ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The Cyber Resilience Act open source question worries maintainers and companies alike: does the new EU regulation apply to code that people publish for free, and who is responsible if a component is used inside someone else’s product? The short answer is that the law tries to protect genuine open source development while placing clear duties on those who make open source part of a commercial offer.
This guide explains when open source software is in scope, what an open-source software steward is and must do, what manufacturers that use open source components must do, and how to prepare. It draws on the European Commission’s summary of the legislative text. The regulation is long and technical, and the rules are still being supplemented by guidance and standards, so treat this as orientation, not legal advice.
Free gap assessment
Where do you stand on the Article 21 measures?
Score scope, all ten measures, the management-body duties and the reporting clocks, free.
Run the free NIS2 gap assessment → or View premium report sample
The Commission summary says that free and open-source software is a product with digital elements in scope only when it is made available on the market in the course of a commercial activity. Merely publishing source code online, without a commercial context, does not make a developer a manufacturer under the regulation.
Commercial activity can take many forms: charging a price, offering paid technical support where it is a condition of use, using the software to monetize other services or collecting personal data for purposes other than security or interoperability. If you are unsure, analyze your own model carefully and record the reasoning. Our overview of the EU Cyber Resilience Act explains the regulation and our guide on CRA product classification shows how risk categories work.
The regulation creates a role for legal entities that provide sustained support for specific open source products intended for commercial activities and that ensure the viability of those products. Foundations and some companies that host projects may qualify. The idea is to recognize that these organizations are not manufacturers but still play a central role in security.
Stewards must put in place and document a cybersecurity policy that fosters the development of a secure product and effective vulnerability handling, including voluntary reporting of vulnerabilities by developers and users. They must cooperate with market surveillance authorities on request and provide their policy documentation in an understandable form. Where they are involved in development, parts of the manufacturer reporting obligations apply, and where serious incidents affecting their development infrastructure impact the security of the products, reporting obligations can apply too. The Commission summary also notes that stewards are not subject to administrative fines under the regulation.
Most of the practical impact falls on manufacturers that build open source into products. A manufacturer is responsible for the cybersecurity of the whole product, including the components it integrates. That means exercising due diligence on third-party components, including open source, and handling vulnerabilities found in them. See our page on SBOM requirements for how a software bill of materials supports this.
In practice, you will need to know what open source is in your product, which versions, under what support, and how quickly you can react when a vulnerability is disclosed. Where you find and fix a vulnerability in a component, you should report it to the person or entity maintaining it, and share the fix where appropriate.
| Role | When it applies | Main obligations |
|---|---|---|
| Manufacturer | Places a product with digital elements on the EU market in a commercial activity | Secure design, vulnerability handling, documentation, conformity assessment, reporting |
| Open-source software steward | Provides sustained support for specific open source products intended for commercial use | Cybersecurity policy, vulnerability handling cooperation, reporting of exploited vulnerabilities and severe incidents as applicable |
| Individual or non-commercial maintainer | Publishes code outside commercial activity | Generally outside scope |
| Integrator using open source | Builds open source into a commercial product | Exercises due diligence on components and remains responsible as manufacturer |
The CRA sets vulnerability handling requirements and, from 11 September 2026, reporting obligations for actively exploited vulnerabilities and severe incidents under Article 14, according to the Commission. Those reporting obligations apply before the full set of requirements, which the Commission gives as 11 December 2027. Read the CRA reporting deadline for the details, and set up a policy for coordinated vulnerability disclosure.
Open source projects benefit from a clear security contact, a published policy and a process for triage, fixes and advisories. Even where the regulation does not apply to you, these practices make it easier for downstream manufacturers to meet their own obligations.
Three dates matter according to the Commission’s summary: 11 June 2026, when the provisions on notification of conformity assessment bodies become applicable; 11 September 2026, when reporting obligations begin; and 11 December 2027, when the regulation becomes fully applicable. As of the end of September 2026, the reporting date has just passed, so manufacturers and stewards in scope should already be operating their reporting process.
Use the time before the main date to inventory components, set up support period decisions, prepare technical documentation and plan conformity assessment. Our guides on the CRA support period and conformity assessment explain those elements.
Use the following actions as a starting point and adjust them to your role.
Costs depend on your role. Manufacturers face engineering, documentation and assessment costs; see CRA compliance cost. Penalties can be substantial for manufacturers, but stewards are reported to be outside the administrative fines; read CRA penalties for details on enforcement and the authorities involved. Also compare with CRA vs NIS2, because companies often face both.
Policies and records are the working tools: a vulnerability handling policy, a component inventory, a due diligence record, an incident reporting procedure and technical documentation. The EU CRA Toolkit includes editable templates aligned to the regulation, so you can build a documented process instead of starting from scratch.
For the source of the Commission’s description, see the European Commission summary of the Cyber Resilience Act. Combine templates with your real engineering workflow: the regulators will ask for evidence of practice, not only policies.
Consider three cases. A developer publishes a small library on a code hosting site and accepts voluntary donations; with no commercial model behind it, this is generally the situation the regulation aims to leave alone, though the analysis should be recorded. A foundation hosts a widely used project, sets its security policy and coordinates releases that companies rely on commercially; it may be an open-source software steward. A company takes a popular library, builds it into a connected device and sells the device in the EU; it is a manufacturer and is responsible for the library as part of its product. Every real case needs its own analysis, so treat these as illustrations, not rulings.
When you depend on an open source project, ask simple questions. Does the project publish a security policy and contact? How does it announce vulnerabilities and fixes? Which versions are supported and for how long? Does it provide a software bill of materials or signed releases? Keep the answers with your due diligence record. If the answers are poor, consider contributing upstream, pinning to a supported version or replacing the component. This approach protects your product and helps the ecosystem, which is the direction the Cyber Resilience Act open source provisions are meant to encourage.
Whether you are a steward or a manufacturer, put ownership in writing. Name a person accountable for the security policy, a person who triages vulnerability reports and a person who decides on advisories and releases. Review the policy yearly and after any incident, and keep minutes of the decisions. Good governance turns the regulation from a one-off project into a routine part of engineering.
Teams often assume the regulation does not apply because their code is free, without analyzing commercial activity. Others assume it applies to every hobby project. Manufacturers forget to track components deep in the dependency tree. Some wait until the December 2027 date and miss the reporting obligations that started earlier. Write down your analysis, keep your inventory current and build the reporting process now.
No. The Commission says open source is in scope as a product with digital elements only when made available on the market in the course of commercial activity.
A legal entity that provides sustained support for specific open source products intended for commercial activities and ensures their viability. Stewards have a lighter set of obligations.
According to the Commission summary, stewards are not subject to administrative fines under the regulation, although they still have obligations.
Reporting obligations apply from 11 September 2026 and the regulation is fully applicable from 11 December 2027.
Keep an inventory and SBOM, exercise due diligence on components, handle vulnerabilities, and report actively exploited vulnerabilities and severe incidents as required.
October 1, 2026
