# Open source and the CRA: the libraries you use, and what an open-source steward is Canonical: https://craguard.eu/blog/open-source-and-the-cra-steward Language: en Last updated: 2026-09-02 - [CRAguard](https://craguard.eu/)/ - [Blog](https://craguard.eu/blog)/ - Open source and the CRA: the libraries you use, and what an open-source steward is 30 Aug 2026 · CRAguard Summary The CRA doesn't make a non-commercial open-source developer a manufacturer. But it introduces a new role, the \"open-source software steward\" (Art. 24) — a legal person systematically supporting open source intended for commercial use — with a lighter regime: a cybersecurity policy, cooperation with authorities, and reporting actively exploited vulnerabilities. Crucial for most companies: when you use open-source libraries in your commercial product, you are responsible for those components. Open source and the Cyber Resilience Act is a topic where relief and surprise mix. The relief: the regulation **doesn't turn every open-source developer into a manufacturer**. The surprise: when you **use open-source libraries in your commercial product**, the responsibility for them is yours. Let's untangle it — and explain the new "open-source steward" role. ## Non-commercial open source is out The basic rule: if you develop open-source software **outside a commercial activity** — a community project nobody monetises — you don't fall under the manufacturer's obligations of the CRA. The regulation deliberately avoids stifling volunteer development. But the moment you **monetise** the open source (a paid edition, licences, paid support as part of a commercial offering), you become a manufacturer with everything that entails. ## A new role: the open-source steward (Art. 24) Between "pure volunteer" and "manufacturer", the CRA adds an intermediate link. An **open-source software steward** (**Art. 24**) is a legal person that **systematically and durably supports** the development of open-source software intended for **commercial use** — typically a foundation or organisation behind significant libraries. A steward has a **lighter regime**, not the full manufacturer obligations: - put in place and follow a **cybersecurity policy** (Art. 24(1)) fostering secure development and vulnerability handling, - **cooperate with market surveillance authorities** on request, - **report actively exploited vulnerabilities and severe incidents** affecting their development infrastructure. No CE, no declaration of conformity — a steward is not a manufacturer. It's a proportionate level of responsibility for those who hold important pieces of the ecosystem. Scope-checker ### Find out whether the CRA applies to you Six questions, two minutes, no account. Get your product class and first steps. [Start the scope-checker](https://craguard.eu/checker) ## The most important part for an ordinary company Most small companies are neither a steward nor a pure open-source project — they're **manufacturers who use open source**. And here's the crux: when you use an open-source library in your commercial product, **you are responsible for the security of that component within your product**. Article 13 requires the manufacturer to exercise due diligence when integrating third-party components — including open-source ones. In practice: the fact that a library is "someone else's" and free doesn't relieve you of the duty to track vulnerabilities in it and respond. That's exactly why an **SBOM** (listing those open-source components too) and their **monitoring** are the foundation of the whole process — more in the [SBOM guide](https://craguard.eu/blog/how-to-generate-an-sbom-in-10-minutes). ## How to handle open-source responsibility in practice The good news: you don't have to audit the source code of every library. You just need a process that handles three things: - **Know what you use.** An SBOM that includes open-source dependencies with versions — without it you don't even know what to watch. - **Track vulnerabilities in it.** A daily comparison against databases (OSV, KEV, EPSS) tells you when a problem appears in one of your libraries. - **Be able to respond.** When a finding arrives, you assess it and, if needed, update the library or apply a mitigation — and document the decision. This is exactly the same loop as for your own code; open source just extends it to components you didn't write. Due diligence under Article 13 doesn't mean "you guarantee a third-party library is flawless", but "you have oversight and you respond". ## Common misconceptions - **"We use open source, so we're out of the CRA."** No — out of scope is non-commercial *development* of open source. *Using* open source in a commercial product doesn't cancel responsibility. - **"A hole in a library is its author's responsibility."** Towards your customer and the surveillance authority, you're responsible for your product, including its open-source parts. - **"A steward is anyone who contributes to open source."** No — a steward is a legal person systematically supporting open source for commercial use (Art. 24), not an individual contributor. ## Example: a CVE in a popular library Imagine `CVE-2026-YYYY` appears in a popular library among your dependencies. What follows for you as a manufacturer using it in a commercial product? - **Find out whether it affects you.** From the SBOM you know which of your versions include that library (and at what version) — and whether you fall in the vulnerable range. - **Assess and decide.** If yes, update to the fixed version; if you can't right away, apply a mitigation and document the decision (part of the [risk assessment](https://craguard.eu/blog/two-page-risk-assessment-article-13)). - **If it's actively exploited** (KEV), consider [reporting under Article 14](https://craguard.eu/blog/article-14-step-by-step-enisa-platform) and, after the fix, an [advisory](https://craguard.eu/blog/security-advisories-when-and-how). The fact that a foreign library "caused" the hole doesn't free you from this loop — towards your customer and an authority you're responsible for your product as a whole. ## FAQ - **Must we audit each dependency's code?** No. It's enough to have them in the SBOM, monitor vulnerabilities in them and be able to respond. - **We're a small open-source project with no income — are we a steward?** Probably not; a steward is a legal person systematically supporting open source for commercial use (Art. 24), not every contributor. ## Key point Open source and the CRA have three layers worth not confusing. **Non-commercial development** of open source is outside the manufacturer's obligations — the regulation doesn't want to smother volunteers. An **open-source software steward** (Art. 24) is a legal person systematically supporting open source for commercial use, with a lighter regime (a cybersecurity policy, cooperation, reporting), no CE. And finally, the most important for an ordinary company: when you **use open-source libraries in your commercial product**, you are **responsible** for those components within your product (Art. 13). The fact that a library is someone else's and free doesn't relieve you of tracking its vulnerabilities and responding. Due diligence doesn't mean vouching for the flawlessness of someone else's code — it means having an overview (SBOM), monitoring, and responding (triage and documentation). You do exactly this loop for your own code; open source just extends it to what you didn't write. ## How CRAguard helps CRAguard takes open-source components as seriously as your own code: your dependencies are in the SBOM and we compare them daily against vulnerability databases. When a new problem appears in an open-source library, you get a verdict and the input for your response — whoever the library's author is. [Find out whether the CRA applies to you](https://craguard.eu/checker), or [join the waitlist](https://craguard.eu/#waitlist). *This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Art. 24 open-source software steward, Art. 13 due diligence on components) and the European Commission's guidance of 27 July 2026 (including the FOSS perspective).* Scope-checker ### Find out whether the CRA applies to you Six questions, two minutes, no account. Get your product class and first steps. [Start the scope-checker](https://craguard.eu/checker) ## Sources - [EUR-Lex — Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [ENISA — Single Reporting Platform](https://www.enisa.europa.eu/) --- Source: CRAguard — https://craguard.eu