The CRA and open source: maintainers, stewards and the companies that ship your code
- open-source
- scope
- article-14
- sbom
- vex
The Cyber Resilience Act mostly does not apply to open-source maintainers. It applies to companies that make software available on the EU market in the course of a commercial activity, and it makes them responsible for every open-source component they ship. In between sits a new, lighter category, the open-source software steward, for foundations and similar bodies that support projects other companies build on. Where the line falls for a given project is, in places, genuinely unclear, and this post says where.
Does the Cyber Resilience Act apply to open-source maintainers?
For most maintainers, no. The CRA applies to products made available on the market, meaning supplied for distribution or use in the course of a commercial activity.Art. 3(22) Recital 18 of the Regulation says free and open-source software that is not monetised by its manufacturer is not supplied in the course of a commercial activity, and that the Regulation does not apply to people who contribute code to projects that are not under their responsibility.
Recital 18 also rules out several things people feared would count:
- receiving financial support from manufacturers, or manufacturers contributing code;
- making regular releases;
- the way development is financed or organised;
- development by a not-for-profit organisation that puts all earnings after costs back into its not-for-profit objectives.
Hosting code on a forge or a package registry is not, by itself, making it available on the market either (recital 20). And accepting donations without the intention of making a profit is not a commercial activity (recital 15).
Open-source foundations argued for exactly this distinction while the Regulation was being negotiated, and on the final text they largely got it. The obligations follow the money, which is where they belong.
What is an open-source software steward?
Open-source software steward
A legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products. Defined in Article 3(14) of the Regulation.
Three parts of that definition do the work. A steward must be a legal person, so an individual maintainer cannot be one. It must support the project systematically and on a sustained basis, which recital 19 says includes hosting and managing collaboration platforms, hosting code, governing the project and steering its development. And the software must be intended for commercial activities, which recital 19 says covers integration into commercial services or monetised products, including where the companies integrating it contribute regularly or fund its continuity.
In practice that describes many foundations, and also companies that develop and publish open source in a business context without selling it. Recital 19 names both.
What does Article 24 require of stewards?
Article 24 has three paragraphs, and they are light by design:
- A cybersecurity policy, documented in a verifiable way. It should foster secure development and effective vulnerability handling by the project's developers, encourage voluntary reporting under Article 15, and cover documenting, addressing and remediating vulnerabilities and sharing vulnerability information in the community.Art. 24(1)
- Cooperation with market surveillance authorities on request, including handing over that policy when an authority asks with reasons.Art. 24(2)
- A narrow part of Article 14.Art. 24(3) More on this below, because it is the part most often overstated.
Stewards may not put a CE marking on the projects they support (recital 19). And none of the CRA's administrative fines apply to any infringement by a steward.Art. 64(10)
Do stewards have to report actively exploited vulnerabilities?
Partly, and the text is less clear than it looks. Article 24(3) applies Article 14(1), the duty to notify actively exploited vulnerabilities, to stewards "to the extent that they are involved in the development" of the product. It applies the severe-incident duty in Article 14(3) and the user-notification duty in Article 14(8) only where a severe incident affects network and information systems the steward provides for development.Art. 24(3)
Three things are not settled by the text:
- The deadlines. Article 24(3) names Article 14(1), not Article 14(2), which is where the 24-hour, 72-hour and 14-day stages live. Article 14(2) is phrased as serving the notification in paragraph 1, so the stages may follow. Nothing says so outright.
- "To the extent that they are involved in the development". A foundation that only holds trademarks and runs a build farm is involved in development differently from one that employs the core team. The Regulation does not draw that line.
- Which CSIRT. Article 14(7) picks the CSIRT from a manufacturer's main establishment. A steward is by definition not a manufacturer, and the Regulation does not say how the rule transfers.
Our reading: a steward should run the same process a manufacturer would for an actively exploited vulnerability it is involved in fixing, because the cost of doing so is low and the alternative is arguing about paragraph references with a CSIRT. That is a judgement, not a statement of the law. If you run a foundation, take advice on it. The Commission keeps a page on the CRA and open source worth watching for guidance.
Who you are, and what applies
| Who you are | Status under the CRA | Article 14 | What else applies |
|---|---|---|---|
| Individual maintainer, project not monetised | Outside the Regulation (recital 18) | Does not apply | Nothing. You may report voluntarily under Article 15 |
| Foundation or company supporting a project meant for commercial use, without selling it | Open-source software steward, Art. 3(14) | Art. 14(1) to the extent involved in development; 14(3) and 14(8) for incidents on its own development infrastructure (Art. 24(3)) | Documented cybersecurity policy and cooperation with authorities (Art. 24). No CE marking. No fines (Art. 64(10)) |
| Company that monetises its own open-source product | Manufacturer, Art. 3(13) | Applies in full | All manufacturer obligations. An Annex III product can self-assess if its technical documentation is public (Art. 32(5)) |
| Company integrating open source into a product it sells | Manufacturer of the whole product | Applies in full, including to exploited vulnerabilities in components | Due diligence on components (Art. 13(5)); report component vulnerabilities upstream (Art. 13(6)) |
If you are unsure which row you are in, the free scope check asks the questions in order and shows its reasoning. The CRA glossary defines manufacturer, making available and the other terms the table relies on.
Where is the law genuinely unclear?
Monetisation. Recital 15 says commercial activity might be characterised by charging for the software, charging for technical support beyond cost recovery, monetising through a platform, requiring personal data for reasons other than security, compatibility or interoperability, or accepting donations that exceed the costs of design, development and provision.
Several common open-source business models sit on that list or next to it: paid support contracts, open core, dual licensing, a hosted version of the same code. A company built on one of them should assume it is a manufacturer for whatever it monetises.
The harder cases are smaller. A maintainer who sells a support contract to one employer. A project whose sponsorship income exceeds its costs in a good year. A component that is free, maintained by a company that sells something else. Recital 18 says a component meant for integration counts as made available on the market only if it is monetised by its original manufacturer, which helps, but recitals guide interpretation rather than bind. Until the Commission's guidance and the first market surveillance decisions exist, treat these as open questions, and do not let anyone tell you they are settled in either direction.
What applies to companies that ship open-source code?
Everything. If you sell a product containing open-source components, you are its manufacturer, and your vulnerability handling covers the product in its entirety, components included.Art. 13(8) You must exercise due diligence when integrating components, including open source that was never made available on the market.Art. 13(5) Recital 34 lists what that can involve: checking a component's security update history, checking it against public vulnerability databases, and testing it.
When a vulnerability in an open-source library you ship is actively exploited, and the exploitation reaches your product, the Article 14 clock is yours. The maintainer has no CRA deadline. Neither the law nor a support ticket moves your 24 hours onto them.
Article 13(6) adds the obligation that matters most to maintainers. A manufacturer that identifies a vulnerability in a component must report it to the person or entity maintaining the component, and where it has developed a fix, share the code or documentation with them.Art. 13(6) In our view this is the best paragraph in the Regulation for open source. It turns "we patched our fork" into a legal duty to send the patch upstream.
What will manufacturers ask of upstream projects?
Expect questions, not demands. Manufacturers have to document components and vulnerabilities, including in a machine-readable SBOM covering at least the top-level dependencies.Annex I Part II(1) To do that well, they will ask projects for:
- A security contact and a private reporting channel, such as a
SECURITY.mdand private vulnerability reporting on your forge. Article 13(6) means you will receive reports from companies that are legally required to send them. - Advisories with affected and fixed versions, published somewhere machine-readable, so a fix can be matched against what they ship.
- VEX statements, saying a CVE in a dependency does not affect your project. Useful, and not required of anyone by the CRA.
- A support or end-of-life policy. Manufacturers set support periods of at least five years and may take the support periods of core components into account.Art. 13(8)
- An SBOM for your releases. Helpful for a project with vendored code, and again not a CRA obligation for a maintainer outside the Regulation.
None of this is owed by an individual maintainer outside the Regulation. It is what makes a project easy to depend on, and a project that publishes the first two will get fewer questionnaires about the rest. If a company asks for more, such as contractual fix deadlines or a signed statement of CRA conformity, that is a commercial request. It is reasonable to ask to be paid for it, and reasonable to note that charging for support may itself bear on whether you are monetising (recital 15).
How much pressure does exploitation data put on library maintainers? Less than the noise suggests. Of the 25 vulnerabilities CISA added to its exploited catalogue between 11 and 30 September 2026, none was published in OSV against npm, PyPI, Maven, Go or crates.io, as our analysis of KEV since Article 14 went live shows. Most entries in that window were commercial products in their own right. The SBOM requirements a manufacturer has to meet are on SBOM requirements under the CRA, and why we watch SBOMs rather than scan code is in we don't scan your code.
Where to start
- If you maintain a project: add a
SECURITY.mdwith a contact and turn on private vulnerability reporting. It costs an hour and answers the most common question manufacturers will ask. - If you run a foundation: write down the cybersecurity policy Article 24(1) describes, even if most of it already exists as practice, and decide who would handle a notification under Article 24(3).
- If you ship open source commercially: run your SBOM through the free KEV check, and check that your process sends component vulnerabilities and fixes upstream, as Article 13(6) requires.
- If you are not sure which of these you are: answer the scope check, then read the Commission's CRA reporting page for the obligations that follow.
Frequently asked questions
Does the Cyber Resilience Act apply to open-source maintainers?
Not to an individual maintainer who does not monetise the project. The Regulation covers products made available on the market in the course of a commercial activity, and recital 18 says it does not apply to people who contribute code to free and open-source projects that are not under their responsibility.
What is an open-source software steward under the CRA?
A legal person, other than a manufacturer, that systematically supports the development of specific free and open-source software intended for commercial activities on a sustained basis and ensures its viability. Article 3(14) defines it. Many foundations will qualify; an individual cannot.
Do open-source stewards have to report actively exploited vulnerabilities?
Article 24(3) applies Article 14(1) to stewards to the extent they are involved in development, and Article 14(3) and (8) only for severe incidents on infrastructure they provide for development. How far the staged deadlines apply is not spelled out, and stewards cannot be fined under Article 64(10).
Who reports a vulnerability in an open-source library used in a commercial product?
The company selling the product. It is the manufacturer and is responsible for vulnerabilities in every component it integrates. Article 13(6) also requires it to report a vulnerability it finds in a component to whoever maintains that component.
Checked against Regulation (EU) 2024/2847 as of 1 October 2026. Written by the team that builds Declara.
Not sure whether this applies to you?
This produces evidence, timelines and drafts. It is not legal advice, and you remain the party responsible for reporting.