CRA SBOM requirements
Required, machine-readable, top-level dependencies minimum, not public. Annex I Part II of the Cyber Resilience Act requires manufacturers to identify and document the components in the product, including by drawing up a software bill of materials in a commonly used machine-readable format covering at the very least the top-level dependencies. It goes in the technical documentation and is disclosed to market surveillance authorities on a reasoned request — not to the world.
The four things the regulation actually says
| Question | The regulation's answer |
|---|---|
| Format | A commonly used machine-readable format. No single standard is mandated. SPDX and CycloneDX both qualify. |
| Depth | At the very least the top-level dependencies. Deeper is permitted and increasingly expected; "at the very least" is a floor, not a target. |
| Who sees it | Part of the technical documentation. Provided to market surveillance authorities upon a reasoned request. No publication duty. |
| When | Maintained for the support period, because vulnerability handling depends on it. |
Why the SBOM is the load-bearing artefact
The SBOM is not a compliance checkbox that happens to sit in Annex I. It is the thing that makes three other obligations possible:
- Vulnerability handling — you cannot identify vulnerabilities in components you have not enumerated.
- Article 14 reporting — when a vulnerability in a widely used library is actively exploited, the question "do we ship it?" needs a same-day answer, and the answer has to be reliable. The 24-hour clock →
- Due diligence on integrated components — an explicit duty in Article 13. The SBOM is the record of what you exercised that diligence over.
Treat it as an operational asset and the compliance requirement is satisfied as a side effect. Treat it as a document to be produced once for an auditor and it will be stale within a release.
Practical shape of a compliant SBOM programme
- Generate at build time, not by hand. An SBOM assembled manually is wrong the day after it is written. Generate it as an artefact of the build, from the same dependency resolution that produced the binary.
- Version it with the release. One SBOM per released artefact, stored with it. The declaration of conformity identifies versions; the SBOM has to match.
- Go beyond top level where you can. Transitive dependencies are where the interesting vulnerabilities live. The floor is top-level; the useful depth is complete.
- Include the non-obvious. Base container images, bundled binaries, vendored source, firmware blobs, fonts, and anything pulled in at install time rather than build time.
- Keep it for the support period. You will need the SBOM for a version you stopped shipping three years ago, because that version is still in the field and still supported.
- Record the diligence, not just the list. Annex VII expects the vulnerability handling process to be described. "We generate an SBOM" is a fact; "we generate an SBOM, scan it against known vulnerability sources on every build and on a weekly schedule for released versions, and triage findings against this severity policy" is a process.
SPDX or CycloneDX?
Either satisfies the regulation. SPDX has stronger licence-compliance heritage and ISO standardisation; CycloneDX was designed around security use cases and carries vulnerability and VEX data more naturally. If you have no existing commitment, CycloneDX tends to fit CRA workflows with less adaptation. If your organisation already produces SPDX for licence reasons, do not introduce a second format for its own sake.
Where the SBOM goes in the technical file
Annex VII section 2 covers the vulnerability handling processes and names the SBOM explicitly. Annex VII also notes the SBOM is provided to market surveillance authorities upon a reasoned request. In a well-organised technical file the SBOM is referenced from the vulnerability handling section and stored as a dated, versioned attachment — not pasted into a Word document. The full Annex VII structure →
Get told when the requirements change
None of the 35 CRA harmonised standards is published yet. When they land — and when deadlines move — we email you. No more than twice a month.