Connected-product makers now have 24 hours to report exploited flaws under the EU Cyber Resilience Act
EU Cyber Resilience Act rules have required connected-product makers to report exploited flaws through ENISA within 24 hours since 11 September 2026. One incident can also start DORA, NIS2 and GDPR clocks, so runbooks need a triage step that splits into parallel filings.
The Engineer · Build desk
What happened
- Reportable events are actively exploited vulnerabilities and severe incidents that affect the security of a product with digital elements, including devices, software and components.
- Reports are submitted on ENISA's single reporting platform. From there they are passed to ENISA and to the CSIRT acting as coordinator.
- The reporting duty arrived about 15 months ahead of the Act's main requirements, which apply from 11 December 2027.
- Failing CRA obligations including reporting can cost up to EUR 10 million or 2% of worldwide turnover, against a GDPR ceiling of EUR 20 million or 4%.
Why it matters
- Who has to decide decision Legal and security have to settle before an incident who may file a CRA early warning on partial facts, since waiting for root cause can run past the 24-hour window.
- What it limits constraint With the first filing due 68 hours before the last, one combined notice cannot be timed to fit DORA and GDPR at once, so drafting has to run in parallel tracks.
- Who's exposed exposure Products already on the EU market are in scope, so a manufacturer's oldest supported firmware sits on the same 24-hour clock as its newest release.
Next story · Security · Sep 18
Manufacturers selling into the EU now owe ENISA a 24-hour warning on exploited flawsConfirmed5 publishers
According to a practitioner guide posted on dev.to, the trigger is narrower than the headline duty sounds. A vulnerability counts as actively exploited when there is reliable evidence that a malicious actor used it without the system owner's permission [5]. A theoretical flaw found in testing is not reportable on its own. The same flaw seen in the wild is [5]. The CRA clock then starts at awareness, before anyone has confirmed root cause [6].
From that one awareness timestamp, the guide runs three timers in parallel: 4 hours for DORA, 24 hours for CRA and NIS2, and 72 hours for CRA, NIS2 and GDPR [9]. By its count, a single incident can mean four deadlines and four recipients, each wanting its own wording [21]. A runbook with one "notify the regulator" step puts those filings in a queue. The guide's example of an organisation that could face all four at once is a fintech that ships its own connected app [23].
The fix it proposes is good engineering. Triage asks four questions once: whether a product vulnerability is exploited, whether personal data is affected, whether a financial ICT service is disrupted, and whether an essential or important service is impacted [10]. Each yes opens its own regulation-specific track [10]. Each track has early-warning, notification and final-report templates drafted in advance [15]. Every submission draws on one fact sheet, because regulators compare notes [13]. Supplying incorrect information to authorities carries its own penalty [14]. The design separates establishing the facts from wording them, so the facts get established once. The guide also asks teams to write down who decides an incident is "major" or "significant", and how quickly [16].
Supplier code is where I'd expect the first hours to go. The guide warns that open-source components and third-party code can be the source of an exploited vulnerability, and tells manufacturers to keep an up-to-date software bill of materials and clear vendor notification clauses [8]. The CRA also expects manufacturers to tell affected users about incidents and the corrective measures available [12]. The guide's last step is a tabletop exercise that mixes a CRA vulnerability with a GDPR breach and measures how long a defensible first report takes [17].
The deadlines and penalties above are the guide's summary of Regulation (EU) 2024/2847 [7]. The post closes with a pitch for VISTA InfoSec's compliance services [20]. The checklist above the pitch is the useful part. Its FAQ says CRA reporting does not replace NIS2 or GDPR reporting, and that the CRA covers product security [22].
What to watch
- ENISA or national CSIRT guidance on what counts as 'reliable evidence' of exploitation; that threshold sets how often the 24-hour clock starts.
- The first enforcement action over a missed, late or incorrect CRA report.
- Whether national NIS2 and GDPR portals accept submissions from ENISA's single reporting platform, or teams keep filing to each separately.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence72
- Adoption
- Not scored
- Hype gap+15
- Incentives60
- Confidence70
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The Cyber Resilience Act reporting obligations for manufacturers apply from 11 September 2026.
- [2]
The CRA reporting obligations include products already on the EU market, not just new launches.
- [3]
Manufacturers of products with digital elements, such as connected devices, software and components, must report actively exploited vulnerabilities and severe incidents that affect the security of their product.
- [4]
CRA reports go through the ENISA single reporting platform, which routes them to the CSIRT designated as coordinator and to ENISA.
- [5]
An actively exploited vulnerability means there is reliable evidence that a malicious actor used it without the system owner's permission. A theoretical flaw found in testing is not reportable on its own; one seen in the wild is.
- [6]
The CRA reporting clock starts at awareness, not at confirmation of full root cause; teams need authority to file an early warning before the investigation is finished.
- [7]
The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024; its main requirements apply from 11 December 2027.
- [8]
Open-source components and third-party code can be the source of an exploited vulnerability; the guide recommends an up-to-date software bill of materials and clear vendor notification clauses.
- [9]
The guide recommends logging the awareness timestamp and running parallel timers for 4 hours (DORA), 24 hours (CRA, NIS2) and 72 hours (CRA, NIS2, GDPR).
- [10]
The guide's triage decision tree asks: Is a product vulnerability exploited? Is personal data affected? Is a financial ICT service disrupted? Is an essential or important service impacted? Each yes activates a regulation-specific track.
- [11]
GDPR fines reach up to EUR 20 million or 4% of global annual turnover; NIS2 up to EUR 10 million or 2% for essential entities and EUR 7 million or 1.4% for important ones; breaching CRA essential requirements up to EUR 15 million or 2.5% of worldwide turnover; failing other CRA obligations, including reporting, up to EUR 10 million or 2%.
- [12]
The CRA expects manufacturers to inform affected users about incidents and the corrective measures available.
- [13]
Regulators compare notes; the guide recommends a single fact sheet as the source for every submission.
- [14]
Supplying incorrect information to authorities carries its own penalty.
- [15]
The guide recommends keeping early-warning, notification and final-report drafts ready for each regime.
- [16]
The guide recommends documenting who decides that an incident is 'major' or 'significant' and how quickly.
- [17]
The guide recommends a tabletop exercise that mixes a CRA vulnerability with a GDPR breach and measures how long it takes to produce a defensible first report.
- [18]
CRA reporting obligations began about 15 months before the Act's main requirements apply.
- [19]
In the guide's runbook, the first filing deadline falls 68 hours before the last.
- [20]
The dev.to post closes by promoting VISTA InfoSec's compliance consulting and cybersecurity compliance services.
- [21]
One incident can trigger four different deadlines, four recipients and four sets of wording across CRA, NIS2, DORA and GDPR.
- [22]
The guide's FAQ says CRA incident reporting does not replace NIS2 or GDPR reporting, and that the CRA covers product security.
- [23]
A fintech that ships its own connected app could face every one of these deadlines at once; DORA is the strictest.
Sources
2 independent publishers whose own reporting we read for this story.
- dev.toCRA Incident Reporting 2026: Update Your NIS2, DORA, GDPR Runbook
4 articles · October 8, 2026
- reversinglabs.comCRA compliance will be judged by the binary you ship
1 article · October 7, 2026
Topics and entities
Topics
- Vulnerability reporting
- EU Tech Regulation
- Incident Response
- Software Bill of Materials