CRA SBOM Requirements: What Goes Inside, Which Format Versions to Use, and Where VEX Fits
The Cyber Resilience Act requires a machine-readable SBOM, but the regulation does not list the fields it must contain or the format versions you must use. In practice most manufacturers fill that gap with Germany's BSI Technical Guideline TR-03183. This guide sets out what goes inside, which versions still count, and where VEX (vulnerability exploitability information) fits.
Key points
- The law sets the floor. Annex I, Part II(1) requires a machine-readable SBOM covering at least the top-level dependencies, kept in your technical documentation. It does not have to be public.
- BSI TR-03183 Part 2 supplies the detail. Version 2.1.0 (released 20 August 2025) lists required fields and accepted formats.
- Use current format versions: CycloneDX 1.6 or later, or SPDX 3.0.1 or later. Older versions do not meet TR-03183.
- VEX is optional. TR-03183 never mandates it.
- TR-03183 is a benchmark, not a legal presumption. Harmonised standards that will confer presumption of conformity are still in development.
This is general guidance, not legal advice.
If you are still deciding whether you need one, read do you need an SBOM for the CRA. If you need to generate one this week, see the SBOM tool guide. This page covers what the file should contain.
What the CRA itself requires
Annex I, Part II(1) of Regulation (EU) 2024/2847 asks manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies of the product. The SBOM belongs in the technical documentation, which you keep for ten years. Market surveillance authorities can request it. Customers cannot demand it by right.
That is all the regulation says. There is no field list and no named format. That is why TR-03183 matters.
What goes inside: the BSI TR-03183 view
BSI's guideline sorts fields into three groups rather than quality tiers. According to a summary of TR-03183 v2.1.0, any source that presents named "basic, standard, comprehensive" levels is not describing the current text.
| Group | Meaning | Examples |
|---|---|---|
| Required | Always mandatory | Document creator and ISO 8601 timestamp; per component: name, version, creator, filename, recursively resolved dependencies, distribution licences, SHA-512 hash, and yes/no flags for executable, archive and structured |
| Additional | Mandatory when the data exists | Source code URI, deployable URI, CPE or purl identifier, original licences |
| Optional | May be included | Anything else your tooling can supply |
Two points catch teams out. Dependencies must be resolved recursively, so a top-level-only list satisfies the CRA's minimum wording but not the guideline. Every component needs a SHA-512 hash, which many generators leave out by default.
Which format versions still count
TR-03183 v2.1.0 accepts:
- CycloneDX 1.6 or higher, or
- SPDX 3.0.1 or higher.
CycloneDX 1.4 and 1.5, and SPDX 2.x, are not compliant with the guideline. Check what your generator emits before you build a pipeline around it. Comparisons of the two formats are available from CRA Evidence and Sbomify.
Choosing between them
- CycloneDX is often the easier fit if your main use is vulnerability management and you want VEX in the same ecosystem.
- SPDX is often the easier fit if licence compliance is your main driver or your customers already ask for it.
- Either is acceptable. Pick one, pin the version, and keep it stable across releases. Do not maintain both by hand.
Where VEX fits
VEX statements say whether a known vulnerability in a component actually affects your product. TR-03183 treats VEX only as an optional channel, described as a CSAF profile. It is never mandated.
It is still useful. A "not affected" statement for a vulnerable component you do not call reduces noise for customers and your own team. But it is a discretionary extra, not a way to satisfy the SBOM requirement. Publish advisories through your coordinated vulnerability disclosure process either way.
Common mistakes
- Generating once and forgetting. The SBOM must reflect what you ship. Regenerate it for each release across your support period.
- Using an old format version because the tool default is older.
- Top-level only, when your customers or auditors expect resolved dependencies.
- Missing hashes or timestamps, the simplest fields to omit and the easiest to add.
- Treating TR-03183 as law. It is a widely used benchmark that BSI itself frames as transitional until EU harmonised standards exist.
What is still open
Harmonised standards for the CRA are still under development, so no SBOM format or field list has legal presumption of conformity yet. The sources above are vendor summaries. Read the official BSI guideline itself before you commit to a pipeline, and keep an eye on our deadlines page for standards news.
Tip: Add SBOM generation to your release pipeline now, then validate the output against TR-03183 once per quarter. See the readiness checklist.
Subscribe to The CRA Brief for a calm weekly update when the standards land.
Related reading
Three Weeks Into CRA Reporting: What Early Users Learned and What a "Disclosure Delay" Really Means
Article 14 reporting has been live for three weeks. Here is what early users of ENISA's Single Reporting Platform report, what a "disclosure delay" does and does not change, and the four things worth doing this week.
Does the Cyber Resilience Act Require Penetration Testing?
The CRA never mentions penetration testing. Annex I, Part II, point 3 requires "effective and regular" security tests - here is what that means in practice.
The CRA Notified Body Capacity Crisis: What Class II and Critical Manufacturers Should Actually Do
Zero CRA notified bodies are listed in NANDO as manufacturers head into the final compliance stretch. If your product is Class II or Critical, here is why the bottleneck exists, who it actually affects, and the sequenced plan that turns waiting into progress.