SBOM Requirements for the CRA: A Guide to BSI TR-03183
| Interlynk
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.
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.