SBOM and the CRA: what the Regulation actually requires
The software bill of materials is one of the few CRA requirements that translates into a precise deliverable. It is also the one surrounded by the most misconceptions — starting with its scope.
What the Regulation says
The requirement sits in Annex I, Part II, §1: the manufacturer draws up a software bill of materials in a machine-readable format, covering at least the top-level dependencies of the product.
Two phrases matter. "At least": the floor is set, not the ceiling. "Top-level dependencies": the text does not require walking recursively through the entire transitive dependency tree. Many teams stall on a completeness goal the Regulation does not set.
What it is actually for
- Knowing within minutes whether a published vulnerability affects you. Without an inventory, the answer takes days.
- Feeding the technical documentation (Annex VII), which must describe the product's components.
- Supporting the vulnerability handling process of Annex I, Part II — identification, remediation, coordinated disclosure.
- Answering customers, who increasingly ask for it early in tender processes.
Which format?
The Regulation sets the minimum content and requires a machine-readable format. Two tooled standards dominate today: CycloneDX (OWASP) and SPDX (Linux Foundation). Both can be generated automatically by common build pipelines.
Choosing a format is a tooling decision, not a compliance one. What matters is that the bill of materials is accurate, current and usable.
Three common mistakes
Confusing the bill of materials with compliance
A perfect SBOM demonstrates nothing on its own. It is one element of the technical documentation, not a certificate.
Generating it once
A frozen bill of materials becomes wrong at the first update. It must be produced by the build pipeline, not maintained by hand.
Forgetting the firmware
On an industrial product, most of the risk sits in embedded components and third-party firmware libraries, not in the supervision application.
Where to start
- Generate a first bill of materials automatically from the build pipeline, even an incomplete one.
- Check that it covers the top-level dependencies of the product as shipped, firmware included.
- Plug vulnerability monitoring into that list.
- Attach the bill of materials to the technical documentation, and regenerate it with every release.
Frequently asked questions
Does the SBOM have to be public?
The Regulation requires drawing it up, keeping it current and making it available to market surveillance authorities on request. It does not make publication a condition of compliance.
Must transitive dependencies be included?
The requirement covers at least the top-level dependencies. Going further is useful for your own monitoring, but it is not the threshold set by Annex I.
Is an SBOM enough to be CRA-compliant?
No. It is one of the expected elements, alongside the risk assessment, security-by-design requirements, the vulnerability handling process, the technical documentation and the conformity assessment.
How often should it be updated?
With every product release whose software content changes. In practice that means generating it automatically at build time rather than maintaining it manually.
Source: Regulation (EU) 2024/2847, Annex I, Part II.