Since 11 September 2026, manufacturers selling products with digital elements in the EU must act fast. They must send an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident. A notification follows within 72 hours. The final report is due no later than 14 days after a fix or mitigation is available for a vulnerability, or within one month after the notification for an incident. Reports go through ENISA’s Single Reporting Platform.
That makes the EU Cyber Resilience Act a stopwatch, not a design conversation. Most teams prepare the reporting half: templates, owners, escalation paths. Few work on the four words that start the clock: “of becoming aware of it”.
- 24 hoursEarly warning deadline for an actively exploited vulnerability, from 11 September 2026Source: Regulation (EU) 2024/2847, Articles 14 and 64
- EUR 15MMaximum administrative fine for breaching Article 14, or 2.5% of worldwide annual turnover, whichever is higherSource: Regulation (EU) 2024/2847, Articles 14 and 64
What Do the CRA Reporting Obligations Require Since 11 September 2026?
The Cyber Resilience Act entered into force on 10 December 2024. Most of its requirements apply from 11 December 2027. Article 14, the reporting article, applied early.
It applies to every product that falls in scope, including products placed on the market before December 2027. Manufacturers carry three separate duties, and they run on different timetables.
- 10 December 2024Cyber Resilience Act enters into force
- 11 September 2026Reporting duties in Article 14 applyEarly warning, notification and final report. ENISA’s Single Reporting Platform goes live.
- 11 December 2027Full set of essential requirements appliesReporting duties for open-source software stewards start the same day.
Track one: an actively exploited vulnerability
An actively exploited vulnerability is one where there is reliable evidence that a malicious actor has exploited it without the system owner’s permission. When a manufacturer becomes aware of one in its product, it files an early warning within 24 hours.
A vulnerability notification follows within 72 hours. It carries the general nature of the exploit and any corrective or mitigating measures. The final report is due no later than 14 days after a corrective or mitigating measure is available.
Track two: a severe security incident
A severe incident affecting the security of the product triggers the same 24 hour early warning and the same 72 hour notification. The closing report has a different anchor. It is due within one month after the incident notification is submitted, not one month after the incident.
Track three: the people using the product
Separately from the regulator, the manufacturer must inform affected users, together with the corrective or mitigating measures they can apply. This duty has no fixed hour count attached to it, which makes it the one most likely to be handled last. If a manufacturer fails to inform users in time, the CSIRTs may do it for them.
| Track | Early warning | Notification | Final report |
|---|---|---|---|
| Actively exploited vulnerability | Within 24 hours of becoming aware | Within 72 hours of becoming aware | No later than 14 days after a corrective or mitigating measure is available |
| Severe security incident | Within 24 hours of becoming aware | Within 72 hours of becoming aware | Within one month after the 72-hour notification is submitted |
| When the clock starts | The manufacturer becomes aware | The manufacturer becomes aware | A fix is available (vulnerability), or the notification is submitted (incident) |
How Does Reporting Work Since 11 September?
All regulatory reporting goes through one route. ENISA runs the CRA Single Reporting Platform, and it went live on 11 September 2026 as an initial operating capability. ENISA says it will expand the functions over the coming months.
The manufacturer reports once. The notification goes to the CSIRT of the member state where it has its main establishment, and ENISA gets access at the same time. A manufacturer with no main establishment in the EU is routed by the location of its authorised representative, importer, distributor or users, in that order.
The receiving CSIRT then shares the notification without delay with the CSIRTs of the other member states where the product is available. In exceptional cases, on justified cybersecurity grounds, a CSIRT may delay that onward sharing. The Commission adopted a delegated act on 11 December 2025 that sets the terms for those grounds.
The receiving CSIRT may also ask for an intermediate report with status updates. Open-source software stewards must report too, but only from 11 December 2027.
CRA Reporting Obligations Hinge on One Phrase: Becoming Aware
Read Article 14 closely and the trigger is not the exploitation, the disclosure or the patch. It is awareness.
This produces an uncomfortable asymmetry. A manufacturer with good external visibility learns about exploitation early, starts its clock early, and reports on a timeline that looks responsive.
A manufacturer with poor visibility may learn about the same exploitation weeks later from a customer, a journalist or a national CSIRT. Its clock technically starts on time, because it started when awareness arrived. But the exploitation has been running for weeks, other CSIRTs have not been warned, and users have not been told.
Article 14 starts the clock at awareness and says nothing about how fast a manufacturer should find out. That gap is a detection problem, and no reporting template closes it.
Why Is Awareness the Hard Part?
The gap between exploitation starting and a manufacturer noticing is not a paperwork problem. The window is narrow.
The exploitation window closes before most reporting windows open
Exploitation often comes before a fix exists. Then the ordinary disclosure process cannot warn the manufacturer, by definition.
Who Must Report, and What Does a Miss Cost?
Coverage follows the market, not the head office. The obligation attaches to manufacturers who make products with digital elements available on the EU market, wherever the company is established.
A vendor headquartered anywhere in the world that sells connected products into Europe is in scope. So is a company that sees itself as a software business, if what it ships is a product with digital elements.
The exposure sits in the highest penalty tier. Breaching Article 14 can bring administrative fines of up to EUR 15,000,000 or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. That tier covers the essential cybersecurity requirements too, so reporting is not a lesser duty. It makes CRA reporting obligations a board-level risk item, not a documentation task.
What Should You Do in the First 24 Hours?
Once someone inside the company suspects active exploitation, work through these steps in order.
- Record the time, the person and the evidence at the moment of awareness.
- Check the evidence against the legal test: reliable proof that a malicious actor exploited the weakness without permission.
- Send the early warning through the Single Reporting Platform, listing the member states where the product is available.
- Prepare the 72-hour notification: affected product, nature of the exploit, and measures taken or advised.
- Tell affected users what they can do, and plan the final report.
To see which versions of your own product are exposed on the internet, start with External Attack Surface Management. For a quick look at what is visible about your company domain, run a free scan on Atlas.
How Can You Close the Awareness Gap?
The reporting workflow is the easy half. The awareness half needs work that looks nothing like compliance work, and meeting CRA reporting obligations depends on solving it first.
Know what you actually shipped
The 24 hour clock applies to products already on the market, including versions shipped years ago and still deployed. An inventory of what you support is not an inventory of what is running, and Article 14 cares about the second one.
Watch the product from the outside
Internal telemetry covers the instances you operate. It says nothing about the customer deployments that make up most of your installed base. Finding exposed instances of your own product from the outside, including versions you no longer support, is the most direct way to shorten the gap.
Monitor where exploitation is discussed before it is disclosed
Exploit code, access listings and target lists circulate in closed forums and marketplaces well before a coordinated disclosure lands in your inbox. Where exploitation precedes disclosure, this is often the only channel through which awareness can arrive in time.
Decide now who is allowed to say the word aware
Awareness is a legal state with a 24 hour consequence. The moment it is reached should be a named decision by a named role, recorded with a timestamp. Left undefined, it becomes a question a regulator answers after the fact, which is the worst time to answer it.
Brandefense Coverage
| Brandefense Capability | How It Applies to CRA Reporting |
| EASM | External Attack Surface Management discovers exposed instances of your own products, shadow IT, forgotten subdomains and certificates. That is how you learn what is still deployed and reachable before someone else tells you. |
| Cyber Threat Intelligence | Threat actor tracking and TTP mapping across 36+ detection mechanisms and 13,000+ security controls surface active exploitation of the technologies you ship. That is the signal that starts the Article 14 clock. |
| Dark Web Monitoring | Collection across surface, deep and dark web, from 100K+ sources in 190+ countries, covers the closed channels. Exploit code and target lists circulate there before coordinated disclosure. |
RELATED READING
Understanding the EU Cyber Resilience Act: Strengthening Digital Security Across the EU Background on the regulation itself, its scope and its security by design requirements.
No Patch Exists Yet: Who Owns the Pre-Disclosure Window? The ownership question behind exploitation that happens before a fix exists.
Vulnerability Exploitation Trends: H1 2026: What Threat Actors Are Actually Using How quickly vulnerabilities are exploited after disclosure, and which ones threat actors favor.
Why Vendor Security Questionnaires Don’t Work (And What Actually Does) Why point in time attestation fails against continuous risk, the same failure mode as annual product security review.
For newer 2026 detail, see the full Cyber Resilience Act date ladder and how the CRA clock compares with NIS2, SEC and CIRCIA.
Another reporting clock: NYDFS Part 500 asks for notice within 72 hours of determining a cybersecurity incident.