Article 14 Incident Reporting: A Step-by-Step Guide

Article 14 of the EU Cyber Resilience Act establishes a mandatory three-stage incident reporting process for manufacturers of products with digital elements. When a manufacturer becomes aware of an actively exploited vulnerability or a security incident that impacts their product, they must notify ENISA within defined timeframes. Missing these deadlines — or failing to report at all — is a violation of the regulation from September 2026.

What Triggers Article 14?

Not every vulnerability triggers Article 14. The reporting obligation is activated when a manufacturer becomes aware of:

1. An actively exploited vulnerability in their product — meaning threat intelligence or evidence confirms the vulnerability is being used in attacks, not merely that a CVE exists
2. A security incident with significant impact on the product — typically meaning the product has been compromised, used as an attack vector, or has resulted in data loss or service disruption for users

A CVE published against a library you use does not automatically trigger Article 14. The trigger is active exploitation or an actual incident, not theoretical exposure. However, once that trigger occurs, the clock starts immediately.

Stage 1: Early Warning (24 Hours)

Within 24 hours of becoming aware of the triggering event, you must submit an early warning to ENISA. This is intentionally lightweight — the purpose is to alert the authority that an incident is underway, not to provide a full technical analysis.

The early warning should include: basic identification of the product affected, the nature of the incident (vulnerability exploitation, breach, service disruption), and whether you suspect any malicious involvement. At this stage, you are not expected to have root cause analysis complete.

The 24-hour clock starts from when your organisation becomes aware — this means your internal escalation processes must be fast enough to reach the person responsible for CRA compliance within hours of an incident being detected.

Stage 2: Detailed Report (72 Hours)

Within 72 hours of becoming aware (not 72 hours after the early warning), you must submit a detailed incident report to ENISA. This report includes: a technical description of the incident, the affected product versions and their classification, the number of users affected (if known), whether a patch is available or in development, and the current status of your response.

💡 Note: The 72-hour window for detailed reports matches the NIS2 timeline manufacturers may already be familiar with.

If your organisation already has NIS2 incident response processes in place, the 72-hour cadence will be familiar. The content requirements are similar, though the CRA focuses specifically on the product and its vulnerabilities rather than the broader network incident scope under NIS2.

Stage 3: Final Report (14 Days or 1 Month)

The final report is due within 14 days of issuing a patch, or within one month of first becoming aware of the incident — whichever comes first. This is the comprehensive post-incident document covering: full root cause analysis, timeline of events, remediation actions taken, patch details, and any recommendations for affected users.

If the incident is still ongoing at the one-month mark and no patch has been issued, you must still submit a progress report explaining the current status, expected resolution timeline, and interim mitigations available to users.

Practical Preparation

To meet these timelines, manufacturers need to build their processes well before September 2026. Key preparation steps include:

Detection capability: You cannot report an incident you haven't detected. Implement monitoring for active exploitation of your products — threat intelligence feeds, customer reports, CVE watch lists, and security researcher coordination via a public vulnerability disclosure policy.

Internal escalation: Build a documented escalation chain that gets incidents from detection to the CRA compliance owner within hours, not days. Define who has authority to submit ENISA reports and who must be notified.

ENISA registration: ENISA's reporting portal will require manufacturer registration in advance. Do not wait until an incident occurs to create your account and familiarise yourself with the submission process.

Documentation templates: Prepare templates for each of the three report stages. Having a structured format reduces the time to submit under pressure and ensures you don't omit required fields.

CRAReady's incident management module tracks all three Article 14 deadlines automatically from the moment you create an incident. The dashboard shows countdown timers to each deadline and prompts you through the required information at each stage, so nothing is missed under pressure.