The EU Cyber Resilience Act expects manufacturers to exercise due diligence when they include third party components, including open source, and to tell the component's maintainer when they find a vulnerability. The recitals give examples such as checking that a component receives regular security updates. Check the legal text for your case.
What the sources say
The European Commission's CRA page states that the regulation entered into force on 10 December 2024, that reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, and that the main obligations apply from 11 December 2027. It also says the Commission published practical implementation guidance on 27 July 2026. The page notes a special approach to free and open source software without detailing it.
Recital 34 of Regulation (EU) 2024/2847 says that where a manufacturer identifies a vulnerability in a component, it should inform the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability. It gives examples of due diligence, including checking whether a component receives regular security updates.
This post is a product manager's reading aid, not legal advice. Whether and how the regulation applies to a given product depends on the product and your role. Ask counsel.
What this means in practice
If your product ships with open source parts, a reviewer could reasonably ask what you did to choose and monitor them. A defensible record answers four questions.
| Question | Evidence to keep |
|---|---|
| What components are in the product? | A current inventory or SBOM per release |
| Why did we choose this component? | A short adoption note covering maintenance and security checks |
| How do we learn about new vulnerabilities? | Monitoring against advisory data |
| What do we do when we find one? | A handling process, including notifying the maintainer |
Steps for a product team
- Produce an inventory for each shipped version and store it with the release.
- Use a checklist at adoption. The OpenSSF evaluation guide covers maintenance, security response, and licensing.
- Monitor shipped components continuously, not only at build time.
- Define who contacts upstream maintainers about findings.
- Keep records of decisions, including exceptions.
Dates matter
Reporting of actively exploited vulnerabilities has applied since 11 September 2026 according to the Commission. The main obligations follow on 11 December 2027, which is a planning date for roadmap capacity.
Quick check
Does the CRA ban open source components?
No. It expects care in choosing and maintaining them.
Is an SBOM required by the CRA?
Check the legal text and the Commission's guidance for the exact wording. An inventory is useful evidence in any case.
Who tells the maintainer about a vulnerability?
Decide an internal owner now. Recital 34 expects the manufacturer to inform the maintainer.
Safeguard's SBOM and dependency scanning and its compliance and evidence automation help keep per release inventories and decision records, and the free scan is at gold.safeguard.sh/scan.
Sources
- European Commission, Cyber Resilience Act
- Regulation (EU) 2024/2847 on EUR-Lex
- OpenSSF Concise Guide for Evaluating Open Source Software
Last reviewed: 19 October 2026.
