EU Cyber Resilience Act SBOM Requirements: 2026 Guide

Most coverage of the EU Cyber Resilience Act treats the software bill of materials requirement as a line item to tick off before the 2027 deadline. Produce a document, store it somewhere, move on. That framing misses the point entirely.

The SBOM obligation in Regulation (EU) 2024/2847 is not a documentation exercise. It is the foundation of the CRA's entire supply chain security architecture. Without an accurate, maintained SBOM, you cannot meet the vulnerability handling obligations. You cannot demonstrate conformity to a notified body. You cannot respond to a market surveillance authority asking which components in your product carry known CVEs. The SBOM is where compliance becomes operational.

The regulatory floor: Annex I, Part II of the CRA sets out the minimum SBOM requirement. But organisations that treat it as a ceiling, rather than a starting point, will find themselves scrambling when the full application date arrives on 11 December 2027.

This article covers exactly what the CRA requires you to produce, what format and content the SBOM must contain, how open source components affect your obligations, how the CE marking and conformity assessment routes work, and what practical steps to take now.

The CRA's core security obligations are split across two parts of Annex I. Part I covers security-by-design requirements during product development. Part II covers the post-market obligations that apply throughout the product's supported lifetime, and it is here that the SBOM requirement sits.

Under Annex I, Part II, manufacturers must identify and document components contained in their product with digital elements. The regulation does not use the term "SBOM" explicitly, but the obligation it describes is precisely that: a machine-readable inventory of software components sufficient to support vulnerability management throughout the product's support period.

What the SBOM must contain

The CRA does not mandate a single prescribed format, but it does specify the categories of information that must be captured. A compliant SBOM must include, at minimum:

1. Component names and versions: Every software component, library, and dependency, identified with enough precision to match against vulnerability databases
2. Supplier or origin: Where the component comes from, including whether it originates from a third-party commercial supplier or an open source project
3. Dependencies: The relationships between components, not just a flat list
4. Licences: The licence terms under which each component is distributed
5. Cryptographic hashes: Where applicable, to verify component integrity

The regulation also requires that this documentation be updated when vulnerabilities are discovered and addressed. A static SBOM produced at release and never touched again does not satisfy the obligation. The CRA treats the SBOM as a living document, tied directly to the vulnerability handling process.

Format: SPDX, CycloneDX, or something else?

The CRA does not mandate a specific machine-readable format. Both SPDX (ISO/IEC 5962:2021) and CycloneDX are widely accepted and align with the regulation's intent. The European Commission has indicated that delegated acts may provide further technical specification, but as of the 2027 application date, manufacturers have discretion on format provided the output is machine-readable and contains the required fields.

Practical implication: Choose SPDX or CycloneDX now. Both are supported by major toolchains (Syft, Trivy, Grype, OWASP Dependency-Track). Locking in a format early means your tooling, processes, and audit trail are consistent before enforcement begins.

This is the question most development teams ask first: does using open source components in our product trigger the SBOM requirement? The answer is almost certainly yes, but the nuance matters.

The CRA applies to "products with digital elements" placed on the EU market in the course of a commercial activity. For most software companies, that threshold is met the moment they sell, licence, or distribute their product commercially, regardless of what the underlying components are. The open source exemption is about the origin of a component, not about whether the product containing it is commercial.

The three categories of open source under the CRA

According to the European Commission's guidance, open source software falls into three categories for CRA purposes:

The decisive test is not whether the software carries an open source licence. It is whether access to the software, including its maintenance, is conditioned on payment or otherwise part of a commercial relationship. A GitHub repository alone does not constitute "placing on the market." A paid enterprise edition with SLA-backed support does.

What this means for your SBOM: If your product integrates open source components, those components must appear in your SBOM regardless of their licence. The CRA explicitly requires manufacturers to exercise due diligence when integrating third-party components, including open source ones not made available commercially. If you discover a vulnerability in an integrated open source component, you are also required to report it to the component's maintainer.

This is a meaningful obligation. It means your SBOM is not just a compliance artefact: it is your primary tool for tracking which open source dependencies carry known vulnerabilities and whether they have been addressed.

The SBOM obligation and the vulnerability disclosure obligation are not parallel tracks. They are the same track.

Annex I, Part II requires manufacturers to actively monitor for vulnerabilities in their products and components, address vulnerabilities without undue delay, and disclose them through the coordinated vulnerability disclosure process. Article 14 of the CRA, which applies from 11 September 2026, requires manufacturers to notify ENISA of actively exploited vulnerabilities within 24 hours of becoming aware of them.

You cannot do any of this without a current, accurate SBOM.

