BSI TR-03183: SBOM Quality Levels and CRA Compliance

The CRA mandates a Software Bill of Materials but leaves the technical detail to others. Annex I, Part II, point (1) requires a machine-readable SBOM covering at least the top-level dependencies of the product, and that is roughly where the regulation's specifics end. No field list. No format version floor. No advisory schema. Germany's Federal Office for Information Security (BSI) has filled the gap with BSI TR-03183, a three-part technical guideline that names exact format versions, lists every required field, and ties SBOM generation to vulnerability advisory publication. Treat it as the practical specification beneath the legal obligation, not a competing regulation.

What BSI TR-03183 is

BSI is Germany's national cyber security agency. Its Technical Guideline TR-03183 carries the full title Cyber Resilience Requirements for Manufacturers and Products, with separate parts numbered and versioned independently. The guideline targets manufacturers preparing for the EU Cyber Resilience Act, translating CRA Annex I obligations into concrete, testable technical requirements.

The three parts of the document, with the versions current at the time of writing:

Part	Version	Published	Scope
Part 1	v0.10.0	2025-09-12	General CRA cyber resilience requirements, derived from Annex I, Annex II, and Annex VII
Part 2	v2.1.0	2025-08-20	Software Bill of Materials (SBOM): formats, fields, generation, and updates
Part 3	v1.0.0	2025-08-20	Vulnerability reports and notifications, including CVD, security.txt, and CSAF advisories

Part 1 §1 frames the guideline as a transitional artefact:

"This Technical Guideline will be superseded in the current form as soon as its content is covered by the corresponding standardisation deliverables under the aforementioned standardisation request."

That sentence shapes how you should treat TR-03183. It is the BSI's read of how a CRA-compliant SBOM and vulnerability programme should look while CEN/CENELEC harmonised standards are still in draft. When those land, the harmonised standards take precedence; until then, TR-03183 is the most detailed publicly available specification aligned to CRA Annex I.

graph LR
    A[BSI TR-03183]
    A --- P1[Part 1
General CRA
requirements]
    A --- P2[Part 2
SBOM]
    A --- P3[Part 3
Vulnerability
reports]
    P2 --- F1[CycloneDX 1.6
or SPDX 3.0.1]
    P2 --- F2[Required, Additional,
and Optional fields]
    P3 --- C1[CSAF 2.0
advisories]
    P3 --- C2[security.txt
CSAF tag]
    style A fill:#008080,stroke:#005f5f,color:#fff
    style P1 fill:#e8f4f8,stroke:#008080,color:#333
    style P2 fill:#e8f4f8,stroke:#008080,color:#333
    style P3 fill:#e8f4f8,stroke:#008080,color:#333
    style F1 fill:#f8fafc,stroke:#008080,color:#333
    style F2 fill:#f8fafc,stroke:#008080,color:#333
    style C1 fill:#f8fafc,stroke:#008080,color:#333
    style C2 fill:#f8fafc,stroke:#008080,color:#333

The CRA gaps that TR-03183 fills

You can read the CRA's SBOM clauses end to end without learning what fields belong in your document, which format version satisfies the obligation, or how to publish the resulting advisories. TR-03183 fills three specific gaps.

Gap in the CRA text	What TR-03183 specifies
Annex I, Part II, point (1) requires an SBOM but lists no data fields	Part 2 §5.2 enumerates Required, Additional, and Optional fields for both the SBOM document and each component
The CRA says formats must be "commonly used and machine-readable" without naming any	Part 2 §4 states: "CycloneDX, version 1.6 or higher" or "System Package Data Exchange (SPDX), version 3.0.1 or higher"
Article 14 requires reporting actively exploited vulnerabilities to ENISA without specifying a public advisory format	Part 3 §4.2.8 and §5.1.6 align advisories on CSAF 2.0 and reference ISO/IEC 20153:2025

For the CRA-side detail of those obligations, see CRA SBOM requirements. For the deadline and penalty context that frames the urgency, see SBOM compliance deadlines and penalties.

Required, additional and optional fields in Part 2

Part 2 v2.1.0 does not use the words "Basic", "Standard", or "Comprehensive". Any vendor diagram or summary that presents three named "quality tiers" with those labels is introducing structure the specification does not contain. The conformance model in v2.1.0 is binary at the field level: a field is Required (always present), Additional (mandatory when the data exists), or Optional.

The three categories, mapped to spec sections:

