The EU Cyber Resilience Act, Regulation (EU) 2024/2847, is the first law anywhere to make a software bill of materials a binding legal requirement rather than a recommendation. Annex I, Part II, point 1 requires manufacturers of products with digital elements to identify and document the components in their products, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies.

The dates catch people out. The SBOM obligation itself is enforceable from 11 December 2027. Vulnerability reporting under Article 14 binds from 11 September 2026, roughly two weeks from now. That ordering creates a practical dependency: you cannot report within 24 hours whether an actively exploited vulnerability affects your product unless you already know what is inside it.

The SBOM deadline is December 2027 in law. It is September 2026 in practice.

This guide covers what the CRA requires, what a compliant SBOM contains, which formats qualify, how deep the dependency tree must go, how the reporting clocks work, and what to build before the September deadline.

Key Definitions

Term	Definition
CRA	Cyber Resilience Act, Regulation (EU) 2024/2847. In force since 10 December 2024
SBOM	Software Bill of Materials. A machine-readable inventory of the components in a product
Product with digital elements	Any software or hardware product with a data connection placed on the EU market
Top-level dependency	A component the product directly depends on, as distinct from transitive dependencies further down the tree
Transitive dependency	A dependency of a dependency. Not expressly required by the CRA baseline
Actively exploited vulnerability	A vulnerability for which there is reliable evidence of malicious execution against a system without the owner’s permission
Severe incident	An incident negatively affecting the security of a product with digital elements
ENISA	European Union Agency for Cybersecurity. Operates the Single Reporting Platform
CSIRT	Computer Security Incident Response Team. The national coordinator for CRA reporting
SPDX	Software Package Data Exchange. An ISO-standardised SBOM format
CycloneDX	An OWASP SBOM standard widely used for security use cases
VEX	Vulnerability Exploitability eXchange. A companion document stating whether a known vulnerability actually affects a product

What the CRA Says About SBOMs

The operative text sits in Annex I, Part II, point 1. Manufacturers must identify and document vulnerabilities and components contained in products, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies.

Four elements of this requirement carry weight.

Identify and document. The obligation is continuous, not a point-in-time artefact. An SBOM generated once at release and never updated does not satisfy a requirement framed around ongoing identification.

Commonly used and machine-readable format. The CRA does not name a format. In practice this means SPDX or CycloneDX. A PDF listing components is not machine-readable in any useful sense and will not survive a market surveillance authority request.

At least the top-level dependencies. This is the minimum, not the target. Top-level dependencies are the components your product directly declares. Transitive dependencies, the ones your dependencies pull in, are where most exploited vulnerabilities actually live.

Available on request. The SBOM must be kept current and provided to market surveillance authorities when they ask. There is no obligation to publish it publicly.

The Two SBOM Deadlines and Why the Order Matters

Date	Obligation	Legal basis
10 December 2024	CRA enters into force	Article 71
11 June 2026	Chapter IV applies. Member states designate authorities and notified bodies	Article 71
11 September 2026	Article 14 vulnerability and incident reporting binds	Article 71(2)
11 December 2027	Full application: essential requirements, Annex I, technical documentation, CE marking, SBOM	Article 71

Article 71(2) brings Article 14 forward, ahead of the rest of the regulation. This is deliberate: the legislator wanted the reporting channel operating before the substantive product requirements landed.

The consequence is a sequencing problem that most engineering teams have not yet absorbed. From 11 September 2026, a manufacturer must report an actively exploited vulnerability in its product within 24 hours of becoming aware of it. When a CVE is published against a widely used library, the manufacturer has to determine, within hours, whether that library is in its product and at what version.

Without a current component inventory, that determination is a manual investigation across every repository and build. By the time it completes, the 24-hour clock has run.

Critically, the September 2026 reporting obligations apply to products already on the EU market, not only to new releases. There is no grandfathering.

The Article 14 Reporting (Ticking) Clocks

Two events trigger a report: a vulnerability in the product being actively exploited, and a severe incident affecting the product’s security. Both must be notified simultaneously to the CSIRT designated as coordinator, being that of the member state of the manufacturer’s main establishment, and to ENISA via the Single Reporting Platform.

Stage	Deadline	Content required
Early warning	24 hours from awareness	That the vulnerability or incident exists and, if known, the affected member states
Vulnerability notification	72 hours from awareness	General information about the affected product, the nature of the issue, and available corrective or mitigating measures
Final report	14 days after a corrective measure is available	Full description, severity, impact, and the corrective measure deployed

The clocks are measured in elapsed hours, not working days. A vulnerability disclosed on a Friday evening does not get until Monday.

The Single Reporting Platform operated by ENISA requires registration that cannot be completed retroactively. Manufacturers should register before the obligation binds rather than at the moment they first need to file. Let’s take a look at the practicalities of SBOM.

What Goes in a CRA-Compliant SBOM

The CRA itself does not specify data fields. The reference point that has emerged in practice is the BSI TR-03183 family, particularly Part 2, which the German federal cybersecurity authority published specifically to give manufacturers an implementable specification against CRA requirements.

A defensible SBOM should contain the following for each component.

Field	Purpose
Component name	Identification
Version	Determines whether a published CVE applies
Supplier or author	Attribution and support contact
Unique identifier	PURL, CPE, or SWID tag enabling automated vulnerability matching
License	Legal and compliance tracking
Dependency relationship	Position in the dependency graph
Hash or checksum	Integrity verification
Executable and archive status	Whether the component ships as executable code

