Cyber Resilience Act and Open Source Software: What Software Vendors and Stewards Need to Know
Update — 27 July 2026
The European Commission has approved its guidance on applying the CRA to open-source software (Communication C(2026) 5252 and Annex), finalizing what was still a draft when this post first went live. We’ve updated the post to match: the “commercial activity” test now turns on whether access to the software itself, including its maintenance, is gated behind payment, not simply whether paid services are sold alongside it. The guidance also sets out what qualifies as FOSS in the first place, and confirms the reporting timeline and scope that apply to open-source software stewards under Article 24(3).
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. The European Commission (EC) has been clarifying the details through guidance since March 2026, and approved the content of that guidance on 27 July 2026.
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 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 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 under the same 24-hour early-warning, 72-hour notification, and 14-day final-report timeline that applies to manufacturers, to the extent the steward is involved in developing the product (Article 24(3))
- Report severe security incidents, but only those affecting the network and information systems that the steward itself provides for the product’s development (Article 24(3))
- 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, but the guidance clarifies the decisive factor: whether access to the software itself, including its maintenance, is conditioned on payment — not simply whether professional services are sold alongside it. SLA-backed hosting or a paid edition that gates access to the software constitutes commercial activity; offering optional paid support around software that otherwise remains freely available typically does not. 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 Cyber Resilience Act requires regular vulnerability assessments and external audits – on a continuous and sustainable basis.
OPENVAS SECURITY INTELLIGENCE supports your CRA compliance – on premises or in the cloud. Contact us to learn more.
The EC’s CRA Guidance: What We Know Now
A public consultation on the EC’s draft guidance ran from 3 March to 13 April 2026. On 27 July 2026, the European Commission approved the content of its guidance on applying the CRA (Communication C(2026) 5252 and its Annex). The guidance is non-binding and will formally apply once all EU-language versions have been adopted; some edge cases remain open to interpretation, but this is no longer a draft. In its guidance, the EC clarifies the definition of “commercial activity” and addresses other key issues regarding scope, including what qualifies as FOSS.
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
- To qualify as FOSS in the first place, software must meet two cumulative conditions: a licence granting the full set of rights to access, use, modify, and redistribute it, and source code that is genuinely openly shared — not limited to paying customers or a restricted group
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); onboarding and registration guidance has been rolling out from ENISA since 31 July 2026, with the platform itself scheduled to go live by 11 September 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.
Are you ready for the Cyber Resilience Act?
CRA-compliant vulnerability assessments and audits – OPENVAS SECURITY INTELLIGENCE guides you toward compliance, on premises or in the cloud.
Recommendations for Software Vendors Working with Open Source
- 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.
- 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 guidance’s monetization test is the place to start.
- Prepare for September reporting now. Set up an internal process that can produce a 24-hour early warning — ENISA’s SRP onboarding and registration guidance has been available since 31 July 2026.
- 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.
- Review the EC’s guidance. The Commission approved its guidance on applying the CRA on 27 July 2026 (Communication C(2026) 5252 and Annex) — if you assessed your project’s CRA status using the March 2026 draft, revisit that conclusion against the final text, particularly the FOSS and commercial-activity tests.
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/
11. European Commission — Communication C(2026) 5252 and Annex: Guidance on the application of the Cyber Resilience Act (27 July 2026)
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
