EU Cyber Resilience Act Reporting Starts 11 September 2026: The 24-Hour Clock Manufacturers Missed
On 11 September 2026 the EU Cyber Resilience Act stops being a 2027 problem. From that Friday, any manufacturer placing a product with digital elements on the EU market has 24 hours to file an early warning when it learns that a vulnerability in that product is being actively exploited — and the obligation covers products that were already on the market long before anyone at the company had heard of the CRA.
Most compliance roadmaps we have seen point at December 2027, when the bulk of the regulation applies. That is the wrong date to be planning around, because the first binding, operational duty lands more than a year earlier and it is the one with a stopwatch attached.
The obligation that starts on Friday, and the one that does not
The Cyber Resilience Act is Regulation (EU) 2024/2847. Its substantive product requirements — secure-by-default configuration, vulnerability handling, the technical documentation, the conformity assessment that lets you put a CE mark on a connected device — apply from December 2027. What starts on 11 September 2026 is narrower and much more immediate: reporting.
Under Article 14, a manufacturer must notify two categories of event. The first is an actively exploited vulnerability in one of its products — meaning, in the Commission's framing, that there is reliable evidence a malicious actor has exploited it in a system without the owner's permission. The second is a severe incident affecting the security of the product: one that affects, or could affect, the product's ability to protect sensitive data or functions, or that has led or could lead to malicious code being introduced or executed on the product or a user's systems.
The law firm Freshfields put the split plainly in its 31 August briefing:
“The reporting obligations also cover PDEs placed on the EU market before the CRA becomes fully applicable in December 2027.”
— Freshfields, Cyber Resilience Act reporting obligations take effect on 11 September 2026
That single sentence is the whole story for a lot of teams. There is no grandfathering clause waiting to rescue the connected controller you shipped in 2021, stopped iterating on in 2023, and still sell spares for. If it is on the EU market and someone is exploiting a hole in it, you are reporting it on Friday's rules.
The clock: 24 hours, 72 hours, 14 days
Three deadlines, running in sequence from the moment you become aware. The European Commission's own reporting page sets them out, and they are short enough that no part of the chain can be improvised on the day.
| Filing | Deadline | Trigger | Goes to |
|---|---|---|---|
| Early warning | Within 24 hours | Becoming aware of an actively exploited vulnerability or severe incident | CSIRT of your main establishment, via the Single Reporting Platform; available to ENISA simultaneously |
| Full notification | Within 72 hours | Same event, with detail added | Same channel |
| Final report — exploited vulnerability | Within 14 days | A corrective or mitigating measure becoming available | Same channel |
| Final report — severe incident | Within 1 month | Submission of the incident notification | Same channel |
| User notification | Alongside the above | Impacted users, and where appropriate all users | Direct to users, with mitigation advice |
Two details in that table are easy to miss and expensive to get wrong.
The first is when the clock starts. It starts when you become aware — and the Commission's CRA guidance, published on 27 July 2026, ties that to the point at which an initial assessment gives a “reasonable degree of certainty” that a vulnerability is being actively exploited or that a severe incident has compromised the product. That is not the point at which your incident review concludes. It is much earlier, and it is a judgement somebody in your organisation has to be authorised to make.
The second is that the clock does not stop for weekends or public holidays. Freshfields flags this as following from the EU's general rules on time limits, Regulation (EEC, Euratom) No 1182/71. A report of active exploitation that arrives at 17:00 on a Friday is due by 17:00 on Saturday. If your escalation path depends on one named engineer answering a phone, you do not have an escalation path.
One platform, one filing — and it is still being tested
The mechanics are simpler than the deadlines suggest. Manufacturers report once, through the CRA Single Reporting Platform. The notification is addressed to the CSIRT of the member state where the manufacturer has its main establishment and, barring exceptional circumstances, is made available to ENISA at the same time. That receiving CSIRT then shares the notification without delay with the CSIRTs of every other territory where the product has been made available.
There is a narrow escape hatch on that onward sharing: on 11 December 2025 the Commission adopted a delegated act specifying the terms under which a CSIRT may, on justified cybersecurity grounds, delay dissemination to the others. It is a decision for the CSIRT, not for the manufacturer.
Worth knowing, five days out: the Commission's own page says the Single Reporting Platform “will be operational by 11 September 2026” and that functional and security testing are under way. ENISA has already published FAQs and user guidance for it. Nobody outside the process has filed a live report yet, which means the first week of this regime will be the first week for the platform too. Read the ENISA FAQ before you need it, not while a 24-hour window is running.
Who this catches that does not think it is caught
“Products with digital elements” is a deliberately wide net. It is not a software regulation with hardware attached; it is a product regulation that treats firmware, an embedded controller and a companion mobile app as parts of the same product.
Practically, that pulls in three groups who often assume the CRA is somebody else's file. Industrial equipment makers whose machines carry a network stack and a cloud dashboard. Distributors and integrators who badge a connected device as their own — putting your name on a product can make you the manufacturer for regulatory purposes. And software teams shipping a product component into an EU-bound device, whose customer's 24-hour clock is running on information only they hold.
The third case is the one that catches development shops. If you built the firmware or the telemetry service inside somebody else's connected product, your contract almost certainly does not yet say how fast you must tell them about active exploitation. From Friday, their legal deadline is 24 hours, so yours is shorter than that.
What to have in place before Friday
The short windows leave no room to design a process after the event. Freshfields' recommendation is a dedicated procedure for receiving, assessing and escalating information about potential vulnerabilities and incidents, with responsibility clearly allocated for three separate calls: whether the reporting threshold is met, who submits, and who talks to affected users.
In practice that comes down to a handful of things you can settle this week. Know which of your products are on the EU market and where your main establishment sits, because that determines which CSIRT you file with. Name a person and a deputy who can declare “reasonable degree of certainty” without waiting for a management meeting, and make sure at least one of them is reachable at the weekend. Register with and read the Single Reporting Platform guidance now. Draft the 24-hour early warning as a template with the fields already known — product, version range, what is being exploited, what you know and what you do not — so the first filing is an editing job.
And map the overlap. A single event can trigger CRA reporting, NIS2 incident reporting and a GDPR personal-data breach notification on three different clocks. Freshfields notes that these channels are not yet consolidated, pending the Digital Omnibus. Deciding which regimes apply while a 24-hour window runs is the failure mode to design out.
The wider point for connected hardware
Strip out the legal machinery and the CRA is making a commercial argument that industrial buyers have been making informally for years: a connected product now carries an obligation to keep watching it after it ships. A machine, a tool or a controller that reports what it did is worth more than one that does not — and, from Friday, one whose maker cannot say what it is doing is worth less.
That is a design brief as much as a compliance brief. Products need a route by which exploitation evidence reaches the manufacturer at all: a telemetry channel, a monitored disclosure address, a supported update path. Teams that treated those as roadmap items now have a regulatory reason to move them forward.
Sources
- Cyber Resilience Act — Reporting obligations, European Commission, Shaping Europe's digital future (primary source for the deadlines, the Single Reporting Platform, the CSIRT/ENISA routing and the 11 December 2025 delegated act).
- Cyber Resilience Act reporting obligations take effect on 11 September 2026, by Theresa Ehlen, Satya Staes Polet, Quentin Fontaine and Leonie Wittershagen, Freshfields Technology Quotient blog, 31 August 2026 (Article 14 scope, the “reasonable degree of certainty” test, the weekend point, NIS2/GDPR overlap).
- Get Ready: Reporting FAQs and Checklist, Skadden, Arps, Slate, Meagher & Flom, September 2026.
- EU Cyber Resilience Act: preparing for vulnerability and incident reporting, Hogan Lovells.
- Cyber Resilience Act: Manufacturer Reporting Deadlines 2026 by Element Testing — used as the starting point for the December 2027 versus September 2026 framing; cited from its title and published description, not from its contents.
- What are the CRA reporting obligations and how to report to ENISA SRP by Codific — cited from its title and published description.
- EU Cyber Resilience Act Explained Part 1: Scope, Obligations and Key Deadlines by Element Testing — background lead on CRA scope.
Building or maintaining a connected product that reaches the EU? Vesprr's software division builds IoT platforms, telemetry pipelines and the monitoring that makes a 24-hour report possible rather than theoretical. Start a project with us and we will map what your product needs before Friday's rules become somebody's incident.