When the EU Cyber Resilience Act was first proposed in September 2022, the open-source community was alarmed. The initial draft appeared to hold open-source maintainers — often unpaid volunteers — liable for the security of software used in commercial products worldwide. The outcry from foundations, developers, and the Linux kernel community prompted significant revisions. The final text of Regulation (EU) 2024/2847 reflects hard-fought compromises.
This guide explains the final position: who is exempt, who is in scope, and what the new "open-source software steward" category means in practice.
The Basic Rule: Non-Commercial Open Source Is Exempt
Article 2(1) of the CRA states clearly that the regulation does not apply to "free and open-source software that is developed or supplied outside the course of a commercial activity."
This exemption covers the vast majority of open-source projects: volunteer-maintained libraries on GitHub, hobby projects, academic code, and non-commercial community software. If you maintain a library in your spare time, distribute it for free, and receive no commercial benefit, the CRA does not apply to you directly.
When Open Source Becomes In-Scope
The exemption has limits. The following scenarios bring open-source projects into CRA scope:
- Commercial distribution: If you sell your open-source software — even at a nominal price, even as part of a support contract — it is in scope.
- Monetised services: If you provide your open-source project as a managed service or SaaS, it may be in scope depending on the service model.
- Commercial backing: If a company (including your employer) maintains the project primarily for commercial purposes, even if the code is open-source, it may be in scope.
- Integrated into a commercial product: When a business takes an open-source component and incorporates it into a commercial product for the EU market, that business (as the manufacturer) bears the CRA obligations — not the original maintainer. This is a critical distinction.
The Open-Source Software Steward
The CRA introduces a new legal category: the "open-source software steward." This is defined in Article 3(18) as a legal entity that systematically provides ongoing support for open-source products with digital elements intended for commercial activities — without placing those products on the market.
Think of foundations like the Linux Foundation, the Apache Software Foundation, the Python Software Foundation, or the Eclipse Foundation. These organisations manage projects widely used in commercial products, but do not themselves sell or distribute commercial products.
OSS stewards face lighter obligations than full CRA manufacturers:
- Must establish and maintain a CVD (coordinated vulnerability disclosure) policy
- Must cooperate with market surveillance authorities when investigating products using their projects
- Must notify ENISA of actively exploited vulnerabilities in their projects
- Not required: CE marking, technical documentation, SBOM (as a steward — commercial manufacturers using their projects must generate their own SBOMs)
What This Means for Businesses Depending on Open Source
Here is the critical implication most businesses overlook: if you use open-source components in a commercial product for the EU market, you are the CRA manufacturer. The open-source maintainer's exempt status does not transfer to you.
This means:
- You must generate an SBOM that includes your open-source dependencies
- You must monitor those dependencies for new vulnerabilities
- When a critical vulnerability is discovered in an open-source library you use (like a future Log4Shell), you must assess impact, patch, and report within the CRA's timelines
- If an open-source project is abandoned and a security vulnerability is discovered, you remain responsible for patching — even if that means forking and maintaining the dependency yourself
The CRA does not punish open-source maintainers. It places appropriate responsibility on the organisations that commercialise open-source software. If you profit from open-source, you are responsible for its security in your products.
The Dependency Risk Problem
The average modern software product contains 528 open-source dependencies (Synopsys OSSRA 2024). Of those, a significant proportion are unmaintained, have known vulnerabilities, or are maintained by a single volunteer. The CRA creates a powerful incentive for commercial organisations to contribute back to the open-source projects they depend on — or to reduce dependency on unmaintained projects.
This is, ultimately, what the regulation intends to achieve: a healthier, better-funded, more secure open-source ecosystem where commercial beneficiaries bear appropriate responsibility.
Practical Steps for OSS-Dependent Businesses
- Generate comprehensive SBOMs including all transitive dependencies
- Assess which open-source projects are critical to your products and poorly maintained
- Contribute financially or with engineering resources to those projects
- Establish a process for responding to open-source vulnerabilities (CVD, ENISA reporting)
- Include open-source lifecycle risk in your product end-of-life planning