Check an SBOM against the CRA and BSI TR-03183-2

The requirement sits in the vulnerability handling half of Annex I. Part II, point (1) asks 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 of the products”.

That is the whole of it. The regulation does not name CycloneDX or SPDX, and it sets no field list, though the Commission may specify the format and elements by implementing act (Article 13(24)). FOSSA’s write-up of the CRA’s SBOM requirements (on fossa.com, opens in a new tab) covers how teams are reading the minimum.

The SBOM is part of the technical documentation (Annex VII, point 2(b)), and a market surveillance authority can ask for it with a reasoned request (Annex VII, point 8). You are not required to publish it: if you choose to make it available to users, the user information must say where (Annex II, point 9). And the SBOM is a means, not the end. When you find a vulnerability in a component, you must report it to whoever maintains that component (Article 13(6)).

Both are commonly used and machine-readable, so either meets the CRA’s format wording. CycloneDX, from OWASP, was standardised as ECMA-424 from version 1.6 and is built around security use: vulnerabilities, services and dependency graphs. SPDX, from the Linux Foundation, grew out of licence compliance; version 2.2.1 is the international standard ISO/IEC 5962:2021, and version 3.0 rebuilt it as a linked-data model with profiles for security and more.

Where the choice is made for you is BSI TR-03183-2. Version 2.1.0 requires CycloneDX 1.6 or later, or SPDX 3.0.1 or later, in JSON or XML. An SPDX 2.3 document can meet the CRA’s wording but not the guideline, which requires SPDX 3.0.1 or later.

The German Federal Office for Information Security’s technical guideline is not EU law, and nothing in the CRA points to it. It matters because it is the most detailed published SBOM specification written with the CRA in mind, and because German customers can ask for SBOMs that follow it. Version 2.1.0 was published on 20 August 2025.

It also asks for more depth than the CRA: dependencies resolved recursively for everything you deliver, down to and including the first component outside your scope of delivery, and the SBOM carrying the information available at build time.

For the SBOM itself

For each component

Where the information exists, the guideline requires a URI for the SBOM and, per component, the source code URI, the URI of the deployable form, other unique identifiers such as a Package URL or CPE, and the original licences. Only the most recent version of the guideline counts, though the one before it may still be used for six months after a new one appears.

Does the CRA require a specific SBOM format?

No. It asks for a commonly used and machine-readable format. In practice that means CycloneDX or SPDX, in any of their serialisations. A spreadsheet or PDF is not a commonly used SBOM format.

Do I have to publish my SBOM?

No. It goes in the technical documentation and to a market surveillance authority on request, including for an EU-wide dependency assessment of a product category (Article 13(25)). Publishing it to users is optional.

Does the SBOM need transitive dependencies?

The CRA sets the floor at top-level dependencies. BSI TR-03183-2 asks for full recursive resolution within your scope of delivery. Many teams generate the full tree anyway, because vulnerabilities rarely sit only in direct dependencies.

When does the SBOM requirement apply?

With the rest of Annex I, from 11 December 2027. The reporting obligations that applied from 11 September 2026 do not themselves require an SBOM, though one makes finding an affected product much faster.

How does this compare with the US minimum elements?

On 29 July 2026 CISA, the NSA, the FBI and international partners, BSI among them, published the 2026 Minimum Elements for an SBOM, which update and replace the 2021 NTIA minimum elements. The 2026 list adds component hash and algorithm, component licence, SBOM tool name and version, SBOM generation context, SBOM version, data format and an author signature to the 2021 core of name, version, identifiers, producer, dependency relationship, author and timestamp. BSI TR-03183-2 overlaps with it, and goes further on SHA-512 specifically, filenames and the executable, archive and structured properties.