BSI TR-03183: SBOM Quality Levels and CRA Compliance

The CRA mandates a Software Bill of Materials but leaves the technical detail to others. It 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

BSI 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
The CRA requires an SBOM but lists no data fields (Annex I Part II (1))	TR-03183 enumerates the 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	TR-03183 names them: "CycloneDX, version 1.6 or higher" or "System Package Data Exchange (SPDX), version 3.0.1 or higher"
The CRA requires reporting actively exploited vulnerabilities to the coordinating CSIRT and ENISA without specifying a public advisory format (Article 14)	TR-03183 aligns advisories on CSAF 2.0 and references ISO/IEC 20153:2025

For the CRA-side detail of those obligations, see CRA SBOM requirements. For the Article 14 reporting clock that makes current component data operationally important, see CRA vulnerability and incident reporting.

Required, additional and optional fields

TR-03183 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 field categories:

Category	What it means	Examples
Required for the SBOM itself	Document-level fields that MUST always be present	Creator of the SBOM, Timestamp
Required for each component	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	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	MAY be included	Effective licence, Hash value of the source code, URL of the security.txt

TR-03183 also requires recursive dependency resolution: you resolve dependencies for every component in the scope of delivery, not just the immediate ones. That is its answer to the CRA's vague "top-level dependencies" floor in Annex I Part II (1): walk the whole tree.

Field-by-field requirements

The candidate fields most teams ask about, with their v2.1.0 category.

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

TR-03183 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 covers SBOM and vulnerability advisory mechanics together. The headline rule is simple: CSAF is recommended for advisories and operationally required for security.txt publication. VEX is never mandated.

Mechanism	Strength	What it means
CSAF 2.0 as advisory format	Recommended	"The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile)"
security.txt CSAF tag	MUST	The security.txt statement that references CSAF documents must begin with the tag CSAF:
Provider metadata URI	SHOULD	Manufacturer SHOULD provide the URI of provider-metadata.json for CSAF documents
ISO/IEC 20153:2025	Reference	The international standard form of CSAF v2.0
VEX	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 notification, and a final report 14 days after a fix is available for an actively exploited vulnerability, or one month after the notification for a severe incident). It does not specify a public advisory format. TR-03183 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. TR-03183 mentions VEX only as a CSAF profile and as one possible channel for sharing vulnerability information; it is never required. 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, and it does not claim to apply outside Germany.

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, no other CRA-aligned specification comes close to this level of detail today, so manufacturers reach for TR-03183 as the practical reference.

Third, TR-03183 is built around the same CRA annexes you already have to satisfy: Annex I, Annex II, and Annex VII. Documentation prepared to TR-03183 produces the technical evidence an EU market surveillance authority expects in your Annex VII file, the SBOM included. Our technical documentation guide lists everything Annex VII has to contain.

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.