Without knowing which components are in your product and which versions are deployed, vulnerability monitoring becomes reactive at best and impossible at worst. The SBOM is the prerequisite for every other security obligation the CRA imposes.

How the SBOM feeds the disclosure process

When a new CVE is published for a component in your dependency tree, your SBOM tells you:

1. Whether you use that component at all
2. Which version you are running, and whether it falls within the affected range
3. Which products and which versions of your product are affected
4. Whether a patched version exists and whether you have deployed it

Without this information, the 24-hour notification window for actively exploited vulnerabilities becomes unworkable. Organisations that treat SBOM generation as a one-time release activity will find themselves unable to meet the disclosure timeline when it matters.

The practical implication: SBOM generation should be integrated into your CI/CD pipeline, not run manually at release. Automated scanning against the NVD and OSV databases should run continuously, with alerts tied to your vulnerability management workflow.

The CRA introduces a CE marking requirement for all products with digital elements placed on the EU market. This is not a new concept: CE marking already applies to products under directives such as the Radio Equipment Directive and the Machinery Regulation. The CRA extends the same mechanism to cybersecurity.

What matters is which conformity assessment route you must follow. The CRA divides products into three categories, and the route depends on the risk profile of your product.

The three product categories

Self-assessment vs notified body: what it means in practice

For default-category products, self-assessment means the manufacturer prepares technical documentation (which includes the SBOM), draws up an EU Declaration of Conformity, and affixes the CE mark. No external audit is required, but the documentation must be complete and available to market surveillance authorities on request.

For Class I products using harmonised standards, self-assessment is still possible, but only if the standards fully cover the CRA's essential requirements. Where gaps exist, a notified body must assess those gaps. This creates a practical incentive to monitor the development of harmonised standards closely, since their scope directly determines whether external assessment is required.

For Class II products, the notified body route is mandatory regardless of standards compliance. This involves a formal audit of the technical file, including the SBOM, vulnerability handling processes, and security testing evidence.

The SBOM implication: For Class I and Class II products, the SBOM is not just an internal tool. It is part of the technical documentation reviewed during conformity assessment. Incomplete, inconsistent, or manually maintained SBOMs will create problems at assessment stage.

The full CRA application date is 11 December 2027. That sounds distant. It is not. Notified body capacity for Class II products is already constrained, harmonised standards are still being finalised, and building the internal tooling and processes to generate, maintain, and act on SBOMs takes longer than most teams expect.

Organisations that start now are not just ahead of the deadline: they are building a supply chain security capability that pays dividends before 2027 arrives.

A practical programme, in order of priority

1.  Classify your products now Determine whether each product falls into the default category, Class I, or Class II under Annex III. This single decision determines your conformity route, your timeline, and your resource requirements. If you have Class II products, notified body capacity needs to be secured well in advance.

2. Instrument your build pipeline Integrate SBOM generation into your CI/CD pipeline using tooling such as Syft, Trivy, or the OWASP Dependency-Track platform. Generate a new SBOM at every release. Store SBOMs in a version-controlled, auditable location alongside your release artefacts.

3. Choose your format and stick to it Select either SPDX or CycloneDX as your standard format across all products. Consistency matters: a mix of formats creates friction in vulnerability scanning, audit preparation, and any future notified body review.

4. Map dependencies to vulnerability feeds Connect your SBOM tooling to the National Vulnerability Database and the OSV database. Automated alerts when a component in your SBOM receives a new CVE are not optional under the CRA: the 24-hour notification requirement for actively exploited vulnerabilities makes manual monitoring insufficient.

5. Document your vulnerability handling process The CRA requires manufacturers to have a documented process for addressing vulnerabilities. This process should reference the SBOM explicitly: how you identify affected versions, how you prioritise remediation, how you communicate with component maintainers, and how you notify ENISA when required.

6. Prepare your technical documentation file For Class I and Class II products, begin assembling the technical documentation file now. This includes the SBOM, security test evidence, risk assessment documentation, and the EU Declaration of Conformity. Waiting until 2027 to start this work is the single most common compliance risk for manufacturers in scope.

The broader point

The CRA's SBOM requirement is the regulatory minimum. Organisations that treat it as such will meet the threshold. Organisations that use it as the foundation for a genuine software supply chain security programme will be in a materially different position: faster vulnerability response, cleaner dependency hygiene, and audit-ready documentation when market surveillance authorities come calling.

Penalties for breaching the CRA's essential requirements reach up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. The cost of building a compliant SBOM programme is a fraction of either figure.

For a broader view of the CRA's requirements and scope and the full compliance timeline, see the related articles in this series on the EU Cyber Resilience Act. The vulnerability disclosure obligations that sit alongside the SBOM requirement are covered in the anchor article on reporting.