The software bill of materials, the SBOM, is the one Cyber Resilience Act duty that fits in a single sentence, and the one most often misquoted. Three claims appear in almost every summary: the SBOM must be published, it must list every dependency down to the last level, and the CRA prescribes a format. None of the three is in the Regulation.
This text takes apart the sentence the duty sits in and shows what follows for practice: how deep, in which format, where it is kept, who may see it, and why a manufacturer needs one before 11 September 2026 even though Annex I applies from 11 December 2027. If the CRA as a whole is still unfamiliar, start with What is the Cyber Resilience Act?
The sentence the duty sits in
The SBOM duty is Annex I Part II(1) of Regulation (EU) 2024/2847. Manufacturers shall "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 wording as published: Annex I Part II, vulnerability handling.
Five things are in that sentence, and each one carries weight.
1. The SBOM is a means, not an end. The duty is to identify and document vulnerabilities and components. The SBOM is the tool for it, "including by". A manufacturer that generates an SBOM and does nothing with it has the tool but has not met the duty. The duty is met when the SBOM is used to find vulnerabilities in the components.
2. At the very least the top level. "At the very least" is a floor, not a ceiling. A product that directly includes fifty libraries has an SBOM with at least fifty entries. Whether the transitive dependencies of those libraries belong in it, the Regulation does not say. In practice the question is whether a vulnerability match on the top level alone is still meaningful. In most software ecosystems it is not, because the known vulnerabilities sit deep in transitive dependencies.
3. Commonly used and machine-readable. No format is named. Commonly used and machine-readable means, today, two: SPDX and CycloneDX. A table in a text document is machine-readable in the literal sense but not commonly used. The Commission may specify the format and elements of the SBOM by implementing act (Article 13(24)). Until then, the German BSI's Technical Guideline TR-03183 Part 2 is the most precise description of what an SBOM should contain at minimum, and the German market surveillance authority will take its lead from it.
4. Per product, and therefore per version. The SBOM describes "the products". A product with digital elements is a specific piece of software in a specific version; the next version has different components. An SBOM that does not belong to a version describes nothing.
5. Vulnerabilities and components. The duty names both. The SBOM alone gives the components. The vulnerabilities come from matching the SBOM against vulnerability databases and vendor advisories. The two together are the documentation Annex I requires.
Where the SBOM lives, and who may see it
The Regulation mentions the SBOM in three further places, and the three answer the publication question.
So the answer is: the SBOM does not have to be published. It has to exist, it has to sit in the technical documentation, and it has to be produced to market surveillance on a reasoned request. Whether customers get it is the manufacturer's call. A manufacturer that does hand it out says where in the user information. The texts: content of the technical documentation and information and instructions to the user.
In practice, business customers increasingly demand the SBOM by contract, independently of the CRA. That is then a contract question, not a question of the Regulation.
The SBOM among the eight vulnerability-handling duties
Annex I Part II has eight items, and the SBOM is the first because the other seven do not work without it.
Treat the SBOM as a document for the binder and items 2 to 8 are missed. Treat it as the data source for continuous matching and all eight are met by the same process.
Why the SBOM is needed before 11 September 2026
Annex I applies to new products from 11 December 2027. The reporting obligations in Article 14 apply from 11 September 2026, including to products already on the market by then (Article 69(3)). Article 14 requires a manufacturer to report an actively exploited vulnerability within 24 hours of becoming aware of it.
Becoming aware presupposes that the manufacturer can recognise that a newly published vulnerability affects its product at all. For vulnerabilities in its own code, that is its own finding. For vulnerabilities in a third-party component, which is most of them, it is the match between a published vulnerability and the list of the manufacturer's own components. Without that list, the manufacturer learns it is affected when a customer or an attacker tells it, and the 24 hours are already running. What the two reporting duties require in detail: Article 14 is two reporting duties, not one.
The SBOM is therefore not a December 2027 task. It is the precondition for being able to report in September 2026.
Third-party components and suppliers
Article 13(5) obliges manufacturers to exercise due diligence when integrating components from third parties, including open-source components, so that they do not compromise the security of the product. The SBOM is the instrument that makes that diligence demonstrable. For purchased components with their own software, that means in practice requesting the supplier's SBOM and folding it into your own. A supplier that falls under the CRA itself from December 2027 must have one. Until then the request is a contract matter, and a manufacturer that writes it into supply contracts today has the full chain in 2027.
For open-source components there is no supplier to ask. The SBOM comes from the build, and the vulnerability information from public databases. That is the case machine-readable formats were made for.
What to do now
- Generate the SBOM from the build, not by hand. Package managers know the dependencies; an SPDX or CycloneDX generator runs in the build pipeline and produces one file per release.
- Store it per version, with a checksum. The SBOM sits next to the release artefact, with a hash, so it can later be shown which SBOM belongs to which shipment.
- Decide the depth and write down why. At least the top level. If transitive dependencies are included, say to which level and why. The reasoning belongs in the technical documentation.
- Set up the matching. SBOM against vulnerability databases and vendor advisories, continuously, with a person who judges the hits. That is the process that makes Article 14 possible.
- Request supplier SBOMs. Put it in the supply contracts, fold them into your own SBOM.
- Decide whether users get the SBOM. If yes, say where in the user information (Annex II(9)). If no, that is allowed.
There is also a way to keep the record without your own tooling: the Legalithm command cra ingest takes an SBOM or a signed declaration onto the record, as hypotheses, and cra watch joins the components to published advisories. Both are open source and run without an account: developer tools.
Frequently asked questions
Do I have to publish the SBOM? No. It belongs in the technical documentation and is produced to market surveillance on a reasoned request. Giving it to users is the manufacturer's decision; a manufacturer that does so names the location in the user information.
Which format is prescribed? None. What is required is a commonly used, machine-readable format. SPDX and CycloneDX meet that. The Commission may specify the format and elements by implementing act; in Germany, BSI TR-03183 Part 2 describes the expected content.
How deep does the SBOM have to be? At least the top-level dependencies. Deeper is not prescribed, but usually necessary for a meaningful vulnerability match. The chosen depth should be justified in the technical documentation.
Do I need one SBOM per version? Yes. The SBOM describes a product in a version. Every release that changes components has its own.
Does the duty apply to SaaS? Only insofar as the service is a remote data processing solution of a product with digital elements. For pure services the CRA does not apply; NIS2 may.
Is the SBOM sufficient evidence of vulnerability handling? No. It is the component list. The evidence for Annex I Part II is the process that works with it: matching, remediation, update, disclosure.
Sources
- Regulation (EU) 2024/2847, Annex I Part II, Annex II, Annex VII, Article 13: eur-lex.europa.eu/eli/reg/2024/2847/oj
- BSI, Technical Guideline TR-03183 Part 2, Software Bill of Materials: bsi.bund.de
- Every CRA obligation with its wording: Cyber Resilience Act obligations
This text is a cited starting point, not legal advice. The text of the Regulation prevails.
