Required: a machine-readable software bill of materials (SBOM) per product, covering at least top-level dependencies, used to identify and document components and vulnerabilities. Not required by the text: public release, a named format or transitive depth. Decide those by risk.
What the regulation says
Annex I Part II(1) tells 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”.
The same Part requires the manufacturer to remediate vulnerabilities without delay, test regularly, disclose fixed vulnerabilities, have a coordinated disclosure policy and distribute updates securely. The SBOM is the inventory that makes the rest possible.
What it does not say
- It does not name CycloneDX, SPDX or any other format. It says commonly used and machine-readable.
- It does not require transitive dependencies. It sets top-level dependencies as a minimum. Your risk assessment may need more.
- It does not require you to publish the SBOM. Annex VII provides it to authorities on reasoned request, and Annex II lets you decide whether to tell users where to find it.
SBOM generation: binaries and firmware
Source-based SBOMs miss components added at build or packaging time, vendor binaries and statically linked libraries. For firmware and third-party software without source access, SBOM generation from the compiled binary or firmware image gives a more accurate picture of what is shipped. CRAprepared helps manufacturers choose and introduce suitable SBOM tooling, including binary analysis; see the Slovenian page on SBOM management solutions.
An archive of SBOMs per release, the quality checks applied, and the vulnerability decisions made against them (for example as VEX statements).
Producing an SBOM to answer a customer questionnaire and calling the requirement met. The requirement is to identify and document components so vulnerabilities can be handled.
We help manufacturers turn this requirement into a process and evidence.
Related guidance
- Cyber Resilience Act (CRA): what it is and what it requires
- CRA vulnerability management requirements
This guidance explains the regulation and gives practical recommendations. It is not legal advice. Regulatory facts and recommendations are labelled separately. See our editorial policy (Slovenian): editorial policy.