Cyber Resilience Act and Open Source Software: What Software Vendors and Stewards Need to Know

The CRA’s scope for open-source software (OSS) was one of the most contested parts of the regulation. The OSS community raised legitimate concerns during the legislative process such as how should manufacturer obligations apply to non-commercial, volunteer-driven projects? The final regulation offers an answer, though how convincing that answer is depends on who you ask. Since March 2026, the European Commission’s (EC) first draft guidance has started to clarify the details.

For companies like Greenbone that both steward an open-source project (OPENVAS) and sell commercial products built on it, the answer is clear: full manufacturer obligations apply to the commercial side, and steward obligations apply to the open-source community activities. Knowing where those lines fall is important.

The CRA’s Three-Tier Approach to Open-Source Software

Tier 1: Non-Commercial Open-Source Projects and Their Contributors (Out of Scope)

Free and open-source software (FOSS) developed and distributed in a purely non-commercial context (i.e. volunteers building software and sharing it freely, with no commercial intent or support model) does not impose CRA obligations on its creator or distributor. Only FOSS supplied in the course of a commercial activity falls in scope, and the EC’s draft guidance confirms that merely supplying non-monetized FOSS is not a commercial activity.

That said, “non-commercial” is still perhaps more narrowly defined than many projects assume. Accepting donations does not automatically make a project commercial. However, (EU) 2024/2847 Recital 15 states that “accepting donations exceeding the costs associated with the design, development and provision” does constitute commercial activity. The EC’s draft CRA guidance and (EU) 2024/2847 Recital 18 also state that the CRA does not apply to individuals or companies that merely contribute source code to FOSS projects that are not under their responsibility.

Tier 2: Open-Source Software Stewards (Lighter Obligations)

The CRA introduces the legal definition of an “open-source software steward”: a legal person that provides sustained, systematic support for the development of open-source products intended for commercial activities, or ensures those products’ viability. This covers software foundations, industry consortia, and companies that maintain and support OSS projects used commercially by others. A natural person is not classified as an OSS steward under (EU) 2024/2847 Article 3(14).

Stewards do not face the full obligations that manufacturers do. Their obligations are lighter than full manufacturer requirements: no CE marking, no formal conformity assessment, no required retention of technical documentation. However, under (EU) 2024/2847 Article 24, open-source software stewards must still:

• Maintain a cyber security policy that fosters secure development of the OSS products they support
• Cooperate with market surveillance authorities and make security documentation available on request
• From 11 September 2026, report actively exploited vulnerabilities and severe security incidents that affect the network and information systems provided for development of their OSS products
• Effectively remediate vulnerabilities and ensure they are accessible to users without undue delay
• Establish a policy that fosters voluntary vulnerability reporting by the developers of the software product

Stewards are also exempt from administrative fines for CRA infringements under Article 64(10). Enforcement works through cooperation and corrective measures rather than financial penalties.

Tier 3: Commercial OSS Vendors (Full Manufacturer Obligations)

If an individual (natural person) or legal person (such as a company or other type of organization) develops and distributes OSS and places it on the EU market in the course of commercial activity, they qualify as a manufacturer under the CRA. The CRA’s threshold for “commercial activity” is broad. It is not only about selling a license. Providing paid support, SLA-backed hosting, or professional services built around an OSS product also constitutes commercial activity under the CRA. All Annex I requirements apply to manufacturers: secure-by-default design, vulnerability handling, 24-hour incident reporting, SBOM, technical documentation, and CE marking.

Manufacturers remain responsible for vulnerability handling in their own products, including vulnerabilities caused by integrated third-party OSS components. (EU) 2024/2847, Article 13 specifies that manufacturers must exercise due diligence when integrating third-party components. Upon identifying a vulnerability in an integrated component, including an FOSS/OSS component, they must report the vulnerability to the person or entity manufacturing or maintaining that component and, without delay, remediate the vulnerability in accordance with (EU) 2024/2847 Annex I, Part II.

The EC’s March 2026 Draft Guidance: What We Know Now

The public feedback period for the EC’s March 2026 draft guidance closed on 31 March 2026. Some edge cases remain unclear, although final guidance is expected later in 2026. Organizations should revisit any scope conclusions based on the draft once the final version is published. In its March 2026 draft guidance on applying the CRA, the EC does make some clarifications for the definition of “commercial activity” and addresses other key issues regarding scope.

Key clarifications include:


