CRA 24-Hour Reporting Clock

The clock starts 11 September 2026. From that date, a manufacturer of a product with digital elements sold into the EU must report an actively exploited vulnerability to ENISA and its coordinator CSIRT within 24 hours, follow with a full notification at 72 hours, and file a final report 14 days after a fix is available.

That last clock is the single most misread sentence in Article 14. It does not run from awareness. It runs from availability of the corrective measure — which means a vulnerability you cannot fix for six months does not start its 14-day clock for six months. The sequencer, the decision tree and the guide all hammer this point, because getting it wrong produces either a panicked filing or a missed one.

The CRA is not NIS2 and not DORA. Those cover operational and personal-data events at entities. The CRA trigger is product security: your product has an actively exploited vulnerability, or you suffer a severe incident affecting its security. A US SaaS or IoT vendor with EU customers is squarely in scope and usually has no process for it at all.

01 Four-Regime Trigger Harmonization Matrix (XLSX) — CRA, NIS2, DORA and GDPR across 17 dimensions: what trips each one, the clock, the recipient, the required content, and who in your organisation owns it. The clock sequencer computes every deadline from a single T-0.

02 Is It Reportable? (DOCX + printable PDF + Markdown) — the evidence test for 'actively exploited', the (a)/(b) test for a severe incident, and where each one gets filed.

03 24/72/14-Day Clock Runbook (DOCX) — opens with the pre-flight, because the platform work has to happen before the deadline: register your submitters during ENISA's test period, determine your coordinator CSIRT, and list the Member States each product is placed in. Then roles, the T-0 to final timeline, Single Reporting Platform mechanics, and the records to keep.

04 Early Warning & Notification Templates (DOCX) — field-complete drafts for the 24-hour early warning, the 72-hour notification for both vulnerabilities and incidents, the final reports, the user notice, and a submission log.

05 PSIRT / CSIRT RACI (XLSX) — 18 activities across 10 roles, with a contacts sheet to complete before the 11th. If your PSIRT and your incident responders have never agreed who presses submit, this is that conversation on one page.

06 Coordinated Vulnerability Disclosure Policy (DOCX) — a manufacturer CVD policy and security.txt, which Annex I Part II(5) obliges you to have. Publishable as-is under your own name; the licence says so explicitly.

07 Practitioner Guide (PDF) — triggers, clocks, the SRP, reporting sensitivity, the four-regime comparison, a ten-day readiness plan and an FAQ.

Companion to the EU Cyber Resilience Act Workbook, which covers scope, classification, conformity routes, Annex I and SBOM — the governance half. This is the operational half. Pairs with CIRCIA 72/24 if you report on both sides of the Atlantic.

Current as of 2 September 2026. ENISA's coordinator-CSIRT list and the SRP's published field names are still landing; those items are marked in the files and are v1.1 territory, free to existing buyers. A practitioner's toolset, not legal advice.