The EU Cyber Resilience Act reporting playbook — 24h/72h, from 11 September 2026

Use this playbook if you make, develop, or place on the EU market a product with digital elements — hardware or software whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Art. 3, Regulation (EU) 2024/2847). From 11 September 2026 the reporting duties in Article 14 apply to you, and — critically — they apply to products already on the market, not only to products you ship after that date.

It fires the moment one of two things becomes true:

• You have evidence that a vulnerability in your product is being actively exploited — meaning a malicious actor has successfully used it, not merely that a proof-of-concept exists.
• A severe incident has an impact on the security of your product with digital elements — for example a compromise of your development or distribution environment that could affect the product, or an incident degrading the product's ability to protect confidentiality, integrity or availability.

It does not fire for: an operator-side security incident on infrastructure you run for your own business (that is NIS2/DORA territory — see the NIS2 Title 13 timeline); a vulnerability you found internally with no evidence of exploitation (log it in your vulnerability-handling process, do not file a 24-hour early warning); or product categories carved out of the CRA (medical devices under MDR/IVDR, motor vehicles, aviation, products already covered by sector regimes). If you are only a distributor or importer, your duties are narrower — but you must inform the manufacturer and the market-surveillance authority, so read Phase A anyway.

There are two parallel reporting tracks under Art. 14 and they share the same three-gate cadence. Set both up now; you cannot improvise them at hour 1.

Track 1 — actively exploited vulnerability (Art. 14(1)): - Early warning — within 24 hours of becoming aware. - Vulnerability notification — within 72 hours of becoming aware. - Final report — no later than 14 days after a corrective or mitigating measure is available.

Track 2 — severe incident impacting product security (Art. 14(2)): - Early warning — within 24 hours of becoming aware. - Incident notification — within 72 hours of becoming aware. - Final report — within one month of the 72-hour notification.

Both tracks file to the CRA Single Reporting Platform (SRP). The notification is routed to the CSIRT designated as coordinator in the Member State of your main establishment, and is made available to ENISA simultaneously. You report once, into one platform — you do not email 27 national CSIRTs.

The trigger word is awareness. The 24-hour countdown starts when a competent person in your organisation should have concluded that the vulnerability is being exploited or that a severe incident has occurred — not when a committee formally signs off. Backward-calculation applies, exactly as it does under NIS2 Title 13.

Goal: submit the early warning to the SRP before the 24-hour mark from awareness.

The minimum content of the early warning is deliberately thin — do not delay it for completeness:

• Whether you are reporting an actively-exploited vulnerability or a severe incident.
• The name and version(s) of the affected product with digital elements.
• The Member State(s) where the product is made available, if known.
• Whether, to your knowledge, the vulnerability is being exploited, or the incident is suspected to be unlawful or malicious.
• A single point of contact.

First-24-hour checklist:

• Timestamp awareness in an immutable log — this timestamp is the start of every downstream clock.
• Convene the CRA reporting lead, the product-security owner and legal. One named decision-maker owns the filing.
• Confirm the trigger meets the Art. 14 threshold — actively exploited (evidence of successful exploitation) or severe — and record the reasoning. Over-reporting a non-severe issue burns credibility; under-reporting an exploited flaw is a €15M-class breach.
• Identify affected versions and the Member States of availability from your SBOM and distribution records.
• File the early warning through the SRP. Under-disclosure at this gate is expected; the early warning is preliminary by design.
• If a corrective or mitigating measure already exists — a patch, a config change, a kill-switch — state it. On Track 1 it starts the 14-day final-report clock running in your favour.

Goal: submit the fuller notification by the 72-hour mark from the same awareness timestamp.

Content to add over the early warning:

• For a vulnerability: its nature, the severity and impact, and — where available — corrective or mitigating measures users can take. Include the CVE identifier if one is assigned.
• For a severe incident: the nature and impact, the assessed root cause where known, and the mitigating measures applied or recommended.
• Whether the vulnerability or incident affects other products, and any known indicators of compromise.

72-hour checklist:

• Assign or reference a CVE — register as a CVE Numbering Authority in advance if you routinely ship security fixes, so you are not requesting an ID under deadline.
• Publish or stage the coordinated-disclosure advisory required by Annex I, Part II — the regulator report and the public advisory must not contradict each other.
• Attach the SBOM slice for the affected component so the CSIRT can assess downstream reach.
• State containment: what you have shipped, what you have pulled, what customers should do now.
• Flag honestly what is still hypothesis. A preliminary root cause clearly marked as preliminary is fine; a confident conclusion you later walk back at the final report is not.

Track 1 (vulnerability): no later than 14 days after a corrective or mitigating measure is available. If you never ship a fix, that clock does not start — but leaving a known exploited vulnerability unfixed breaches the Annex I, Part II duty to address vulnerabilities without delay, so this is not an escape hatch.

