CRA topic guide

SBOM (Software Bill of Materials) under the CRA

Last updated · 8 Jun 2026

Under the EU Cyber Resilience Act, every manufacturer of a product with digital elements must create and keep a Software Bill of Materials (SBOM) - a machine-readable list of the software components and dependencies in the product. It does not have to be public, but it must be in your technical documentation and shown to authorities on request. This is mandatory from 11 December 2027.

TL;DR

  • An SBOM is an "ingredients label" for your software: a machine-readable inventory of components and dependencies.
  • The CRA requires it in Annex I, Part II(1) - covering at least the top-level dependencies.
  • It must be machine-readable (e.g. CycloneDX or SPDX) and kept in your technical documentation.
  • It does not have to be published, but market surveillance authorities can demand it.
  • It is the backbone of vulnerability handling: when a CVE drops, your SBOM tells you if you are affected.
Get the CRA ChecklistCheck if you are in scope

Overview

What it is

A Software Bill of Materials (SBOM) is a formal, machine-readable record of the components that make up a piece of software, including open-source libraries, their versions, and the supply-chain relationships between them. Think of it as an ingredients list: when a new vulnerability is disclosed in a popular library, an SBOM lets you (and your customers and regulators) answer "are we affected?" in minutes rather than weeks. The two dominant open formats are CycloneDX (OWASP) and SPDX (Linux Foundation / ISO/IEC 5962).

The regulation

What the CRA requires

  • Annex I, Part II(1) requires manufacturers to identify and document vulnerabilities and components, "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".
  • The SBOM forms part of the technical documentation (Annex VII), which must be kept for 10 years and provided to market surveillance authorities on request.
  • The CRA does not oblige you to publish the SBOM, nor to cover every transitive dependency - top-level is the legal minimum, though going deeper is good practice.
  • The SBOM must be kept up to date across the support period as components change.

How to comply

How to comply

  1. Pick a format and standard: CycloneDX or SPDX, generated as part of your build, not hand-written.
  2. Automate generation in CI/CD so every release produces a fresh SBOM tied to that exact build.
  3. Capture at least top-level dependencies - version, supplier and licence - and ideally transitive ones too.
  4. Store the SBOM in your technical documentation and link it to the specific product version.
  5. Wire the SBOM into vulnerability monitoring so new CVEs are matched against your components automatically.
  6. Keep it current: regenerate on every release and retain versions for the support period.

Watch out

Common mistakes

  • Treating the SBOM as a one-off document instead of a build artefact regenerated every release.
  • Listing only your own code and omitting open-source and third-party components.
  • Generating an SBOM but never connecting it to vulnerability monitoring - half the value lost.
  • Assuming the SBOM must be public and over-disclosing, or assuming it is optional because it is not public.

FAQ

Common questions

Does the CRA SBOM have to be public?
No. The CRA does not require you to publish your SBOM. It must be part of your technical documentation and provided to market surveillance authorities on request, and you may choose to share it with customers.
Which SBOM format does the CRA require?
The CRA only says "a commonly used and machine-readable format". In practice that means CycloneDX or SPDX. The Commission and standards bodies are aligning on these formats.
How deep must the SBOM go?
The legal minimum is the top-level dependencies of the product. Covering transitive dependencies is stronger practice and makes vulnerability response far more reliable, but is not strictly mandated.
When is the SBOM requirement enforceable?
The SBOM obligation applies with the full CRA from 11 December 2027. Building the capability now is sensible because it underpins the reporting duties that start 11 September 2026.

Related guides

More CRA topic guides

Security by design

Security by design under the CRA

Security by design means building in security from the first design decision, proportionate to the product's risk.

Secure by default

Secure by default under the CRA

Secure by default means the out-of-the-box configuration is the safe configuration.

Secure software development

Secure software development under the CRA

A secure software development lifecycle (SDLC) is implied throughout the CRA's essential requirements.

Back to the CRA overview or see all guides.

This is guidance, not legal advice

This guide explains how the Cyber Resilience Act approaches sbom, but it is not legal advice. For decisions specific to your business or product, confirm with the official sources we link or a qualified adviser.

Sources

  1. [1]European Commission - CRA legislative summaryretrieved 8 Jun 2026
  2. [2]Regulation (EU) 2024/2847 - full text (EUR-Lex)retrieved 8 Jun 2026
  3. [3]European Commission - Cyber Resilience Actretrieved 8 Jun 2026

The CRA Brief

Stay current on CRA guidance

We watch Brussels so you don't. Plain-English CRA updates, free.

No spam. Unsubscribe anytime.