If your product includes open source components, you’re not off the hook under the CRA. Even when no single vendor “owns” the code, the manufacturer of the final product is responsible for securing it. Let’s break down what that means.
What the CRA Actually Says
The CRA defines a “product with digital elements” to include software components, even if they’re free and open source (Article 3(1), (6), and (48)).
You, as the manufacturer, are still accountable when:
- You integrate an open source component into your product (Article 13(5))
- A vulnerability is found in that component (Article 13(6))
- You know—or should reasonably know—about that vulnerability (Article 13(21))
Even if no commercial entity maintains that component, CRA expects you to:
- Report the vulnerability upstream (Article 13(6))
- Share patches or mitigation code back to the upstream maintainers, if available
- Document and track the vulnerability as part of your SBOM (Annex I, Part II, point 1)
If the open source component is critical to your product, and you don’t patch or replace it when it becomes insecure, you’re likely in non-compliance.
What If There’s No Maintainer?
That’s where FOSS stewardship comes in. CRA introduces the concept of a “free and open-source software steward” (Article 3(14)), but if no steward exists, the responsibility falls to you.
In practice, this means:
- You may need to fork and maintain the component yourself
- You must have internal procedures to track vulnerabilities in unmaintained open source code
- You should evaluate whether depending on that component is viable under CRA obligations
What You Should Do
- Maintain a full SBOM including all FOSS components (Annex I, Part II, point 1)
- Monitor known vulnerabilities (e.g. CVEs) for every FOSS dependency
- Have a plan for patching or replacing components, even if upstream is dead
- Disclose security issues in your own product, even if the root cause is in open source (Annex I, Part II, point 4)
Open source is a massive enabler, but under the CRA, it also comes with real responsibilities. If your product depends on “nobody’s code,” then you become that “nobody” in terms of security accountability.