Open source

The CRA and Open Source: What Maintainers, Foundations, and Integrators Actually Need to Know

Last updated · June 12, 2026

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) caused real alarm in the open-source community when it was first proposed. The fear was that any developer who published code could suddenly become a regulated "manufacturer" liable for the security of every product that ever used it. The final text is considerably more nuanced - and considerably more fair. Here is what it actually says.

This post is general guidance on the Cyber Resilience Act, not legal advice. Confirm specifics against the official text on EUR-Lex and the European Commission's CRA pages.

Key points

Individual and non-commercial contributors are generally not in scope. The CRA applies only to software placed on the market in the course of a commercial activity. Volunteering code to a project you don't control is explicitly excluded.
A new "open-source software steward" category (Article 24) covers foundations and similar organisations that systematically support OSS intended for commercial use - but with lighter, tailored duties only.
Stewards cannot be fined for CRA infringements. Their obligations are a cybersecurity policy, cooperation with authorities, and reporting actively exploited vulnerabilities.
The manufacturer who ships a product bears the compliance burden for every open-source component inside it. That responsibility does not travel upstream to the original project.
Reporting obligations begin 11 September 2026. Full CRA requirements apply from 11 December 2027.

Who is out of scope: individual and non-commercial contributors

The CRA recognises that special attention should be paid to the different development models of open-source software. Only free and open-source software that is made available on the market - supplied for distribution or use in the course of a commercial activity - falls in scope.

Two protections matter most for individual developers:

Contributors are explicitly excluded. The CRA does not apply to developers who contribute source code to free and open-source software that is not under their responsibility.
Non-monetised publishing is not a commercial activity. The provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity.

In practice: many typical activities of OSS projects are not considered a commercial activity under the CRA - including receiving financial support from manufacturers without a profit, manufacturers contributing to development, performing regular releases, being hosted on an open repository, and accepting donations without the intention of making a profit.

The critical factor is whether your work is "intended for commercial activities" - not whether someone else uses it commercially downstream. A library published freely on GitHub does not become a regulated product simply because a company later bundles it into a paid product.

Hosting code is not placing it on the market. The CRA text is explicit that the sole act of hosting products with digital elements on open repositories — including through package managers or collaboration platforms — does not in itself constitute making a product available on the market.

The new "open-source software steward" category (Article 24)

The CRA creates a new form of economic actor - the "open source steward" - which acknowledges the role played by foundations and platforms in the open source ecosystem. This is the first time this concept has appeared in an EU regulation.

Who qualifies?

An open-source software steward is 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.

Open-source software stewards include certain foundations as well as entities that develop and publish free and open-source software in a business context, including not-for-profit entities. Think: the Linux Foundation, the Eclipse Foundation, the Apache Software Foundation, and similar organisations whose mission is to sustain projects that end up in commercial products.

There is a type of entity - often but not always existing as a not-for-profit foundation - that nurtures, supports and distributes open source projects, providing upgrades, releases, community development, vulnerability management and associated governance processes, and does so without making a profit or making the open source software projects available commercially. That is the steward archetype.

What stewards must do

Open-source software stewards are subject to the obligations laid down in Article 24, notably: putting in place a cybersecurity policy to foster secure development and handling of vulnerabilities; cooperating with market surveillance authorities; and reporting actively exploited vulnerabilities and severe incidents having an impact on the security of products with digital elements.

More specifically on the cybersecurity policy: stewards shall put in place and document a cybersecurity policy to foster the development of a secure product and effective handling of vulnerabilities by developers. That policy shall also foster the voluntary reporting of vulnerabilities and shall include aspects related to documenting, addressing and remediating vulnerabilities, and promote the sharing of information concerning discovered vulnerabilities within the open-source community.

What stewards cannot be fined for

This is the headline protection: in accordance with Article 64(10), open-source software stewards are not subject to administrative fines for infringements of the CRA.

