The Regulation does not choose for you
Annex I Part II point 1 requires an SBOM "in a commonly used and machine-readable format". It names no standard, no version and no profile. That is deliberate: naming a format in primary legislation would freeze it for a decade.
In practice "commonly used and machine-readable" means CycloneDX or SPDX. Both are recognised standards with tooling, both are machine-readable by any reasonable test, and either is defensible to a market surveillance authority. There is no wrong answer between them, and anyone telling you the CRA mandates one is selling something.
How they actually differ
The honest summary: CycloneDX is usually easier to produce from a modern toolchain and fits the CRA’s security framing more naturally. SPDX turns up more often when a large customer asks you for one, because their procurement process standardised on it years ago, sometimes citing the ISO number.
| CycloneDX | SPDX | |
|---|---|---|
| Steward | OWASP | Linux Foundation, and ISO/IEC 5962 |
| Origin | Built for security use — vulnerability and supply-chain first | Built for licence compliance first, security added later |
| Serialisations | JSON, XML, Protobuf | JSON, YAML, RDF, tag-value |
| Typical source | Modern build tooling and security scanners | Enterprise procurement, and anything in the Linux ecosystem |
| Vulnerability data | Carries it natively, and pairs with VEX | Possible, but less idiomatic |
Choose on who is asking, not on the Regulation
For the CRA obligation alone, pick whichever your build tooling emits and move on. The provision is satisfied either way.
The real decision is downstream. If an enterprise buyer, a defence integrator or a public-sector tender has already told you which format they accept, produce that one — you will have to eventually, and maintaining one document is cheaper than reconciling two that drift.
- No external requirement: use CycloneDX. It is the lower-friction default and pairs cleanly with VEX when you need to say "not affected".
- A customer has specified a format: use theirs, and treat the CRA obligation as satisfied by the same artefact.
- Both are demanded: generate one canonically and convert, rather than maintaining two by hand. Converted documents lose fidelity, so keep the generated one authoritative.
The two things that actually get checked
Format is the question people ask. It is not the question that decides whether the SBOM does its job.
- Does it describe the artefact you actually shipped? An SBOM generated from a developer machine, or from a branch, does not evidence the release. Generate it in CI from the exact build you publish.
- Is it current? Annex I Part I point 2(a) is tested at the moment the product is made available. An SBOM from last quarter evidences a vulnerability position that is no longer yours.
Depth: the floor is not the target
The provision requires "at the very least the top-level dependencies". Read literally, a list of your direct dependencies complies.
It is also close to useless, and no harder to beat. Lockfiles give you the full transitive tree for free, and vulnerabilities do not respect dependency depth — the exploitable one is usually four levels down in something you have never heard of. A top-level-only SBOM satisfies the letter of Part II point 1 while leaving you unable to answer Part I point 2(a).