The SBOM requirement in the CRA is one sentence long. Annex I Part II point 1 asks manufacturers to identify and document the vulnerabilities and components in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies.

That sentence leaves room for interpretation. Here is how to read it, and what an assessor is likely to check.

What the regulation asks for

  • A machine-readable format that is commonly used. In practice SPDX or CycloneDX, as JSON or XML. A PDF list does not meet the requirement, and a home-made spreadsheet is unlikely to count as a commonly used format.
  • At least the top-level dependencies. If your firmware uses library A, and library A uses library B, A is top-level and B is transitive. The legal minimum is A.
  • Part of the technical documentation. The SBOM belongs in the file you keep for the authorities, and you give it to a market surveillance authority on reasoned request (Annex VII point 8).
  • Kept for at least ten years after the product is placed on the market, or for the support period if that is longer (Article 13(13)).

The Commission may specify the format and elements of the SBOM in an implementing act (Article 13(24)). Until then, good-practice references such as BSI TR-03183-2 and the NTIA minimum elements are a sensible basis.

What it does not ask for

You do not have to publish your SBOM. The CRA does not require publication. You may share it with users, and if you do, the user information must say where (Annex II point 9). Many manufacturers give it to business customers under a confidentiality agreement and keep it internal otherwise. Whatever you choose, state the same choice in the SBOM procedure, the technical file and the user information. An assessor will compare them.

Top-level is the minimum. Aim for more.

Many of the serious vulnerabilities of the last years sat in transitive components that nobody had listed. A top-level SBOM meets the letter of the law but leaves you blind exactly where it hurts. If your tooling can produce the full dependency tree, use it.

One SBOM per released version

An SBOM describes a build, not a product. When version 4.0.1 ships with a patched library, its SBOM differs from 4.0.0. Keep one SBOM per released version and store it with the release. When a new vulnerability appears, you need to answer for every version still in the field, not only the latest.

Why it matters today, not in 2027

The SBOM requirement applies from 11 December 2027. The need for it starts earlier. Article 14 reporting has applied since 11 September 2026, and its first question is always the same: which of our products and versions contain the affected component, and is the vulnerable function reachable? With one SBOM per version, that takes minutes. Without it, it can take days, and the 24-hour clock does not wait.

When a component is present but cannot be exploited in your product, record that analysis as a VEX statement. It is the evidence that you looked and why you did not report.

Where firmware SBOMs go wrong

Scanners work well on package manifests. Embedded software rarely consists only of package manifests.

  • Binary blobs from chip vendors. Radio firmware, bootloaders and closed drivers often arrive as binaries without metadata. Add them by hand from the supplier's information and note the source.
  • Vendored code. A library copied into your repository years ago, perhaps with local patches, is invisible to tools that read package managers. Search for it and list it with its original version.
  • Static linking. Code linked into a single image leaves no separate files to detect. Generate the SBOM from your build system, which knows what it linked, not from the finished image alone.
  • The backend. If your cloud service is part of the product (remote data processing), consider including its components in your SBOM scope.
  • Supplier components. Ask suppliers for SBOMs of what they deliver. It is part of your due diligence on components (Article 13(5)), and from December 2027 suppliers who sell components separately will need them anyway.

What a useful SBOM entry contains

For each component: name, version, supplier, a unique identifier (a package URL or CPE), a cryptographic hash, the licence and its dependency relationship. For the SBOM as a whole: product and version, author, creation time, and the tool and version that produced it. The unique identifier matters most, because it is what lets you match the SBOM against vulnerability databases automatically.

A short checklist

  1. Choose SPDX or CycloneDX, and decide the depth: top-level as the minimum, full tree as the target.
  2. Generate the SBOM in the build pipeline, from the same source as the release.
  3. Add binary and vendored components by hand, with their source.
  4. Keep one SBOM per released version, unchanged, for at least ten years.
  5. Match all SBOMs of supported versions against vulnerability sources, at least daily.
  6. Record non-exploitable findings as VEX statements.
  7. Decide whether and how you share the SBOM, and say the same thing in every document.

This article explains Regulation (EU) 2024/2847 in plain words. It is not legal advice.