BSI TR-03183: SBOM Data Fields and Formats for the EU CRA
| Interlynk
The CRA SBOM requirements are quick to state and easy to under-deliver on: you need a machine-readable SBOM in a commonly used format, covering at least your product's top-level dependencies. The CRA also requires manufacturers to maintain ongoing vulnerability-handling and documentation processes, and market-surveillance authorities can request the documentation needed to demonstrate compliance. Germany's BSI TR-03183 goes into considerably more technical detail on SBOM formats, fields, and granularity than the CRA itself.
The EU Cyber Resilience Act (Regulation (EU) 2024/2847) became law in December 2024. It requires a software bill of materials for any product with digital elements sold in the EU. But the law sets a low bar on detail. Your SBOM has to be machine-readable and cover at least the product's top-level dependencies. The exact format and the minimum data fields get defined later, by the European Commission, through implementing acts.
Until those rules arrive, Germany's BSI has the most detailed answer to what a CRA-grade SBOM should actually contain. Its Technical Guideline TR-03183 turns the CRA's general language into specific requirements, and Part 2 covers the SBOM.
First, what TR-03183 is not
It is not law. The BSI says plainly that the guideline is not binding, cannot serve as a presumption of conformity, and will be replaced by harmonized European standards once those exist. Following it to the letter does not automatically make you CRA-compliant.
What it gives you is the clearest preview available of where the formal rules are heading, written as requirements you can test against today. The guideline now comes in several parts:
Part | Scope |
|---|---|
Part 1 | General requirements for manufacturers and products |
Part 2 | Software Bill of Materials (the focus of this guide) |
Part 3 | Vulnerability reports and notifications |
Module H | Conformity based on full quality assurance |
Part 2 is on version 2.1.0, published August 2025. Two things to know about versions:
To stay aligned, use the current version. The one before it is acceptable for up to six months after a new release ships.
BSI revises the guideline regularly. Check bsi.bund.de for the latest before you rely on any single version.
Format requirements
An SBOM has to be machine-processable. That means JSON or XML, in one of two formats:
Format | Version mapped in v2.1.0 |
|---|---|
CycloneDX | 1.6 |
SPDX | 3.0.1 |
Version 2.1.0 added field-by-field mappings for both formats, which cut down the old guesswork about how each required value should appear. BSI also publishes a CycloneDX property taxonomy on GitHub for the fields specific to the guideline.
Generate a separate SBOM for every software version. You only regenerate an SBOM for an existing version when new component information turns up, or when you correct an error in the data.
Content requirements
The guideline separates what the document needs from what each component needs.
At the document level:
Identify the creator, by email, or a URL as a fallback.
Record the date and time the component data was collected.
For each component:
Field | Requirement |
|---|---|
Name and version | Required. SemVer or calendar versioning preferred. |
Dependencies | Required. Record the components each one relies on, not just a flat list. |
License | Required. Use the SPDX identifier. Fallbacks are defined for licenses not in the SPDX list. |
Hash | Required. SHA-256. |
Source/executable URI, CPE, PURL | Optional, but useful for matching and traceability. |
Version 2.1.0 also reviewed the licensing section and added handling for virtual and referenced components. Those cover parts of a product that aren't a simple shipped library.
Where SBOMs and vulnerabilities meet
TR-03183 keeps vulnerability data out of the SBOM on purpose. To say which flaws affect a product, and whether they're actually exploitable, it points to CSAF with a VEX profile. The two documents do different jobs:
Document | Answers |
|---|---|
SBOM | What components are in the software |
VEX / CSAF | Which vulnerabilities apply, and whether they're exploitable |
The reason for the split is timing. A component inventory barely moves between releases. Vulnerability status changes daily. Separate documents let each one update on its own clock.
The split is also where the hard part begins. Two things have to be right before an SBOM produces usable vulnerability intelligence:
Clean, machine-matchable identifiers (CPE or PURL) on every component.
Complete, accurate dependency relationships.
The second one trips up most tools. Plenty of generators emit a list of components and quietly drop the structure connecting them. Once those relationships are gone, answering "does this new CVE affect us, and how far down does it reach" becomes guesswork. A compliant SBOM is the starting point. What it's actually worth in an incident depends on the depth and accuracy underneath it.
Does your product class change what the SBOM must show?
Most products fall in the default category and self-assess. The CRA also names two higher groups. Important products (Annex III) split into Class I, which includes password managers, VPNs, and network management systems, and Class II, which covers firewalls and intrusion detection systems. Critical products (Annex IV) sit above both and include hardware security modules and smart meter gateways. The technical descriptions for each were set out in Commission Implementing Regulation (EU) 2025/2392.
Your class does not change the baseline SBOM content. It changes who reads it. A default product can self-assess, so you are your own reviewer. Class II and critical products need a notified body, and Class I needs one too unless you have applied the relevant harmonized standards. Once an outside assessor is reading your technical documentation, a top-level-only SBOM that you could have waved through yourself is a lot harder to defend. The higher your class, the less room there is to under-document.
How the reporting clock uses your SBOM
The CRA's reporting duties have applied since 11 September 2026, and this is where an SBOM does real work rather than sitting in a folder. Two clocks can start. If a vulnerability in your product is being actively exploited, you have 24 hours to send an early warning, 72 hours to file a full notification, and 14 days after a fix or workaround is available to submit a final report. If you have a severe incident instead, the first two steps are the same, but the final report is due one month after the 72-hour notification. The clock starts when you become aware, not when you have confirmed every detail.
That is a tight window to answer one question: are we affected, and where? When the next Log4Shell lands, a team with a current, queryable SBOM can search every product and shipped version in minutes. A team without one is grepping through build logs while the 24-hour clock runs. The SBOM is what makes the deadline survivable.
What getting the SBOM wrong costs
The CRA backs its requirements with real fines, and they run on tiers. The SBOM sits in the top one. Breaching the essential requirements or the manufacturer obligations in Articles 13 and 14, which is where SBOM maintenance, vulnerability handling, and technical documentation all live, can cost up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. Lesser breaches carry lower ceilings: €10 million or 2% for other obligations, and €5 million or 1% for giving an authority incorrect or misleading information. Regulators weigh proportionality, so a first slip is unlikely to draw the maximum. But the SBOM is not a low-stakes checkbox. It is filed under the same duty that carries the heaviest penalty.
How this fits your CRA work
For any manufacturer selling into Germany, TR-03183 is the reference to design against, and the best signal available for the EU-wide rules still being written. The SBOM is one piece of EU Cyber Resilience Act compliance, which also covers vulnerability reporting, secure-by-design, and technical documentation across the product's support period.
Interlynk generates, ingests, and enriches SBOMs in CycloneDX and SPDX, resolves the full dependency tree with relationships intact, and keeps components and vulnerabilities linked. The SBOM you build for the guideline stays useful for the vulnerability management it's meant to support.
Frequently asked questions
Does the CRA require top-level or full dependencies?
The legal minimum is the top-level dependencies. In practice a top-level-only SBOM rarely holds up when a customer or an auditor reads it, so most manufacturers document the full transitive dependency tree to show the product is genuinely covered.
What SBOM format does the CRA require?
The CRA text asks only for a commonly used, machine-readable format. Germany's BSI TR-03183-2 v2.1.0, the reference specification, names CycloneDX 1.6 or later and SPDX 3.0.1 or later as the accepted formats.
When do the CRA's SBOM requirements apply?
The CRA became law in December 2024 and applies in stages. The vulnerability-reporting obligations under Article 14 have applied since 11 September 2026, and the full requirements, including the SBOM, apply from 11 December 2027.
Do you have to publish your SBOM under the CRA?
No. The SBOM is kept in the technical documentation, not published. Market-surveillance authorities can request it, and you can share it with customers on your own terms.
Does BSI TR-03183 apply to the CRA?
Yes. BSI TR-03183-2 is the German technical guideline that operationalizes the CRA's SBOM requirement, defining the mandatory data fields, the accepted formats, and the expected depth. It is the practical reference for meeting the CRA on SBOMs.