Open source and the CRA: the libraries you use, and what an open-source steward is

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:

1. put in place and follow a cybersecurity policy (Art. 24(1)) fostering secure development and vulnerability handling,
2. cooperate with market surveillance authorities on request,
3. 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.

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.

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:

1. Know what you use. An SBOM that includes open-source dependencies with versions — without it you don't even know what to watch.
2. Track vulnerabilities in it. A daily comparison against databases (OSV, KEV, EPSS) tells you when a problem appears in one of your libraries.
3. 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

1. "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.
2. "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.
3. "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?

1. 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.
2. 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).
3. If it's actively exploited (KEV), consider reporting under Article 14 and, after the fix, an advisory.

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

1. 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.
2. 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, or join the 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).