EU Cyber Resilience Act incident reporting is live, stacking new deadlines onto NIS2, DORA and GDPR

Reporting duties are now active

Since 11 September 2026, manufacturers selling connected products in the European Union have been operating under a new regulatory clock. According to a compliance guide published on dev.to, the Cyber Resilience Act's incident reporting obligations took effect that day, and they cover products already on the EU market, not only new releases.

Manufacturers of products with digital elements, such as connected devices, software and components, must now report two categories of events through the ENISA single reporting platform: vulnerabilities in their products that are being actively exploited, and severe incidents that affect product security. The platform routes submissions to the CSIRT designated as coordinator and to ENISA itself.

The reporting clock runs ahead of the rest of the Act

The CRA, formally Regulation (EU) 2024/2847, entered into force on 10 December 2024, and its main requirements apply from 11 December 2027. As the dev.to guide points out, the manufacturer reporting duties were pulled forward by more than a year, to 11 September 2026, so teams cannot wait for the Act's broader conformity regime before overhauling their incident response process.

Four regimes, four sets of deadlines

The practical problem, according to the guide, is that a single event can now trigger four separate reporting tracks with different deadlines, recipients and wording:

• CRA: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report either 14 days after a fix becomes available for vulnerabilities or one month after the notification for severe incidents, filed with the CSIRT coordinator and ENISA.
• NIS2: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month, filed with the national CSIRT or competent authority.
• DORA: an initial notification within 4 hours of classifying an incident as major, and no later than 24 hours after awareness, followed by an intermediate report within 72 hours and a final report within one month, to the financial competent authority.
• GDPR: notification of a personal data breach to the supervisory authority within 72 hours, with affected individuals informed without undue delay where the risk is high.

A 24-hour early warning has effectively become the standard first checkpoint across regimes, the guide argues, with DORA the strictest of the four. A fintech that ships its own connected app could plausibly face all of them simultaneously.

What triggers a CRA report

The dev.to guide draws a clear line between theoretical and real-world risk. A flaw discovered during internal testing is not reportable on its own; a vulnerability becomes reportable when there is reliable evidence that a malicious actor has used it without the system owner's permission. The second trigger is a severe incident affecting the security of the product.

Critically, the clock starts when a team becomes aware of an issue, not when root cause is confirmed. The operational implication is that analysts need standing authority to file an early warning while the investigation is still running.

How to update the runbook

The guide recommends six concrete changes: build one triage decision tree that asks, once, whether a product vulnerability is exploited, personal data is affected, a financial ICT service is disrupted or an essential service is impacted, with each yes activating a regulation-specific track; log the awareness timestamp and run parallel timers; assign named roles with deputies for weekends and holidays; pre-write report templates so analysts fill in facts rather than drafting prose under pressure; verify access to the ENISA platform and national portals before an incident; and rehearse with tabletop exercises that mix a CRA vulnerability with a GDPR breach.

It also flags common mistakes: waiting for certainty, when early warnings exist precisely because facts are incomplete; ignoring open-source and third-party components, which calls for an up-to-date SBOM and clear vendor notification clauses; sending inconsistent messages to regulators who compare notes, which argues for a single shared fact sheet; and forgetting that manufacturers must also inform affected users about incidents and available corrective measures.

Penalties raise the stakes

The financial exposure spans all four regimes. According to the guide, GDPR fines can reach 20 million euros or 4 percent of global annual turnover; NIS2 allows up to 10 million euros or 2 percent for essential entities and 7 million euros or 1.4 percent for important ones; breaching CRA essential requirements can cost up to 15 million euros or 2.5 percent of worldwide turnover; and failing other CRA obligations, reporting included, up to 10 million euros or 2 percent. Supplying incorrect information to authorities carries its own penalty.

A single channel is proposed, not enacted

The European Commission has proposed a single entry point for incident reporting as part of its digital simplification agenda, but proposals can change. Until a final law applies, the guide advises keeping the obligations separate and monitoring official EU sources.

Why it matters

This turns a compliance exercise into an operations problem. Incident response teams that treated regulator notification as one generic step now need parallel tracks, pre-authorised early warnings, documented awareness timestamps and rehearsed handovers, because one event can require up to four submissions with mismatched deadlines. Fines at this scale make the runbook a board-level item, and inconsistencies between filings are visible to authorities who share information. Teams that decide fast and document well will absorb the change; those that wait for certainty will miss the 24-hour window.