The tailor-made regulatory regime does not subject those acting as open-source software stewards to the same obligations as those acting as manufacturers under this Regulation; they should not be permitted to affix the CE marking to the products with digital elements whose development they support.

Who carries the compliance weight: the manufacturer

Here is the principle that matters most for companies that ship products:

The manufacturer is responsible for all parts of the product, including components from third parties. The manufacturer must perform due diligence to determine what components to use, and must also report component vulnerabilities to the component maintainer and upstream fixes if they have any. Using an OSS component in a product makes the manufacturer responsible for its use.

When a manufacturer integrates OSS into a CRA-regulated product, CRA obligations and liability transfer to that manufacturer, not the upstream developer.

This is a deliberate design choice. Legal persons who provide support on a sustained basis for the development of products with digital elements which are intended for commercial activities, and who play a main role in ensuring the viability of those products, should be subject to a light-touch and tailor-made regulatory regime - precisely because the full weight of compliance sits with the commercial integrator, not the upstream project.

What does that mean in practice for manufacturers? If you are the manufacturer of a CRA-regulated product, you are responsible for the security of all components, including open-source ones. You must maintain a comprehensive Software Bill of Materials, evaluate the security posture of each open-source dependency, and monitor vulnerability databases for component security issues.

For more on SBOM requirements under the CRA, see the SBOM guide.

The decision tree: which category are you?

Use this interactive tool to work out where you sit under the CRA's open-source framework.

Practical implications

For open-source maintainers

You are almost certainly not a manufacturer if you publish code freely without commercial intent and don't control a product placed on the EU market.
Expect increased scrutiny and requests from downstream users to provide clearer documentation, disclosed vulnerabilities, and perhaps even changes to development workflows. Organisations will start asking more from OSS maintainers.
You have no legal obligation to comply with those requests - but good security hygiene (a SECURITY.md, a CVD policy, a public vulnerability contact) will make your project more attractive to manufacturers doing due diligence. See the software supply chain security guide for practical steps.

For foundations and steward-like organisations

Audit whether you meet the steward definition: are you a legal person, systematically sustaining OSS projects intended for commercial use?
If yes, your main task is drafting and publishing a cybersecurity policy that covers how your projects handle vulnerability discovery, disclosure, and remediation.
The CRA does place obligations on stewards, particularly around vulnerability and incident management and reporting to EU-appointed bodies and users of the software. There are many fewer obligations, however, on stewards than there are on manufacturers.
You cannot be fined. But cooperation with market surveillance authorities is a real duty, not optional.

For companies integrating open source

The moment you integrate open-source software into a commercial product that falls under CRA scope, you become responsible for ensuring that software meets CRA requirements.
Build or buy an SBOM now. When a CVE lands in a popular library, you need to answer "are we affected?" in minutes, not days.
Establish a coordinated vulnerability disclosure process. The first CRA reporting deadline - for actively exploited vulnerabilities and severe incidents - is 11 September 2026.
Check the glossary for precise definitions of "manufacturer", "steward", "product with digital elements", and related terms.

Timeline at a glance

CRA Key Dates

Date	Event
10 December 2024	CRA entered into force
11 September 2026	Vulnerability and incident reporting obligations begin
11 December 2027	All CRA obligations fully apply

The bottom line

The CRA's open-source provisions are a genuine attempt to reflect how the ecosystem actually works. Individual contributors are protected. Foundations get a lighter regime with no fines. The compliance burden sits squarely with the commercial integrator - the party best placed to act on it.

That does not mean the open-source community can ignore the CRA entirely. Manufacturers will increasingly scrutinise the projects they depend on, and projects with clear security practices will be easier to integrate. The CRA is, in that sense, a quiet pressure towards better upstream hygiene - even for those who are technically out of scope.

For a broader view of how the CRA affects your supply chain, read the software supply chain security guide. For SBOM specifics, see the SBOM guide. Definitions for every term used in this post are in the glossary.

Want updates as Commission guidance and harmonised standards evolve? Subscribe to The CRA Brief - free, no spam.