Open source and the CRA: stewards, commercial manufacturers and upstream duties
The Cyber Resilience Act excludes free and open-source software developed or supplied outside a commercial activity, creates a light-touch regime for open-source software stewards that support projects intended for commercial use, and places full manufacturer obligations — including due diligence and upstream reporting — on commercial products built on open source.
By the Vellaci teamPublished Updated 4 min readOperational guidance, not legal advice
Key facts
- Out of scope
- Free and open-source software developed or supplied outside a commercial activity
- Steward
- A legal person systematically supporting specific open-source products intended for commercial activities (Art. 24)
- Steward duties
- Cybersecurity policy; cooperation with authorities; reporting of exploited vulnerabilities and severe incidents they become aware of, to the extent involved
- Manufacturer duties
- Due diligence on integrated components (Art. 13(5)); report vulnerabilities upstream and share fixes (Art. 13(6))
- Attestation
- Voluntary security attestation programmes for open source (Art. 25)
What is out of scope
Software distributed under a free and open-source licence, developed or supplied outside the course of a commercial activity, is not covered. Accepting donations, being developed by a foundation, or being used commercially by others does not by itself make it commercial. Charging for the software, offering paid support as the main monetisation of the same product, or a company placing an open-source product on the market under its brand does. The line is drawn around the supplier's activity, not the licence.
Open-source software stewards
Article 24 creates a category for legal persons — typically foundations — whose purpose is to systematically provide sustained support for specific open-source products intended for commercial activities and to ensure their viability. Stewards are not manufacturers and do not CE-mark. They must put in place and document a cybersecurity policy fostering secure development and effective vulnerability handling, cooperate with market surveillance authorities on request, and, to the extent they are involved in the development of the product, report actively exploited vulnerabilities and severe incidents they become aware of in accordance with Article 14. Penalties under Article 64 do not apply to stewards.
Commercial manufacturers using open source
The full obligations apply to the product you place on the market, including the open-source components inside it. Two provisions target the relationship with upstream projects:
- Article 13(5) — due diligence when integrating third-party components, including open source, so that they do not compromise the product's security. In practice: an SBOM, provenance and maintenance signals per component, vulnerability matching, and a policy for abandoned dependencies.
- Article 13(6) — when you identify a vulnerability in a component, report it to the person or entity maintaining the component and, where you develop a fix, share the code or the information with them. Coordinate timing with your own Article 14 obligations.
Due diligence in practice
Article 13(5) does not prescribe a method, so market expectation will define it. A defensible baseline for each integrated component: know that it is there (SBOM with purl), know who maintains it and how actively (last release, responsiveness to security reports, bus factor), know its known vulnerabilities and your exposure to them (matching plus VEX), know its licence, and have a plan if it is abandoned (fork, replace, or vendor support). Record the check per release, not once. For components that carry an attestation or an established security process — a foundation with a published policy, a project in the OpenSSF Scorecard upper range — the check is quicker but not skipped.
Contributing back
The regulation nudges manufacturers towards the open-source projects they depend on: report vulnerabilities upstream, share fixes, and — through stewards and attestation — support the projects' security work. Practically, that means an internal rule that security fixes to open-source components are submitted upstream by default, a budget line for supporting critical dependencies, and a disclosure timeline that gives maintainers a fair chance to release before your advisory names them.
Security attestation programmes
Article 25 allows the Commission to establish voluntary security attestation programmes so that open-source developers or users can attest conformity of open-source products with the essential requirements. Attestations will help manufacturers evidence due diligence for components that carry one; they do not transfer the manufacturer's obligations.
Practical steps for both sides
| If you are… | Do this |
|---|---|
| An open-source project outside commercial activity | Nothing is required. Publishing a SECURITY.md, a security.txt and an SBOM per release helps your commercial downstream users meet their duties and is good practice. |
| A foundation or steward | Write and publish the cybersecurity policy; define how you receive and handle reports; decide how you will notify under Article 14 when involved; keep records. |
| A commercial manufacturer | SBOM every release; match continuously; track upstream maintenance health; report upstream and share fixes; document due diligence in Annex VII. |
Frequently asked questions
- Our product is open source and we sell support. In scope?
- If the software is placed on the market in the course of a commercial activity — support as the primary monetisation of the same product is a strong indicator — you are a manufacturer for that product. A dual-licensing or open-core vendor is a manufacturer for the commercial offering.
- Does a foundation have to CE-mark projects?
- No. Stewards do not carry conformity assessment or CE marking obligations; they carry policy, cooperation and reporting duties.
- Who reports if an exploited vulnerability is in a widely used library?
- Every manufacturer whose product is exploited reports for its product; the steward reports to the extent it is involved; the library's own maintainers, if non-commercial, have no obligation but are usually the source of the fix. Coordinate through the CSIRT where necessary.