The Cyber Resilience Act and open source
The hobbyist is out. The vendor is in. The foundation is somewhere new. The CRA excludes open-source software supplied outside the course of a commercial activity, creates a lighter category called the open-source software steward for bodies that support open source used commercially, and treats anyone who monetises open source as a manufacturer like any other.
Three positions, not two
1. Non-commercial open source — excluded
Free and open-source software developed or supplied outside the course of a commercial activity is outside the regulation. This is the case the 2023 drafting fight was about, and the exclusion that resulted is broad. An individual or a community publishing a project, accepting contributions and accepting donations that do not amount to commercial supply is not a manufacturer, does not produce a technical file, and does not CE-mark anything.
2. The open-source software steward — a new, lighter category
The regulation creates a category for legal persons, other than manufacturers, that provide sustained support for the development of specific open-source products with digital elements intended for commercial activities, and that play a main role in ensuring the viability of those products. Foundations sit here.
A steward's duties are deliberately much lighter than a manufacturer's:
- Put in place and document a cybersecurity policy fostering secure development and effective handling of vulnerabilities.
- Cooperate with market surveillance authorities on request.
- Report actively exploited vulnerabilities and severe incidents that the steward is aware of, to the extent it is involved in the development of the product.
A steward does not CE-mark, does not produce Annex VII technical documentation, and does not issue a declaration of conformity.
3. Commercial supply — a manufacturer like any other
Take an open-source project, ship it as a product, charge for it, and you are a manufacturer with the full set of duties. The same is true if you monetise it indirectly — an open-core model, a paid hosted version of your own project, or a free product monetised through data or an upsell. The licence of the code makes no difference.
What "in the course of a commercial activity" turns on
The regulation's recitals point to whether the software is supplied as part of a business model. Indicators that a supply is commercial include charging a price, providing a paid service tied to the software other than to recover actual costs, using it to gather personal data for purposes other than improving the software's security or functionality, and being developed by a commercial entity as part of its offering.
Indicators that it is not: an individual or community publishing for use by anyone, accepting donations without a tie to the software's supply, and providing support voluntarily.
The Commission's July 2026 guidance works through this with examples, and it is the section most worth reading if your project sits near the boundary. What the guidance says →
Practical positions
If you maintain a project and are unsure
Write down, once, why you believe the project is supplied outside the course of a commercial activity. Keep it with the repository. It costs an hour and it is the document you will be glad of if the question is ever asked. Adopting a security policy and a disclosure route is worth doing regardless — it is good practice and it is what a steward would have to do anyway.
If you are a foundation
Assess whether you meet the steward definition, and if you do, write the cybersecurity policy now. The steward duties are light enough to be done properly rather than minimally, and doing them properly is a service to every downstream manufacturer that depends on you.
If you are a company shipping open source commercially
You are a manufacturer. Your SBOM matters more than most, your component due diligence is an explicit duty, and your support period commitment binds you to maintain code you did not write. Run the scope test →
Get told when the requirements change
None of the 35 CRA harmonised standards is published yet. When they land — and when deadlines move — we email you. No more than twice a month.