EU Cyber Resilience Act
Reporting duties start in September 2026. The software bill of materials is not legally enforceable until December 2027 - but you cannot meet the reporting duty without one.
Not legal advice
This page summarizes Regulation (EU) 2024/2847 for engineering and platform teams. It is not legal advice. If you place products with digital elements on the EU market, your product counsel and your notified body are the people who decide what applies to you. Dates and article references were verified against the Official Journal text in July 2026.
The nuance most coverage misses
You will read, correctly, that the CRA's software bill of materials requirement does not become enforceable until December 11, 2027. You will then read, incorrectly, that this means SBOM work can wait until 2027.
It cannot, because of what starts on September 11, 2026. From that date, manufacturers must report actively exploited vulnerabilities within twenty-four hours of becoming aware of them. Twenty-four hours is not enough time to work out whether a newly disclosed flaw in a transitive dependency is present in your shipped product. Either you already know your component inventory when the advisory lands, or you miss the deadline.
That is the practical position: the legal obligation arrives in December 2027, and the operational necessity arrives roughly fifteen months earlier. Teams that read only the enforcement date will discover this in the worst possible way, on the clock, during an actual incident.
Already applying
Chapter IV, covering the notification of conformity assessment bodies, has applied since June 11, 2026. That is the machinery being built, not a duty on most manufacturers.
The near deadline
Article 14 reporting begins September 11, 2026. This is the one worth planning around now, and it is the only CRA duty with an hours-scale clock.
Full application
December 11, 2027 brings the Annex I essential requirements, conformity assessment, CE marking, technical documentation and the enforceable SBOM.
What applies when
Unlike the AI Act, the CRA timeline has not been amended. The Digital Omnibus package does not touch it, and no delay has been proposed as of July 2026.
| Date | What applies | Status |
|---|---|---|
| 10 Dec 2024 | Regulation enters into force, twenty days after publication in the Official Journal | In force |
| 11 Jun 2026 | Chapter IV (Articles 35 to 51): notification of conformity assessment bodies | Applying |
| 11 Sep 2026 | Article 14: reporting of actively exploited vulnerabilities and severe incidents | Imminent |
| 11 Dec 2027 | Full application: Annex I essential requirements, conformity assessment, CE marking, technical documentation, enforceable SBOM | Scheduled |
Sources: Regulation (EU) 2024/2847, Article 71; European Commission, CRA reporting obligations.
The reporting cascade, precisely
Article 14 sets up two parallel cascades that look identical in summaries and are not identical in the text. The intervals match. The clocks do not.
Actively exploited vulnerability
- 24 hours from becoming aware: early warning.
- 72 hours from becoming aware: vulnerability notification, with general information on the product, the nature of the flaw, and any corrective or mitigating measures taken.
- 14 days after a corrective or mitigating measure is available: final report. Note the trigger - this clock does not start when you become aware, it starts when the fix exists.
Severe incident affecting security
- 24 hours from becoming aware: early warning, which must additionally state whether the incident is suspected of being caused by unlawful or malicious acts.
- 72 hours from becoming aware: incident notification.
- One month after submission of the 72-hour incident notification: final report. Again, not one month from awareness.
Where reports go
To ENISA and to the CSIRT designated as coordinator of the Member State where the manufacturer has its main establishment - not simply "your national CSIRT" if you operate in several countries.
How reports go
Through the single reporting platform established under Article 16, which ENISA refers to as the CRA Single Reporting Platform. It is not live yet. ENISA states it is scheduled to be operational by September 11, 2026, with a testing period expected beforehand.
Users too
Article 14(8) separately requires manufacturers to inform impacted users, and where appropriate all users, about the issue and any corrective measures. No fixed deadline is attached to that duty.
Two easements are worth knowing. Every 72-hour and final-report duty is prefixed with a carve-out where the relevant information has already been provided. And the coordinating CSIRT may request an intermediate report under Article 14(6), so the cascade can grow rather than shrink.
What the CRA actually says about SBOM
The requirement lives in Annex I, Part II, point 1, among the vulnerability handling requirements. It is narrower than the industry conversation around it suggests.
"...identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products."
Regulation (EU) 2024/2847, Annex I, Part II, point 1
No format is mandated
The words SPDX, CycloneDX and SWID do not appear in the regulation. Article 13(24) reserves the format and the required elements to a future Commission implementing act, which has not been adopted. Pick a widely used format and be ready to convert.
Top-level dependencies is a floor
"At the very least the top-level dependencies" is a minimum, not a target. A top-level-only SBOM will not tell you whether an exploited transitive package ships in your binary, which is exactly the question the 24-hour clock asks.
You do not have to publish it
Recital 77 states manufacturers should not be obliged to make the SBOM public. Annex VII requires it be supplied further to a reasoned request from a market surveillance authority. If you do choose to share it with users, Annex II requires you tell them where to find it.
Scope: who is a manufacturer, and what about open source
The commercial activity test
The open-source carve-out is not a clean exemption in Article 2. It works through the definition of making available on the market "in the course of a commercial activity" in Article 3(22), read with recitals 15 and 18. Free and open-source software developed or supplied outside a commercial activity is out of scope.
Ship that same package as part of a commercial product and you are a manufacturer under Article 3(13), with the full set of duties.
Open-source software stewards
The regulation invents an intermediate category in Article 3(14) for organizations that provide sustained support to open-source projects intended for commercial use - foundations, in practice. Their lighter duties sit in Article 24.
Stewards may not affix the CE marking, and are exempt from administrative fines entirely under Article 64(10). Micro and small manufacturers are separately exempt from fines for missing the 24-hour early warning deadlines.
Is your SaaS in scope?
Usually not, under the CRA. Remote data processing solutions are covered only where they are integral to a product with digital elements, in the sense of Article 3(1) and 3(2) and recitals 11 and 12. Standalone SaaS, PaaS and IaaS are regulated under NIS2 instead. A hosted development environment is far more likely to be a NIS2 question than a CRA one; the software your customers download is where the CRA bites.
Product classes, and where developer tooling lands
Most products are default class, self-assessed. The important and critical categories are narrower than people assume, and misassigning them is a common and expensive planning error.
| Category | Examples relevant to engineering tooling | Assessment |
|---|---|---|
| Important, Annex III class I | Identity and privileged access management, password managers, VPNs, network management, SIEM, boot managers, PKI and certificate issuance, operating systems, browsers | Self-assessment only if harmonised standards are fully applied |
| Important, Annex III class II | Hypervisors and container runtime systems supporting virtualized execution of operating systems, firewalls, intrusion detection and prevention systems | Notified body involvement required |
| Critical, Annex IV | Only hardware devices with security boxes, smart meter gateways, and smartcards or secure elements. No developer tooling appears here | European certification, conditional on a delegated act and an available scheme |
Note the class II entry carefully. If you ship a container runtime or a hypervisor as a product, you are in the strictest tier that actually applies to software. Running one internally to host your own development platform is not the same thing.
Penalties, and what a centralized platform gives you
Breach of the Annex I essential requirements or of Articles 13 and 14, whichever is higher. Article 64(2).
A defined list of other obligations under Article 64(3) - not a general catch-all.
Supplying incorrect, incomplete or misleading information to notified bodies and market surveillance authorities. Article 64(4).
The CRA applies to products placed on the EU market regardless of whether the code was written by a person or generated by a model. An agent that adds a dependency is doing the same regulated thing a developer does when they add one, and the manufacturer carries the same duty either way. That makes dependency provenance an infrastructure problem rather than a policy one.
One place dependencies enter
When every workspace pulls through the same internal registry rather than from whatever a laptop can reach, the component inventory is a query rather than an investigation. That is what makes a 24-hour answer possible.
Reproducible builds
Technical documentation has to describe the product as shipped. If a build cannot be reproduced from a commit, the SBOM you generate later describes something other than the artifact your customers are running.
Generation and retention
SBOM generation belongs in the pipeline, not in a spreadsheet refreshed before an audit. Retaining one per release is what lets you answer questions about a version you shipped eighteen months ago.
Related reading
Component provenance, incident reporting and data location are the three regulatory threads that reach furthest into how a development platform is built.