SBOM requirements under the CRA (and BSI TR-03183-2)

In short: From 11 December 2027 the CRA requires an SBOM in a commonly used, machine-readable format covering at least your top-level dependencies. It belongs in your technical documentation; you don't have to publish it, but a market surveillance authority can ask for it. BSI TR-03183-2 is stricter: one SBOM per version, CycloneDX 1.6 or SPDX 3.0.1 or newer, recursive dependencies and SHA-512 hashes.

What the CRA requires

Among the vulnerability-handling requirements in Annex I Part II, manufacturers must:

“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”
Annex I, Part II, point (1)

The regulation defines an SBOM as “a formal record containing details and supply chain relationships of components included in the software elements of a product” (Article 3(39)). It names no format. CycloneDX and SPDX are both commonly used and machine-readable. The Commission may specify the format and elements by implementing act (Article 13(24)); we found none adopted as of 7 October 2026.

When it applies

The essential requirements in Annex I, including the SBOM, apply from 11 December 2027 (Article 71(2)). Products placed on the market before then are only covered if they are substantially modified after that date (Article 69(2)). Reporting under Article 14 is different: it already applies, to products on the market today. See the timeline.

Who sees it

The SBOM is part of your technical documentation (Annex VII, point 2(b)). You don't have to publish it. A market surveillance authority can ask for it with a reasoned request (Annex VII, point 8), and can request SBOMs for a Union-wide dependency assessment (Article 13(25)). If you choose to make it available to users, your user information must say where to find it (Annex II, point 9).

Technical documentation must be kept “for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer” (Article 13(13)). For an SBOM, that means keeping the one that matches each version you shipped, not just today's.

BSI TR-03183-2: the stricter reading

Germany's Federal Office for Information Security publishes technical guideline TR-03183, whose part 2 sets out SBOM requirements. It is not part of the CRA, but it is the most detailed public reading of what a good SBOM looks like. Version 2.1.0 (20 August 2025) requires, among other things:

Topic	CRA (Annex I)	BSI TR-03183-2 v2.1.0
Format	Commonly used, machine-readable	JSON or XML; CycloneDX 1.6 or higher, or SPDX 3.0.1 or higher
Depth	At least top-level dependencies	Recursive, at least down to the first component outside your scope of delivery
Versions	Not specified	A separate SBOM for each software version
Per component	Not specified	Creator, name, version, filename, dependencies, licences, a SHA-512 hash, and more
Vulnerabilities	Documented as part of vulnerability handling	Must not be in the SBOM itself

Meeting TR-03183-2 is a reasonable target if you sell in Germany or want headroom; the CRA's legal minimum is lower.

Practical notes

Generate the SBOM from what you actually build (lockfiles or the build itself), not from a manifest of version ranges.
Keep it with the version it describes. An SBOM you regenerate later from today's lockfile tells an authority nothing about what you shipped last year.
An SBOM is only useful if someone re-checks it: advisories for a component often appear long after you ship it.