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

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.

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.

Three months of "not yet live" updates end this week. ENISA has scheduled the Single Reporting Platform (SRP) — the mandatory channel for Cyber Resilience Act incident and vulnerability notifications — to go operational on 11 September 2026, the exact date Article 14 reporting duties enter into application. For European developers, product security teams, and manufacturers placing connected products on the EU market, this is no longer a compliance deadline on a roadmap slide. It is a live, 24-hour regulatory clock.

If your team builds IoT devices, embedded firmware, industrial controllers, or software with a network connection sold anywhere in the EU, this article breaks down exactly what the Cyber Resilience Act (Regulation (EU) 2024/2847) requires you to report, when, and through which channel — without the guesswork.

What Is the ENISA Single Reporting Platform?

The Single Reporting Platform is the electronic entry point established under Article 16 of the CRA. Instead of notifying multiple national authorities separately, a manufacturer files one report through the SRP, which then routes it simultaneously to the national CSIRT designated as coordinator for the manufacturer's main EU establishment, and to ENISA itself.

Crucially, ENISA has confirmed that no reporting API will be offered at this stage. Submissions go through a browser-based interface, authenticated via EU Login, the European Commission's shared sign-in credential. Internal detection and triage workflows can be automated, but the final act of filing is manual. Teams that assumed system-to-system integration would carry them through launch week need to rebuild that assumption immediately.

What Developers Must Actually Report Under Article 14

Article 14 does not ask you to report every bug ticket. It creates two distinct reporting tracks, and understanding the difference is the single most important thing a developer or product security lead can do before touching the platform.

1. Actively exploited vulnerabilities. If a vulnerability in your product with digital elements is being exploited in the wild — not theoretical, not internally discovered during a code review, but actually under active exploitation — you are obligated to notify ENISA and your coordinating CSIRT.

2. Severe incidents having an impact on the security of the product. This covers incidents that materially affect the product's ability to protect the confidentiality, integrity, or availability of data or functions.

For both tracks, the CRA imposes a rigid three-stage timeline:

• 24 hours — an early warning, submitted as soon as the manufacturer becomes aware.
• 72 hours — a more detailed notification confirming severity, indicators of compromise, and corrective measures underway.
• 14 days — a final report once the vulnerability or incident is resolved, including a root-cause assessment.

This is precisely why compliance specialists have been urging manufacturers to treat the reporting obligation as a distinct, earlier milestone from the CRA's broader December 2027 conformity deadline. VISTA InfoSec's detailed Cyber Resilience Act compliance checklist walks through exactly how to sequence this preparation across scoping, documentation, and reporting readiness.

Who Is on the Hook — and Who Isn't

Manufacturers carry almost the entire reporting burden. Importers and distributors have separate, narrower duties around conformity verification and CE marking, but the 24/72-hour reporting clock sits squarely with the manufacturer of the product with digital elements. Open-source software stewards also fall within ENISA's guidance and should register and validate on the SRP only when they have an actual notification to file, to avoid overloading national CSIRT teams during the launch window.

For manufacturers not established in the EU, the coordinating CSIRT is determined by the country of the manufacturer's authorised representative — not by where the company is headquartered. This detail catches non-EU vendors off guard more often than any other part of Article 14.

What Developers Should Prepare Before Filing a First Report

Even with the platform now operational, several practical gaps remain open. The official reporting data format is set by a separate European Commission implementing act, and full registration handbooks, dry-run environments, and the finalised list of national CSIRT coordinators have been rolling out only in the weeks immediately before launch.

What development and product security teams can control right now:

• Create EU Login accounts in advance for a primary and secondary organisational representative, using durable work email addresses.
• Maintain a live product inventory mapping every shipped SKU to a manufacturer identity, an SBOM, and a named PSIRT contact.
• Build (and rehearse) the internal detection-to-decision workflow that determines, within hours, whether an event meets the "actively exploited" or "severe incident" threshold.
• Name a reporting owner and a documented backup, since the 24-hour clock does not pause for someone being on leave.
• Run a full dry-run submission the moment ENISA's test environment is accessible, rather than waiting for a real incident to be your team's first encounter with the interface.

Because classification (Default, Important I, Important II, or Critical under Annex III/IV) determines both your conformity route and how deep your documentation needs to go, organisations still mapping their product portfolio against these categories should not wait. VISTA InfoSec's Cyber Resilience Act gap assessment guide is a useful reference for structuring that inventory and documentation work alongside reporting readiness, rather than treating them as separate projects.

Penalties Make This Non-Negotiable

Non-compliance with the CRA carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher — figures that place it firmly alongside GDPR and NIS2 in terms of enforcement weight. For a regulation whose full conformity requirements do not bite until December 2027, it is notable that the reporting obligation — arguably the operationally hardest part to get right under time pressure — is the piece that started first.

The Bottom Line for European Developers

The SRP going live does not mean your compliance work is finished; it means the clock that actually matters has started. Article 14 rewards organisations that have already separated "actively exploited vulnerability" from routine bug triage, pre-built their EU Login access, and rehearsed their escalation path. Teams still treating CRA reporting as a 2027 problem are now operating under a live regulatory deadline with real financial exposure.