Do you need an SBOM for the CRA? A practical starter

If you make a product with digital elements for the EU market, the Cyber Resilience Act will require you to keep a Software Bill of Materials (SBOM). The good news: an SBOM is not paperwork for its own sake. It is the one artefact that lets you answer "are we affected?" in minutes when the next big vulnerability lands. Here is what the CRA actually asks for, and how to start.

The key points

• The CRA requires manufacturers to draw up and maintain an SBOM for every product with digital elements.
• It must be machine-readable and cover at least the top-level dependencies - CycloneDX or SPDX in practice.
• It lives in your technical documentation (Annex VII). It does not have to be public, but authorities can request it.
• It is mandatory with full application on 11 December 2027 - but build the capability now, because it underpins the reporting duties that start in September 2026.

What an SBOM is

A Software Bill of Materials is a machine-readable inventory of the software components inside your product: open-source libraries, their versions, suppliers, and the relationships between them. Think of it as an ingredients label for software. When a vulnerability is disclosed in a widely used library, an SBOM turns a frantic manual hunt into a lookup.

What the CRA specifically requires

The relevant text sits in Annex I, Part II of the Regulation. Manufacturers must identify and document the components in their products, "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 of the product."

Three things follow from that wording:

• Machine-readable, common format. Not a PDF or a spreadsheet you typed by hand. In practice that means CycloneDX (OWASP) or SPDX (an ISO standard) - the two formats with broad tooling support.
• Top-level dependencies are the floor, not the ceiling. That is the legal minimum. Covering transitive (indirect) dependencies is stronger practice and makes vulnerability response far more reliable.
• It is kept, not necessarily published. The SBOM forms part of your technical documentation, which you retain and make available to market surveillance authorities on request. You can choose to share it with customers, and increasingly they will ask.

CycloneDX or SPDX?

Either is acceptable. Pick the one your toolchain and your customers already use:

• CycloneDX - JSON or XML, strong ecosystem (Syft, Trivy, cdxgen). A reasonable default for modern container and package workflows.
• SPDX - JSON, RDF or tag-value; common in open-source and Linux Foundation projects, and an ISO/IEC standard.

What matters more than the choice is that the SBOM is generated by your build, not maintained by hand.

How to start this week

1. Generate one automatically. Add an SBOM step to your CI/CD so every release produces a fresh SBOM tied to that exact build.
2. Capture the essentials per component - name, version, supplier and licence - and aim to include transitive dependencies too.
3. Store it with the build and link it to the specific product version in your technical documentation.
4. Wire it into vulnerability monitoring so new CVEs are matched against your components automatically. An SBOM you never check is half the value lost.
5. Keep it current - regenerate on every release and retain past versions across the support period.

This is general guidance on the Cyber Resilience Act, not legal advice. Confirm specifics against the official sources below or with a qualified adviser.

Where to go next on CRA Facts

• Read the full SBOM under the CRA guide for the detail.
• Use the SBOM tool to run a readiness check and download a CycloneDX starter template.
• Not sure you are even in scope? Try the scope & class checker.
• Subscribe to The CRA Brief for updates as the harmonised standards land.

Sources: European Commission - CRA legislative summary, Regulation (EU) 2024/2847 (EUR-Lex).