SBOM Requirements under the Cyber Resilience Act: Formats, Contents and Archiving

The Software Bill of Materials — or SBOM — is not optional under the Cyber Resilience Act (Regulation (EU) 2024/2847). It forms part of the mandatory technical documentation that manufacturers of products with digital elements are required to maintain. Full product requirements apply from 11 December 2027, but waiting until then to tackle SBOM compliance is a mistake: a reliable bill of materials requires working development and supply-chain processes that cannot be stood up overnight.

In practice, many organisations have started SBOM implementation but are still at an early pilot or trial stage. The gap between "we have started" and "we are CRA-ready" is real. This article explains what a CRA-compliant SBOM must actually contain, which format to choose, and why the archiving obligation deserves more attention than it typically receives.

What is an SBOM — and why does the CRA require one?

An SBOM is a machine-readable inventory of all software components in a product: libraries, frameworks, dependencies, licences, versions and their relationships. The CRA makes it a tool for two core obligations:

• Vulnerability handling throughout the support period: Without complete component knowledge, manufacturers cannot reliably determine whether a newly disclosed vulnerability (CVE) affects their product — and therefore cannot issue a 24-hour early warning as required by Art. 14 from 11 September 2026 onwards.
• Due diligence on third-party components (Security-by-Design): Manufacturers must demonstrate that they know and monitor the origin and security status of the open-source and third-party components they use.

In short: without an SBOM, a rapid vulnerability notification is structurally nearly impossible. The SBOM is therefore not merely a documentation requirement — it is the operational foundation of vulnerability management. Reporting deadlines are covered in detail in the article CRA Reporting Obligations from 11 September 2026.

What must a CRA-compliant SBOM contain?

The CRA text itself does not specify minimum SBOM fields, but refers to technical documentation (Annex I, Part II) and — via the harmonised standards still being developed — to established industry standards. In practice, the key reference points are the BSI standard TR-03183-2 and the CycloneDX and SPDX format specifications.

The following fields are widely regarded as the minimum content for a CRA-ready SBOM:

End-of-Life (EOL) as an underestimated field

The EOL date of a component is particularly significant in the CRA context: manufacturers must disclose the support period for their product, and that period implicitly requires that all embedded components can supply security updates for its duration. An SBOM without EOL information does not give a complete picture of residual risk — and makes vulnerability handling across the product lifecycle harder to demonstrate.

CycloneDX or SPDX — which format is CRA-compliant?

Both formats are recognised standards; the CRA does not mandate a specific format in the regulatory text. However, the guidance from BSI TR-03183-2 and the draft harmonised standards points clearly to:

• CycloneDX ≥ 1.6 (OWASP standard; strengths: rich security metadata, Vulnerability Disclosure Report, service modelling and licence expressions; well-integrated with Dependency-Track and common CI/CD pipelines)
• SPDX ≥ 3.0.1 (Linux Foundation standard; strengths: broad tool support, strong licence expression capability, widely established in open-source ecosystems)

Security-focused teams frequently choose CycloneDX because the format natively represents vulnerability information, exploit scores and the Vulnerability Exploitability Exchange (VEX) concept — all directly useful for the CRA vulnerability reporting process. SPDX is the stronger choice when licence compliance is the primary concern or when the existing toolchain is already SPDX-oriented.

Practical recommendation: Choose one format and implement it consistently in your CI/CD pipeline — ideally so that the SBOM is generated automatically on every build and managed centrally in a tool such as Dependency-Track. Dual-format outputs are useful in certain supply-chain contexts but increase maintenance overhead.

Archiving obligation: 10 years is not a given

One of the most commonly underestimated requirements in the CRA SBOM context is the technical documentation archiving obligation. Manufacturers must retain technical documentation — including SBOMs — for a period of at least 10 years after placing the product on the market, or for the support period, whichever is longer (so if the product support period exceeds 10 years, the retention obligation extends accordingly).

What this means in practice:

• SBOMs must be stored in a versioned manner — not just the current state, but each relevant historical version (especially at release milestones and after vulnerability remediations).
• The storage system must remain accessible and readable across staff turnover, corporate restructuring and technology changes.
• In the event of market surveillance authority audits, the SBOM must be producible on request — not after a reconstruction phase.

For organisations that have generated SBOMs ad hoc or only for individual releases, 10-year archiving represents a substantial process and infrastructure investment that should be planned well in advance.

BSI TR-03183-2: The German reference framework

The BSI technical guideline TR-03183-2 specifies, for the German and European market, which SBOM requirements are appropriate in the CRA context. It describes minimum fields, maturity models and recommended processes for creating, maintaining and sharing SBOMs along the supply chain.

Although TR-03183-2 is not an officially harmonised CRA standard, it serves as an important reference point — particularly for manufacturers active in the German market or interacting with public authorities and critical infrastructure operators. Aligning with TR-03183-2 puts you in a strong position for the harmonised standards currently being developed under CEN/CENELEC.

The question of which product class applies to your product — and how that affects the depth of your SBOM requirements — is addressed in the article CRA Product Classes: Standard, Class I/II and Critical.

SBOM in the supply chain: what manufacturers must demand from their suppliers

The CRA does not only apply to the finished product — it reaches into the entire supply chain. Manufacturers that source third-party components or software sub-components from other vendors must ensure those components are documented and can be monitored for vulnerabilities.

In practice, this means:

• Requiring supplier SBOMs: Contracts with software suppliers should include SBOM delivery obligations — ideally in the same format as your own SBOM (CycloneDX or SPDX) to enable machine-readable integration.
• Checking transitive dependencies: An SBOM that captures only direct dependencies is typically insufficient for CRA purposes. The full dependency graph including transitive components should be known and auditable.
• Setting up continuous monitoring: The SBOM is not a one-time document but a living artefact. New CVEs appear daily; a tool such as Dependency-Track enables continuous matching of your SBOM against vulnerability databases (NVD, OSV) and raises alerts before a reporting obligation arises.

Practical roadmap: SBOM readiness in four steps

1. Inventory: Which products do you place on the EU market? Which product class applies? The Applicability Check provides initial orientation.
2. Toolchain setup: Integrate SBOM generation into the CI/CD pipeline (e.g. Syft, cdxgen for CycloneDX; Dependency-Track for management and monitoring). Define format and minimum fields — align with TR-03183-2.
3. Supplier requirements: Review existing contracts with third-party software vendors for SBOM obligations and update them where necessary.
4. Archiving infrastructure: Establish versioned, long-term SBOM storage with an access log for regulatory requests.

Blackfort Technology offers a structured SBOM Gap Report — a detailed gap analysis of your current SBOM practice against CRA requirements.

Overview: all CRA manufacturer obligations

The SBOM is one of several core obligations. The full framework — Security-by-Design, CE marking, technical documentation, conformity assessment — is covered in the pillar article Cyber Resilience Act: Requirements, Deadlines and Obligations for Manufacturers.