The cra reporting obligations under the EU Cyber Resilience Act take effect on September 11, 2026. From that date, manufacturers of products with digital elements sold into the European Union must report actively exploited vulnerabilities and severe incidents, and the first deadline in the sequence is twenty four hours.
This is the first hard, enforceable duty the CRA imposes. Everything else in the regulation, the design requirements, the conformity assessments, the documentation, applies from December 11, 2027. Reporting comes first and it comes with a clock that is three times tighter than the one most security teams are built around. This piece covers what the obligation actually says, the three deadlines, what counts as in scope, where you file, what is still missing seventeen days out, how it compares to the reporting regimes you already run, and what to do about it now. If your incident process needs a refresher first, start with our guide to building a data breach response plan.
What the cra reporting obligations require
The European Commission’s reporting page states the trigger plainly. From September 11, 2026, manufacturers must report "actively exploited vulnerabilities and severe incidents having an impact on the security of their product with digital elements."
Two triggers, not one, and they are different things. An actively exploited vulnerability means a flaw in your product that someone is already using against systems without permission. A severe incident is an event that negatively affects your product’s ability to protect "the availability, authenticity, integrity or confidentiality of data."
The clock in both cases starts when you become aware. Not when you confirm, not when you finish triage, not when legal signs off. Awareness is the trigger, which is a deliberate drafting choice and the single most consequential detail in the regulation for anyone building an internal process around it.
Three deadlines, and what each one is for
The sequence is designed so the first report costs you almost nothing to file.
| Deadline | What is due |
|---|---|
| 24 hours from awareness | Early warning. A first notification that an actively exploited vulnerability or severe incident has occurred. |
| 72 hours from awareness | Notification. The general nature of the vulnerability and of the exploit, an initial assessment, and the corrective or mitigating measures taken or planned. |
| 14 days / one month | Final report. Fourteen days after a corrective measure is available for actively exploited vulnerabilities; within a month for severe incidents. |
The twenty four hour early warning is not an incident report. It is a flare. You are telling a regulator that something is happening, not explaining it. Teams that fail this deadline usually fail it because they treated it as the 72 hour report arriving early, and spent the first day investigating instead of filing.
The final report deadline for vulnerabilities is worth reading twice, because it is measured from a different event than the others. Fourteen days runs from when a corrective measure is available, not from awareness. A vulnerability you cannot yet fix does not start that clock.
What counts as a product with digital elements
Broader than most people assume, and this is where organizations discover they are in scope.
The category is defined in Regulation (EU) 2024/2847 itself, and it covers connected hardware and software sold into the EU: operating systems, browsers, VPNs, network equipment, microprocessors, IoT devices, and standalone software products. It reaches manufacturers, importers, and distributors, and it applies to companies outside the EU that sell into the market. Physical presence in Europe is not the test. Placing the product on the EU market is.
The detail most relevant to readers of this site is that open source software stewards involved with products with digital elements are also named in the reporting scope. A maintainer whose project is commercially deployed inside covered products is not automatically outside the regime because the project is free. The CRA created a distinct steward category rather than exempting open source wholesale, and anyone maintaining widely embedded infrastructure should read that provision rather than assume.
Where the report goes, and why that matters right now
One filing, two recipients. Manufacturers "report only once through the CRA Single Reporting Platform" to the Computer Security Incident Response Team where they have their main establishment, and "unless particularly exceptional circumstances apply, the information is made available simultaneously to ENISA."
The single-filing design is a genuine improvement over the alternative, which is what happens today under overlapping regimes: the same incident reported separately to several authorities in several formats on several clocks. One report, routed onward, is the right architecture.
It also creates a single dependency, which brings us to the problem.
Seventeen days before the obligation starts, the CRA Single Reporting Platform is not operational and its public URL has not been published. A tracker following the rollout recorded it as not yet live as of August 20, 2026, with its public URL unpublished and user testing still planned. The Commission’s own page uses forward-looking language, stating that the platform "will be operational by 11 September 2026."
That may well happen. The point for planning purposes is that you cannot currently register, test a submission, confirm what fields are required, or find out how your first filing will be authenticated. Every organization that wants to rehearse a twenty four hour filing before it matters is waiting on infrastructure that does not exist.
The practical response is to build the process around the content rather than the interface. The information the 24 and 72 hour reports require is knowable now from the regulation. Draft the templates, assign the decision owner, and treat the platform as a delivery mechanism to be slotted in when it appears. An organization that has already decided who declares awareness, and what goes in the first flare, will lose very little time learning a web form.
How this compares to what you already run
Most teams reading this already operate under at least one incident reporting regime, and the instinct will be to fold the CRA into it. Check the clocks before you do.
| Regime | First deadline | Triggered by |
|---|---|---|
| CRA Article 14 | 24 hours | Actively exploited vulnerability or severe incident in your product |
| GDPR breach notification | 72 hours | Personal data breach |
| PCI DSS incident response | Contractual, varies | Cardholder data compromise |
The differences matter more than the overlap. GDPR is triggered by personal data exposure; the CRA is triggered by a flaw in your product being exploited, whether or not any personal data moved. A product vulnerability with no data impact can be fully reportable under the CRA and entirely out of scope for GDPR. Running them as one process will produce misses in both directions. The same scoping care applies to the EU’s other 2026 deadline for digital products, which we covered in what AI content watermarking actually is.
There is also a supply chain consequence that has not been widely discussed. If you ship a product containing components from other vendors, your awareness of an exploited vulnerability in one of those components may start your clock. Contracts that do not require prompt upstream notification are now a compliance exposure, not just an operational annoyance. The same reasoning we applied to certificate lifetimes shrinking applies here: when an external deadline tightens, the weakest link becomes whoever tells you last.
What to do in the next seventeen days
Five concrete steps, none of which depend on the platform being live.
Determine whether you are in scope, in writing. The question is whether you place a product with digital elements on the EU market as a manufacturer, importer, or distributor, or whether you are a steward of open source embedded in one. Record the reasoning either way, because "we assumed we were out of scope" is a poor answer to a regulator.
Define what awareness means inside your organization and name the person who declares it. The 24 hour clock is unmanageable without this, and it is the step most teams skip.
Draft the early warning template now. It is short by design. Having it written removes the worst failure mode, which is spending the first day deciding what to say.
Map your components and check your upstream notification terms. You cannot report on a clock you never start.
Identify your CSIRT. Reporting routes to the CSIRT where you have your main establishment, so know which one that is before you need it. Our overview of the Open Secure AI Alliance covers the wider pattern of security coordination moving toward named, accountable bodies.
Why this one is worth taking seriously
The CRA reporting duty lands differently from most compliance dates because it is not a documentation exercise. There is no annual filing, no certificate, no audit window to prepare for. It sits dormant until something goes wrong and then it demands a response within a day.
That structure rewards preparation and punishes improvisation in a way that paperwork regimes do not. Enforcement carries real weight as well: reporting breaches sit in the CRA’s upper penalty band, and legal analyses of the regime put exposure at up to fifteen million euros or 2.5 percent of global annual turnover, whichever is higher. Those figures come from the regulation’s penalty provisions rather than from any enforcement action, since there has not been one yet.
The honest summary is that September 11 changes what happens on your worst day, not what happens on an ordinary one. That is exactly the kind of obligation organizations discover they have not prepared for at the moment preparation is no longer possible.
Frequently Asked Questions
When do the cra reporting obligations start?
September 11, 2026. The Cyber Resilience Act’s main obligations follow later, applying from December 11, 2027. Reporting is the first enforceable duty.
What has to be reported?
Actively exploited vulnerabilities in your product, and severe incidents affecting the product’s ability to protect the availability, authenticity, integrity or confidentiality of data.
What are the deadlines?
An early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for actively exploited vulnerabilities, or within a month for severe incidents.
Who has to report?
Manufacturers of products with digital elements, and open source software stewards involved with such products. The regime reaches companies outside the EU that place products on the EU market.
Where do reports go?
Once, through the CRA Single Reporting Platform, to the CSIRT where the manufacturer has its main establishment. The information is made available to ENISA at the same time unless exceptional circumstances apply.
Is the Single Reporting Platform available?
Not as of late August 2026. Its public URL had not been published and user testing was still planned. The Commission states it will be operational by September 11, 2026.
Does GDPR compliance cover this?
No. GDPR is triggered by a personal data breach and allows 72 hours. The CRA is triggered by exploitation of a product vulnerability regardless of data impact and gives 24 hours for the first notification. A product flaw with no personal data exposure can be reportable under one and not the other.
Does the 14 day clock run from the incident?
No, and this is a common misreading. For actively exploited vulnerabilities the final report is due 14 days after a corrective measure is available, not 14 days after awareness. Severe incidents use a one month deadline instead.
