Guide

SBOM requirements under the Cyber Resilience Act

The CRA turns the Software Bill of Materials from a nice-to-have into a legal requirement. Here is exactly what the regulation asks for, which format to choose, and why the hard part is not generating it, it's keeping it alive.

Yes, the SBOM is explicitly required

Annex I, Part II of the Cyber Resilience Act requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format, covering at the very least the top-level dependencies". In plain terms: every product needs a machine-readable ingredient list of its software. Your customers, especially automotive, industrial and public-sector buyers, are already asking for it contractually, often before the regulator does.

What a CRA-ready SBOM contains

Each component with its exact name and version, its origin (the package ecosystem), and ideally its unique identifier (purl). Modern software is 80-95% third-party components, and vulnerabilities hide disproportionately in transitive dependencies, the components your components pull in. An SBOM that only lists what your team knowingly installed misses most of the attack surface. Machine-readable means JSON/XML in a standard format, not a spreadsheet.

CycloneDX or SPDX?

Both are accepted "commonly used" formats. CycloneDX (OWASP) is security-oriented and the most common in vulnerability management workflows; SPDX (Linux Foundation) has deep roots in license compliance. Practical answer: produce CycloneDX by default, export SPDX when a customer's procurement requires it. What matters more than the format is freshness, an SBOM generated once is a snapshot, and it starts lying at your next release.

The real challenge: keeping it current

Generating an SBOM takes minutes with open-source tooling. The CRA obligation, however, runs for the entire support period of the product, five years or more. Every dependency update invalidates yesterday's document, and every newly published CVE must be checked against your components "without delay". That is a continuous process, not a deliverable: versioned SBOMs per release, automated re-generation from your repositories, and continuous matching against vulnerability databases, with an audit trail proving the monitoring happened. This is precisely the part that doesn't scale manually.

See your product's SBOM in two minutes

Paste a dependency manifest, get a CycloneDX SBOM plus the known vulnerabilities in your components, free account, no credit card.

Run the free scan →

This guide is general information, not legal advice. Sources: Regulation (EU) 2024/2847, Annex I Part II; CycloneDX and SPDX specifications; ENISA guidance.