CRA SBOM requirements: what the Cyber Resilience Act asks for
From 11 December 2027, every product with digital elements placed on the EU market needs a software bill of materials. Here is what the Cyber Resilience Act actually requires, what it does not, and how to keep one SBOM per version without extra work.
What the text says
Annex I, Part II, point 1 asks manufacturers to identify and document the components in their product, including by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format, covering at least the top-level dependencies.
The SBOM is part of your technical documentation (Annex VII). You give it to a market surveillance authority when it sends a reasoned request. The CRA does not ask you to publish it.
Which format
The text names no format. In practice, CycloneDX and SPDX are the two commonly used ones, and most build tools can produce either as JSON. Pick one and stick to it, so every version can be searched the same way.
What works in practice
- One SBOM per released version. Generate it in the build that produces the release, not by hand afterwards.
- Go beyond the minimum when you can. Top-level dependencies are the legal floor, but most exploited flaws sit deeper in the tree.
- Keep it as long as the documentation. Technical documentation is kept for at least ten years, or for the support period if that is longer.
- Make it searchable. The day a library is reported as exploited, you need to know which of your versions ship it, within the 24 hours of the CRA early warning.
Where Clearlane CRA helps
Clearlane CRA keeps a CycloneDX or SPDX JSON file for each version of each product in Jira. Search a component name, a version range or a package URL across every SBOM, and open one case for all the versions found. The register shows the versions on the market that still have no SBOM. Only your security team and Jira administrators can see the SBOMs.
Source: Regulation (EU) 2024/2847, Annex I Part II and Annex VII. Checked on 16 October 2026.