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

Under the Cyber Resilience Act (Regulation (EU) 2024/2847), the Software Bill of Materials - or SBOM - is a mandatory part of the 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.

Anyone who has only just started introducing SBOMs is still at a 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 must not be underestimated.

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 report an actively exploited vulnerability in time: since 11 September 2026, Art. 14 has required an early warning without undue delay and in any event within 24 hours of becoming aware, and a vulnerability notification without undue delay and at the latest within 72 hours.
• Due diligence on third-party components (Security-by-Design): Manufacturers must exercise due diligence on third-party components (Art. 13(5)) and therefore 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 a documentation requirement and at the same time the working basis of vulnerability management. Reporting deadlines are covered in detail in the article CRA Reporting Obligations since 11 September 2026.

What must a CRA-compliant SBOM contain?

The CRA requires an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies (Annex I Part II(1)); it forms part of the technical documentation (Annex VII(2)(b)). The text does not specify individual fields; the Commission may specify the format and elements by implementing act (Art. 13(24)). In practice, the reference points are the BSI Technical Guideline BSI TR-03183-2 and the CycloneDX and SPDX format specifications.

The following fields can serve as orientation:

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

The EOL date of a component is particularly significant in the CRA context: manufacturers must handle vulnerabilities in components throughout the support period (Art. 13(6) and (8)). If a component’s support ends earlier, the manufacturer has to fix or replace it; manufacturers may take the support periods of integrated third-party components into account when determining their own support period (Art. 13(8), second subparagraph). That is why the EOL date belongs in planning. 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. BSI TR-03183-2 (version 2.1.0) requires newly generated SBOMs to use one of these formats in the following versions:

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

For security-focused teams, much speaks for CycloneDX because the format natively represents vulnerability information, ratings (such as CVSS) 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

An easily underestimated requirement 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: the current state and 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 (currently version 2.1.0) describes which SBOM requirements are appropriate in the context of cyber resilience requirements for manufacturers and products. It specifies permitted formats (CycloneDX version 1.6 or higher, SPDX version 3.0.1 or higher), mandatory, additional and optional data fields, and the level of detail of an SBOM.

TR-03183-2 is not a harmonised standard under the CRA. It is nevertheless a useful 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 good position for the pending harmonised standards being developed by CEN, CENELEC and ETSI.

Which product class applies to your product and which assessment route follows is explained in the article CRA Product Classes: Standard, Class I/II and Critical.

SBOM in the supply chain: what manufacturers should ask of their suppliers

The CRA reaches beyond the finished product into the supply chain. Manufacturers must exercise due diligence on third-party components (Art. 13(5)). Supplier SBOMs are a practical way to do so, because they document components and enable matching against vulnerability databases.

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 meets the minimum of Annex I Part II but is not sufficient for reliable vulnerability management. The full dependency graph including transitive components should be known and auditable.
• Setting up continuous monitoring: The SBOM is updated with every release. New CVEs are published continuously; a tool such as Dependency-Track continuously matches your SBOM against vulnerability databases (NVD, OSV) and flags new matches, so you can check early whether a vulnerability affects your product and whether it is being actively exploited.

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.

With the free SBOM check you can automatically scan an SBOM or a lockfile for known vulnerabilities. Blackfort Technology supports you in building your SBOM practice with CRA SBOM consulting: we record tools, gaps and overlaps with you and agree a target picture with a plan.

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.