The obligation, in full
Annex I Part II point 1 requires manufacturers to identify and document vulnerabilities and components contained in the product, "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".
That sentence answers most of the questions people ask about SBOMs under the CRA.
Which format?
The Regulation does not name one. "Commonly used and machine-readable" is universally read as CycloneDX or SPDX, and either is defensible. CycloneDX tends to be easier to produce from modern build tooling; SPDX turns up more often in enterprise procurement.
What is not acceptable is a spreadsheet, a PDF table, or a list in your documentation. Machine-readable means a machine can read it.
How deep does it have to go?
At the very least the top-level dependencies. That is the floor, not the target.
In practice a transitive SBOM is easier to produce than a top-level-only one — lockfiles give you the full tree for free — and it is far more useful for the requirement that actually bites, which is Annex I Part I point 2(a): no known exploitable vulnerabilities. Vulnerabilities do not respect dependency depth.
Do you have to publish it?
No. Two separate provisions are often confused here.
- Annex VII point 8: you provide the SBOM to a market surveillance authority on a reasoned request, where it is necessary for checking compliance. This is an obligation, but it is on request.
- Annex II point 9: if you decide to make the SBOM available to users, you must tell them where to find it. This is conditional on your own decision to publish.
- Neither requires publication. Both require you to have it.