The 24-Hour Notification Obligation: Article 14 and What It Means in Practice

Of all the new requirements introduced by the EU Cyber Resilience Act (CRA), Article 14 is the one keeping general counsel and Chief Information Security Officers (CISOs) awake at night.

Article 14 establishes a shockingly short, strictly enforced timeline for notifying authorities about active security threats. If your company manufactures products with digital elements (PDEs) sold in the EU, understanding the exact triggers and mechanics of this 24-hour reporting window is not optional—it is a critical business continuity requirement.

Let’s unpack exactly what Article 14 demands, when the clock starts ticking, and how to build internal processes that guarantee you never miss a deadline.

The Three-Phase Reporting Timeline

Article 14 doesn't just ask for one report; it mandates a phased approach to incident notification designed to balance the immediate need for situational awareness with the time required for a proper technical investigation.

If a trigger event occurs, manufacturers must execute the following sequence:

1. The Early Warning (T + 24 Hours): Within 24 hours of becoming aware of the trigger event, you must submit an initial notification to ENISA (the European Union Agency for Cybersecurity) or the relevant national Computer Security Incident Response Team (CSIRT). This report is intentionally brief: it simply states that a severe incident or active exploitation has occurred, providing whatever limited context is available.
2. The Vulnerability/Incident Notification (T + 72 Hours): Within 72 hours, you must follow up with a detailed technical report. This must include an assessment of the vulnerability's severity (e.g., CVSS score), the impact on the product, and any known indicators of compromise (IoCs).
3. The Final Report (T + Mitigation + 14 Days): Within 14 days after a patch or mitigating measure is made available, you must submit a comprehensive post-mortem detailing the root cause, the timeline, the fix, and the lessons learned.

The Triggers: When Does the Clock Start?

The most critical factor in Article 14 compliance is understanding exactly when the 24-hour clock starts. The CRA establishes two primary scenarios that trigger mandatory reporting.

Trigger 1: Actively Exploited Vulnerabilities

You must report any vulnerability contained in your product that is being .

• What this means: A security researcher privately reporting a theoretical flaw through your CVD portal does not trigger a 24-hour report. However, if that researcher provides proof that criminals are currently using the flaw to attack your customers, or if your own telemetry detects active exploitation in the wild, the clock starts instantly.
• The "Awareness" threshold: The clock starts the moment the manufacturer "becomes aware" of the active exploitation. The exact regulatory definition of "awareness" is still being interpreted, but it generally refers to the moment a qualified member of the organization (e.g., a triage engineer or security analyst) confirms the credibility of the exploitation report.

Trigger 2: Severe Security Incidents

You must report any having an impact on the security of your product.

• What this means: This is broader than a vulnerability in your code. It covers incidents that compromise the availability, authenticity, integrity, or confidentiality of the product. Examples include a supply chain compromise where your update servers are pushing malware, or a breach of your internal infrastructure that exposes cryptographic keys used to sign your firmware.
• The "Severe" threshold: The CRA defines severity based on factors like the number of affected users, the potential for societal or economic disruption, and the geographical spread of the impact.

(Note: ENISA is expected to provide further technical guidelines on exactly how to qualify "active exploitation" and "severe incident," but manufacturers should err on the side of over-reporting in the early days of enforcement).

Building a 24-Hour Capability

You cannot build a 24-hour Incident Response (IR) process during an active fire. By the time your lawyers debate whether an incident meets the "severe" threshold, the 24-hour window will have closed. You must build the capability now.

1. Establish Triage Authority

The most common cause of missed deadlines is decision paralysis. Who sits in the middle of the night and makes the call that an exploit is "active"?

• Action: Empower a specific role (e.g., the on-call Incident Commander or the PSIRT Lead) with the strict authority to declare a severe incident and initiate the reporting protocol. Do not require C-level sign-off for an Early Warning notification if it risks missing the deadline.

2. Pre-Draft the Templates

The middle of a crisis is the wrong time to figure out what portal to log into or what form to fill out.

• Action: Pre-draft the Early Warning and 72-Hour Notification templates. Know exactly which national CSIRT you are legally required to report to (usually based on your main establishment in the EU). Have the URLs, login credentials, and API keys tested and ready.

3. Implement Automated Telemetry

You cannot report what you cannot see. If you rely solely on external parties to inform you of active exploitation, you will always be behind the curve.

• Action: Instrument your products with adequate logging and telemetry to detect anomalous behavior. If your product is a SaaS, ensure your WAF and SIEM alerts are tuned to detect exploitation attempts against newly discovered (but unpatched) zero-days.

4. Integrate Your CVD Intake

Your Coordinated Vulnerability Disclosure (CVD) front door is often the first place you will learn of active exploitation.

• Action: Ensure your CVD intake process (like CVD Portal) has a prominent checkbox or field asking researchers: "Is there evidence this vulnerability is actively exploited?" If checked, this should immediately page the on-call PSIRT engineer, bypassing normal SLAs.

The Intersection with GDPR and NIS2

Article 14 does not exist in a vacuum. If a severe security incident under the CRA also results in a personal data breach, you must notify the relevant data protection authority within 72 hours under GDPR Article 33.

If your company is an essential or important entity under the NIS2 Directive, you may have overlapping reporting requirements to different authorities regarding the same incident. You must meticulously map out the Venn diagram of your reporting obligations.

Conclusion

The 24-hour Early Warning mandate is the CRA's enforcement teeth. It shifts vulnerability management from a relaxed, internal engineering chore to a highly visible, legally binding, time-critical operation.

Manufacturers who succeed under the CRA will be those who establish clear triage authority, automate their detection capabilities, and treat their incident response playbooks not as dusty documents, but as actively drilled, deeply ingrained operational muscles.