• A product can be free and open-source and still be considered “made available on the market” if it is also offered as part of a commercial service or monetized support model
• The presence of publicly available code alone, such as a GitHub repository, does not constitute market placement; a commercial relationship is what imposes responsibility
• Dual-license models (free OSS edition + commercial enterprise edition) place the commercial edition firmly within scope of the CRA; the free edition’s status further depends on its association with commercial activity
• Responsibility follows governance: whoever publishes and effectively controls a project bears the obligations, not whoever technically publishes changes to the software’s source code
• Manufacturer responsibility also extends beyond the original developer to companies integrating or rebranding OSS components into products placed on the EU market

September Reporting: The Clock Is Ticking

The first hard CRA deadline applies to all products with digital elements, including OSS. From 11 September 2026, manufacturers and stewards must report actively exploited vulnerabilities and severe incidents that may affect the security of the digital products they are responsible for.

The reporting deadlines are tight: an early warning is due within 24 hours of awareness, a full notification within 72 hours, and a final report within 14 days for exploited vulnerabilities or one month for severe incidents. Reports are submitted through ENISA’s Single Reporting Platform (SRP), and onboarding instructions and a reporting manual are expected from ENISA in June 2026.

What This Means for Greenbone

Greenbone operates across two tiers: as a manufacturer of digital products, and as an open-source software steward. As discussed above, the CRA imposes distinct obligations for both of these roles. As a manufacturer, Greenbone is responsible for the commercialized OPENVAS enterprise IT security products, and, as a steward, we take responsibility for our FOSS community projects.

Greenbone meets our manufacturer responsibilities through a wide range of IT security policies, controls, and response plans. This includes continuous vulnerability management, GDPR-compliant architecture, documented security practices, and other IT security best practices. As an active ISO/IEC 27001:2022 and ISO 9001:2015 certified organization, Greenbone is dedicated to the most stringent quality standards for Information Security. As an OSS steward, Greenbone is prepared to fulfill the CRA requirements for our OPENVAS community software projects.

Finally, as a vendor of digital products specifically for cyber security, Greenbone’s customers use our OPENVAS line of IT security products to meet their own CRA obligations. This means we are responsible not only for fulfilling our own CRA obligations, but also for understanding the technical needs that other organizations have to stay compliant. This dual role as a manufacturer of digital products and a vendor of cyber security products that help other organizations achieve CRA compliance gives Greenbone a clear vantage point: navigating the regulation while also broadly supporting global manufacturers of digital products to do the same.

Recommendations for Software Vendors Working with Open Source

1. Map your OSS usage. Every open-source component in your products must be identified, documented, and tracked. This is the foundation of your SBOM and is required by the CRA regardless of the component’s own compliance status.
2. Audit your commercial relationships. If you monetize OSS in any way, such as paid support, SaaS delivery, professional services, seek legal advice on whether full manufacturer obligations apply. The draft guidance’s monetization test is the place to start.
3. Prepare for September reporting now. Set up an internal process that can produce a 24-hour early warning, and watch for ENISA’s SRP onboarding instructions (due in June 2026).
4. Engage with the community. The ORC Working Group maintains a CRA FAQ and resource hub for OSS stewards and manufacturers (cra.orcwg.org and the CRA Hub on GitHub). The OpenSSF is also tracking CRA policy developments.
5. Track the EC’s final guidance. The feedback window closed on 31 March 2026. When the Commission publishes the final version, revisit any scope conclusions based on the draft.

Read the full guide: The Complete Guide to the EU Cyber Resilience Act – all requirements, timelines, and penalties in one place.



1. Sources European Commission — Cyber Resilience Act (Regulation EU 2024/2847), Official Journal https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
2. European Commission — CRA and open source software policy page
https://digital-strategy.ec.europa.eu/en/policies/cra-open-source
3. European Commission — Draft guidance announcement (3 March 2026)
https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act
4. European Commission — CRA reporting obligations
https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
5. ENISA — Single Reporting Platform (SRP)
https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
6. Eclipse Foundation ORC Working Group — orcwg.org
https://orcwg.org/
7. ORC Working Group — CRA Hub (FAQ and implementation resources)
https://github.com/orcwg/cra-hub
8. ORC Working Group — White paper: Open Source Software Stewards and the CRA
https://orcwg.org/cra/resources/d3-5-white-paper-on-open-source-software-stewards-and-cra/
9. OpenSSF — EU Cyber Resilience Act policy page
https://openssf.org/public-policy/eu-cyber-resilience-act/
10. OpenSSF — Global Cyber Policy Working Group CRA tracker
https://policy.openssf.org/CRA/