Category	Spec section	What it means	Examples
Required for the SBOM itself	§5.2.1	Document-level fields that MUST always be present	Creator of the SBOM, Timestamp
Required for each component	§5.2.2	Component-level fields that MUST always be present	Component name, Component version, Distribution licences, Hash (SHA-512), Dependencies on other components, Filename, Executable property, Archive property, Structured property, Component creator
Additional for each component	§5.2.4	Mandatory if the data exists, omit otherwise	Source code URI, URI of the deployable form of the component, Other unique identifiers (CPE, purl), Original licences
Optional for each component	§5.2.5	MAY be included	Effective licence, Hash value of the source code, URL of the security.txt

Part 2 also imposes a recursive resolution requirement at §5.1: dependency resolution MUST be performed for each component included in the scope of delivery. That is the spec's answer to the CRA's vague "top-level dependencies" floor in Annex I, Part II, point (1): TR-03183 expects you to walk the tree, not stop at the immediate dependencies.

Field-by-field requirements

The full mapping of the candidate fields most teams ask about, against the v2.1.0 spec sections.

Field	Category	Spec section	Notes
Creator of the SBOM	Required (SBOM-level)	§5.2.1	Email or URL of the producer
Timestamp	Required (SBOM-level)	§5.2.1	ISO 8601
Component name	Required	§5.2.2	Always populated for every entry
Component version	Required	§5.2.2	Exact version, not a range
Component creator	Required	§5.2.2	Maps to "Supplier" in older language
Filename of the component	Required	§5.2.2	Often missing from default tool output
Dependencies on other components	Required	§5.2.2	Recursive per §5.1
Distribution licences	Required	§5.2.2	Licences as distributed
Hash of the deployable component	Required	§5.2.2	SHA-512
Executable property	Required	§5.2.2	Boolean: is the component executable?
Archive property	Required	§5.2.2	Boolean: is the component an archive?
Structured property	Required	§5.2.2	Boolean: structured payload indicator
Source code URI	Additional	§5.2.4	Mandatory when known
URI of the deployable component	Additional	§5.2.4	Mandatory when known
Other unique identifiers (CPE, purl)	Additional	§5.2.4	Mandatory when available; not unconditionally required
Original licences	Additional	§5.2.4	Pre-distribution upstream licence
Effective licence	Optional	§5.2.5	Result of licence reconciliation
Source code hash	Optional	§5.2.5	Hash of pre-build source
security.txt URL	Optional	§5.2.5	Pointer to vulnerability disclosure entry point

The most surprising row for many teams is Other unique identifiers (CPE, purl). Teams treat package URLs as the primary key of an SBOM. Under TR-03183 Part 2 v2.1.0, purl sits in the Additional category, mandatory only when the data exists. The unconditional component identifier is the SHA-512 hash of the deployable artefact, paired with name and version. If your tooling cannot compute purl for a private internal library, that does not break compliance. If it cannot compute the SHA-512, it does. See common SBOM mistakes for related field gaps.

CycloneDX and SPDX support

Part 2 §4 names the accepted formats and minimum versions:

"A newly generated or updated SBOM MUST be in JSON- or XML-format and a valid SBOM according to one of the following specifications in one of the specified versions: CycloneDX, version 1.6 or higher"

"System Package Data Exchange (SPDX), version 3.0.1 or higher"

The v2.1.0 release notes also document the upgrade path: v2.0.0 (2024-09-20) raised CycloneDX from 1.4 to 1.5 and SPDX from earlier versions to 2.2.1. v2.1.0 (2025-08-20) raised CycloneDX from 1.5 to 1.6 and SPDX from 2.2.1 to 3.0.1.

The practical implication is that tools shipping CycloneDX 1.4 outputs by default (still common in older CI configurations) are non-compliant under v2.1.0. CycloneDX 1.6 introduced refined cryptographic asset and ML BOM support; 3.0.1 of SPDX is a major rework with a new payload model. Your CI baseline needs an explicit --spec-version 1.6 flag or equivalent. For a side-by-side of the two formats and tool maturity, see CycloneDX vs SPDX.