Track 2 (incident): within one month of the 72-hour notification.

Final-report content:

• The verified root cause, or a documented explanation of why it is not determinable.
• The full set of corrective and mitigating measures deployed, with the version that carries the fix.
• The confirmed scope: affected versions, Member States, and — for an incident — what was accessed or degraded.
• Lessons applied to the vulnerability-handling process.

This report is a summary document if the underlying artefacts were captured and signed as you went. If the SBOM, the advisory, the patch provenance and the exploitation evidence were assembled by hand after the fact, the final report becomes a multi-week reconciliation that collides with your next release.

You cannot file a 24-hour report on 12 September if the machinery is not standing on 10 September. The reporting duty presupposes the vulnerability-handling process from Annex I, Part II — even though that Annex is only formally mandatory from 11 December 2027, and the conformity-assessment-body framework has applied since 11 June 2026, you cannot comply with Art. 14 without the vulnerability-handling process already running. Build now:

• A machine-readable SBOM per shipped artefact (CycloneDX or SPDX), covering at least top-level dependencies, generated at build time and kept current. See the SBOM definition for format detail. Without it you cannot answer "which products contain the exploited component" inside 24 hours.
• A named CRA reporting lead and deputy, with SRP access provisioned and tested. ENISA has indicated a testing window before go-live — use it.
• A 24/72-hour notification template pre-written for both tracks, so the first hour is data entry, not drafting.
• A coordinated vulnerability-disclosure policy, published, with a contact channel monitored on weekends.
• Exploitation-detection capability — "actively exploited" is an evidence standard, and the awareness clock starts when you should have known. If you cannot see exploitation of your deployed product, you are exposed to filing late.
• A signed evidence trail: SBOM, advisory, patch provenance, detection telemetry and remediation log, each timestamped and tamper-evident. The European Commission's practical guidance published 27 July 2026 is the current reference for what "adequate" looks like.

That last item is where most product organisations discover their tooling was built for annual audits, not 24-hour clocks. Zero Hunt's Automatic Compliance layer keeps this trail continuously: 32 mapped frameworks with cross-framework control mapping and ECDSA-signed reports with chain-of-custody by construction, exported from the Trust Center in one click. The same evidence base that answers a NIS2 or DORA filing feeds the CRA notification — so a 24-hour early warning becomes an export and a review, not a forensic reconstruction under a regulator's clock.

1. Treating 11 December 2027 as the CRA deadline. The reporting obligations bite 15 months earlier, on 11 September 2026, and they apply to products already in the field. Product teams pacing themselves to the 2027 date miss the first real gate entirely.

2. Filing on a proof-of-concept. Art. 14(1) is for actively exploited vulnerabilities — evidence that an attacker has succeeded. A published PoC with no observed exploitation goes into your vulnerability-handling process, not a 24-hour early warning. Reflexively reporting every PoC trains the CSIRT to ignore you.

3. No SBOM, so no blast-radius answer. When the exploited component sits three dependencies deep, a team without a current per-artefact SBOM spends the first 24 hours reconstructing what shipped where — time the clock does not grant.

4. The awareness gap. The countdown starts when you should have known. A manufacturer with no telemetry on deployed-product exploitation is not merely slower to report — it is structurally late, and "we had no way to detect it" is not a defence for a product-security duty.

5. A regulator report and a public advisory that disagree. The Art. 14 notification and the Annex I coordinated-disclosure advisory are written by different people under pressure. If the CVE severity, the affected versions or the mitigation differ between them, both lose credibility. One source of truth, two renders.

6. Improvising SRP access at hour 1. Provisioning and testing Single Reporting Platform access is a pre-incident task. Discovering at hour 20 that nobody holds credentials turns a 24-hour deadline into a missed one.

A single event can trigger the CRA plus other regimes at once, on different clocks, and the CRA does not displace them:

• CRA vs NIS2: if you are also an essential or important entity, an incident affecting your own service continuity is a NIS2 Title 13 notification (24h/72h/1-month) in parallel with the CRA product-side report. Same event, two capacities — manufacturer and operator.
• CRA vs DORA: a financial entity or ICT third-party provider shipping a product may owe a DORA major-incident report (4h/72h/1-month) as well.
• CRA vs GDPR: if the incident exposed personal data, GDPR Art. 33 fires with its own 72-hour clock to the data-protection authority.
• CRA vs the AI Act: where the product is also a high-risk AI system, the AI Act serious-incident reporting obligations stack on top.

The CRA mitigates one part of this by design: you file once into the Single Reporting Platform and it disseminates. But that single-platform relief is CRA-internal — it does not merge your NIS2, DORA or GDPR filings. Build one evidence base, map it across regimes, and render a report per regulator. Manufacturers who maintain a per-artefact evidence pack file four aligned reports from one record; those who do not file four divergent ones and spend the audit explaining the differences.