Since 11 September 2026, a new regulatory clock has been running for every manufacturer selling connected products in the EU. The Cyber Resilience Act (CRA) reporting duties are now live, and they sit on top of NIS2, DORA and GDPR obligations your security team already juggles. One incident can now trigger four different deadlines, four recipients and four sets of wording. If your incident response runbook still treats them as one generic "notify the regulator" step, this guide is for you.
Why CRA incident reporting changes your runbook now
The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its main requirements apply from 11 December 2027, but the reporting obligations for manufacturers arrived much earlier: 11 September 2026. That includes products already on the EU market, not just new launches.
Manufacturers of products with digital elements, such as connected devices, software and components, must report two things: actively exploited vulnerabilities and severe incidents that affect the security of their product. Reports go through the ENISA single reporting platform, which routes them to the CSIRT designated as coordinator and to ENISA.
CRA, NIS2, DORA and GDPR deadlines at a glance
| Regulation | Targets | First Deadline | Follow-up | Report To |
|---|---|---|---|---|
|
CRA (Cyber Resilience Act) |
Manufacturers of products with digital elements | Early warning Within 24 hours of becoming aware | Notification Within 72 hours, Final report 14 days after a fix is available (vulnerabilities) or one month after the notification (severe incidents) | CSIRT coordinator and ENISA via single reporting platform |
| NIS2 | Essential and important entities | Early warning Within 24 hours | Incident notification Within 72 hours; Final report Within 1 month | National CSIRT or competent authority |
| DORA | Financial entities in scope | Initial notification Within 4 hours of classifying the incident as major (and no later than 24 hours after becoming aware) | Intermediate report Within 72 hours; Final report Within 1 month | Financial competent authority |
| GDPR | Controllers (Processors alert Controllers) | 72 hours after becoming aware of a personal data breach | Inform affected individuals without undue delay if risk is high | Data protection supervisory authority |
The pattern is clear: 24 hours is the new baseline, and DORA is the strictest of all. A fintech that ships its own connected app could face every one of these at once.
What counts as reportable under the CRA?
Two triggers matter. The first is a vulnerability in your product that is being actively exploited, meaning there is reliable evidence that a malicious actor used it without the system owner's permission. The second is a severe incident with an impact on the security of your product. A theoretical flaw found in testing is not reportable on its own; one seen in the wild is.
The CRA reporting clock also starts at awareness, not at confirmation of full root cause. Your team needs authority to file an early warning before the investigation is finished.
6 steps to update your incident response runbook
1. Build one triage decision tree. Ask the same questions once: 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.
2. Start separate clocks. Log the "awareness" timestamp and run parallel timers for 4 hours (DORA), 24 hours (CRA, NIS2) and 72 hours (CRA, NIS2, GDPR). Document who decides that an incident is "major" or "significant" and how quickly.
3. Assign named roles with deputies. Incident commander, legal and DPO, product security lead and regulatory submitter, each with a backup for weekends and holidays.
4. Pre-write report templates. Keep early-warning, notification and final-report drafts ready for each regime so analysts fill in facts instead of drafting prose under pressure.
5. Prepare platform access. Make sure the right people can use the ENISA single reporting platform and national authority portals before you need them.
6. Test it. Run a tabletop exercise that mixes a CRA vulnerability with a GDPR breach. Measure how long it takes to produce a defensible first report.
Common mistakes to avoid
- Waiting for certainty. Early warnings exist precisely because facts are incomplete.
- Ignoring suppliers. Your open-source components and third-party code can be the source of an exploited vulnerability. Keep an up-to-date software bill of materials (SBOM) and clear vendor notification clauses.
- Inconsistent messaging. Regulators compare notes. Use a single fact sheet as the source for every submission.
- Forgetting users. The CRA expects manufacturers to inform affected users about incidents and the corrective measures available.
Penalties: why this is a board-level issue
The stakes are real. GDPR fines reach up to €20 million or 4% of global annual turnover. NIS2 allows up to €10 million or 2% for essential entities and €7 million or 1.4% for important ones. Breaching CRA essential requirements can cost up to €15 million or 2.5% of worldwide turnover, and failing other CRA obligations, including reporting, up to €10 million or 2%. Supplying incorrect information to authorities carries its own penalty.
Need a runbook that survives a real audit? The specialists at VISTA InfoSec help European organisations map overlapping obligations, from GDPR compliance consulting to NIS2 and DORA readiness, and pressure-test defences with penetration testing and vulnerability assessments. If you build connected products, their cybersecurity compliance services can also help you prepare for CRA conformity.
Frequently asked questions
Does CRA incident reporting replace NIS2 or GDPR reporting?
No. The CRA covers product security, while NIS2 covers entity-level incidents and GDPR covers personal data breaches. One event can trigger all of them, so your incident response plan must run them in parallel.
Is a single EU reporting channel coming?
The European Commission has proposed simplifying incident reporting through a single entry point as part of its digital simplification agenda, but proposals can change. Until a final law applies, keep separate obligations in your runbook and monitor official EU sources.
Final thoughts
CRA incident reporting is not a future problem. It is live, overlaps with NIS2, DORA and GDPR, and rewards organisations that decide fast and document well. Update your triage logic, pre-build your templates and rehearse. Then talk to VISTA InfoSec about turning your runbook into an audit-ready compliance asset.
This article is for general information, not legal advice. Deadlines and national rules can change; confirm current requirements with your legal counsel and official EU and national authority guidance.
Top comments (0)