A TR-03183-aligned CycloneDX 1.6 skeleton, with the document-level Required fields populated:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2027-01-15T10:00:00Z",
    "tools": [
      { "vendor": "Example", "name": "syft", "version": "1.10.0" }
    ],
    "authors": [
      { "name": "Example GmbH security team", "email": "security@example.de" }
    ],
    "component": {
      "type": "firmware",
      "name": "SmartSensor Pro",
      "version": "2.4.1",
      "supplier": { "name": "Example GmbH", "url": ["https://example.de"] },
      "purl": "pkg:firmware/example/smartsensor-pro@2.4.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.12",
      "purl": "pkg:generic/openssl@3.0.12",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [
        { "alg": "SHA-512", "content": "ddaf35a193617aba..." }
      ],
      "supplier": { "name": "OpenSSL Software Foundation" },
      "properties": [
        { "name": "executable", "value": "true" },
        { "name": "archive", "value": "false" }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:firmware/example/smartsensor-pro@2.4.1",
      "dependsOn": ["pkg:generic/openssl@3.0.12"]
    }
  ]
}

The authors, timestamp, and SHA-512 hashes entries are the document-level and component-level Required fields most often missing from CI defaults. Validate them with cyclonedx-cli validate --input-version 1.6 before treating an output as TR-03183 compliant.

How TR-03183 relates to CSAF and VEX

TR-03183 splits SBOM and vulnerability advisory mechanics across Part 2 and Part 3. The headline rule is simple: CSAF is recommended in Part 2 and operationally required for security.txt publication in Part 3. VEX is never mandated.

Mechanism	TR-03183 location	Strength	What it means
CSAF 2.0 as advisory format	Part 2 §8.1.14	Recommended	"The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile)"
security.txt CSAF tag	Part 3 §4.2.8 (b)	MUST	The security.txt statement that references CSAF documents must begin with the tag CSAF:
Provider metadata URI	Part 3 §4.2.8 (a)	SHOULD	Manufacturer SHOULD provide the URI of provider-metadata.json for CSAF documents
ISO/IEC 20153:2025	Part 3 §5.1.6	Reference	The international standard form of CSAF v2.0
VEX	Part 2 §1 and §8.1.14	Informational	VEX appears as a CSAF profile and as one of several "should" channels for vulnerability information

CSAF (Common Security Advisory Framework) version 2.0 is an OASIS Standard published 18 November 2022, with Errata 01 issued 26 January 2024. It defines a JSON schema for machine-readable security advisories. German CERTs (BSI-CERT, CERT-Bund) publish and consume CSAF by default, and the Secvisogram editor plus the OASIS CSAF validator are the standard tooling.

The Article 14 connection is more subtle than some commentary suggests. CRA Article 14 sets reporting deadlines for ENISA and the coordinating CSIRT (24 hours for the early warning, 72 hours for the vulnerability notification, and 14 days for the final report). It does not specify a public advisory format. TR-03183 Part 3 fills that gap: once you have notified ENISA, the CSAF document you publish under your security.txt is the operational artefact that customers ingest. Without CSAF tooling in place before 11 September 2026, you can still satisfy Article 14, but you will not satisfy the procurement language and security.txt expectations that flow from TR-03183.

VEX deserves a separate note. Part 2 §8.1.14 mentions VEX as a CSAF profile, and Part 2 §1 mentions it as one possible channel for "exchange of vulnerability information". Part 3 does not mention VEX at all. From a CRA perspective, VEX is useful for component-level not_affected statements that prevent alert fatigue when an SBOM contains a library with a known CVE that is not actually reachable from your code. It is not a TR-03183 obligation. Use it where it earns its keep.

Does TR-03183 apply outside Germany?

TR-03183 is a German national technical guideline issued by BSI, not an EU-wide regulation. None of its three parts assert applicability outside Germany. Part 1 §1 explicitly anticipates being superseded by CEN/CENELEC harmonised standards as those are published under the CRA standardisation request.

In practice, three forces make TR-03183 relevant to manufacturers based outside Germany.

First, the German market is the EU's largest, and German enterprise procurement increasingly references TR-03183 explicitly. If you sell to a German customer, expect TR-03183 language in their security questionnaires and supplier contracts.

Second, there is no alternative CRA-aligned specification of comparable detail at the time of writing. CEN/CENELEC harmonised standards under the CRA standardisation request are still in draft. TR-03183 is the closest available proxy.

Third, Part 1 of TR-03183 maps explicitly onto CRA Annex I, Annex II, and Annex VII. A manufacturer that builds documentation against TR-03183 will produce Annex VII content (point 2(b) and point 8 SBOMs in particular) that any EU market surveillance authority can read. See Annex VII technical documentation for the full content list.

Implementing TR-03183 voluntarily is a defensible engineering choice but not a legal requirement outside Germany. If your products do not include a hardware component, that is the end of the story. If they do, the same document can carry your HBOM entries alongside the software components.