The unique identifier field is the one teams most often treat as optional and most often regret. Automated vulnerability matching depends on it. An SBOM listing component names without PURLs or CPEs requires human interpretation at exactly the moment when the 24-hour clock is running.

Format: SPDX or CycloneDX

Feature	SPDX	CycloneDX
Governance	Linux Foundation, ISO/IEC 5962:2021	OWASP
Primary orientation	License compliance and provenance	Security and vulnerability management
Formats	JSON, YAML, RDF, tag-value, spreadsheet	JSON, XML, protobuf
VEX support	Via separate specification	Native
Tooling maturity	Strong	Strong
CRA acceptability	Yes	Yes

Either satisfies the commonly used and machine-readable requirement. CycloneDX has an edge for CRA purposes because its native VEX integration supports the vulnerability handling workflow the regulation requires. SPDX has an edge where license compliance is a parallel driver and where ISO standardisation matters to procurement.

Generating both is quite common and costs little once the pipeline exists.

How Deep Must the Dependency Tree Go

The CRA baseline is top-level dependencies. This is a genuine floor, not a suggestion, and it is lower than most security practitioners would recommend.

The practical difficulty is that vulnerabilities do not respect dependency depth. Log4Shell affected organisations that had never directly declared Log4j; it arrived transitively through frameworks that used it. A top-level-only SBOM would not have identified exposure.

Depth	CRA position	Practical assessment
Top-level only	Meets the minimum	Insufficient for the 24-hour reporting obligation in most real cases
Full transitive tree	Exceeds the minimum	Necessary for reliable vulnerability determination
Runtime dependencies	Not addressed	Relevant where components are loaded dynamically
Build-time dependencies	Not addressed	Relevant to supply chain integrity

The regulatory minimum and the operational requirement diverge here. A manufacturer that generates top-level-only SBOMs is compliant with Annex I and will struggle with Article 14.

The Third-Party Component Problem

Where a product contains an actively exploited vulnerability originating from a third-party component, the manufacturer must notify it. The obligation does not shift to the component supplier.

This has two consequences for procurement.

First, CRA requirements need to flow into contracts with component suppliers and third-party software providers. Manufacturers should require SBOMs from their suppliers, patching commitments with defined timelines, and notification obligations when the supplier becomes aware of a vulnerability in a component you use. Your compliance depends on theirs.

Second, end-of-life dependencies become a compliance liability rather than a technical debt item. A component whose upstream maintainer has ceased issuing security patches cannot be remediated within the CRA’s support period obligations. Identifying EOL dependencies is part of SBOM hygiene, not a separate exercise.

Open Source and the CRA

The CRA treats open source differently depending on commercial context.

Open source software developed and supplied outside the course of a commercial activity falls outside the regulation. A maintainer publishing a library for free with no commercial relationship is not a manufacturer under the CRA.

The position changes where open source is monetised, supported commercially, or integrated into a commercial product. A manufacturer that ships open source components inside a commercial product is responsible for those components under the CRA regardless of who wrote them.

The SBOM obligation covers the whole product, not only the proprietary parts.

The CRA also created the category of open source software steward, a lighter-touch regime for foundations and organisations that support open source development on a sustained basis without directly monetising it.

Stewards have security policy and cooperation obligations but do not carry the full manufacturer burden.

Product Classification and Conformity Assessment

SBOM obligations are uniform across product classes. The conformity assessment route is not.

Class	Examples	Assessment route
Default (approximately 90% of the market)	Most software and connected hardware	Manufacturer self-assessment and EU declaration of conformity
Important, class I	Browsers, VPNs, password managers, network management systems	Harmonised standards or third-party assessment
Important, class II	Firewalls, intrusion prevention systems, hypervisors	Notified body assessment mandatory
Critical	Hardware security modules, smart meter gateways, smartcards	European cybersecurity certification

Classification determines the assessment route from December 2027 and should be settled early, because notified body capacity for class II products will be constrained.

SBOM-Related Penalties

Infringement	Maximum penalty
Non-compliance with essential requirements in Annex I	€15 million or 2.5% of worldwide annual turnover, whichever is higher
Non-compliance with other manufacturer obligations	€10 million or 2% of worldwide annual turnover
Supplying incorrect, incomplete, or misleading information to notified bodies or authorities	€5 million or 1% of worldwide annual turnover

Market surveillance authorities can also require products to be withdrawn from the market or recalled. For a software product, a withdrawal order is a more serious commercial event than the fine.

What to Build Before 11 September 2026

The reporting obligation binds in roughly two weeks. The following are the minimum operational components.

Register on the Single Reporting Platform. Registration cannot be done retroactively. Identify your coordinating CSIRT based on your main establishment and complete registration before you need it.

Define the reporting process. A named point of contact, an on-call rota, an internal escalation route, templates for the 24-hour, 72-hour, and 14-day submissions, and a decision procedure for determining whether a vulnerability is actively exploited. Rehearse it before you need it.

Generate SBOMs in your build pipeline. Automated generation at build time in SPDX or CycloneDX, stored and versioned alongside the artefact. Manual SBOM generation does not scale and does not stay current.

Connect SBOMs to vulnerability monitoring. An SBOM that is not continuously matched against vulnerability feeds is an inventory, not a control. The value is in the automated match between a newly published CVE and your component list.

Identify end-of-life dependencies. Components no longer receiving upstream security patches cannot be remediated within CRA support period obligations. Surface them now.

Push requirements into supplier contracts. SBOM provision, patching commitments, and vulnerability notification obligations from your component suppliers.

Run a gap analysis against Annex I. Security by design, vulnerability handling, secure default configuration, and update mechanisms. Measure the distance to close before December 2027.

FAQ