
Manufacturers must know and document the components in their products. The CRA makes a software bill of materials part of that duty.
Annex I Part II 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 and machine-readable format, covering at the very least the top-level dependencies.
The SBOM is part of the technical documentation. Market surveillance authorities can request it. There is no obligation to publish it, although manufacturers may choose to make it available to users.
The CRA asks for a commonly used, machine-readable format. SPDX and CycloneDX are the two formats in wide use. The Commission may specify format and elements further by implementing act.
BSI Technical Guideline TR-03183, part 2, describes SBOM requirements in detail and is a useful reference for content and depth.
The SBOM belongs to vulnerability handling, which applies from 11 December 2027. Reporting since September 2026 already depends on knowing your components.
How to make the SBOM support vulnerability handling for the whole support period.
1
Created automatically from the build, so it matches what you ship.
2
A separate SBOM for every released version of the product.
3
Transitive dependencies included where you can, because vulnerabilities often sit there.
4
SBOMs requested from suppliers for the components and firmware you buy in.
5
Components matched against new vulnerabilities every day, not once a year.
6
A documented decision for each vulnerability: affected, not affected, or fixed.
As of October 2026. These guides explain the regulation in plain language and are not legal advice.
We set up SBOM generation and the vulnerability process around it. AITIGRITY monitors the components in your SBOM for the product lifetime.
Tell us about your product and the rule you are facing. You talk to an engineer from the first call.