CRA Reporting Copilot / Guides

24-hour reporting under the CRA: what the early warning actually requires

July 2026 · 5 min read

The number that dominates every Cyber Resilience Act briefing is 24. From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability or a severe incident must submit an early warning within 24 hours (Art. 14(2)(a) and 14(4)(a) of Regulation (EU) 2024/2847). The number alarms teams because they hear "produce an incident report in a day." That is not what the provision asks — and misunderstanding it causes both panic and, paradoxically, delay.

A signal, not an analysis

The staged structure of Article 14 divides labour across time. The early warning's job is to tell the authorities that a reportable situation appears to be underway: what kind of event, which product, when you became aware, and a first indication of impact. The substance arrives later — the 72-hour notification carries the fuller technical picture and interim measures, and the final report carries the analysis and corrective measures. ENISA's published overview of the reporting data items reflects this gradient: the required fields per stage grow from minimal at 24 hours toward comprehensive at the final report, with several items marked as due only when known.

Practically, this means an early warning is a short, mostly pre-writable document. If your team cannot produce it in 24 hours, the constraint is almost never missing information. It is a missing decision.

The two decisions that consume the 24 hours

• Who confirms the clock has started. The window opens when the manufacturer "becomes aware." How that moment is interpreted in edge cases depends on official guidance, so a conservative posture — and a named role who confirms the timestamp and records the reasoning — beats a committee debate at hour six.
• Who may send an incomplete message. Engineering cultures resist shipping unfinished work, and an early warning is by design unfinished. Someone must hold explicit authority to send a document full of "under investigation."

Failure modes seen in rehearsals

1. Waiting for the root cause. The most common. Teams sit on the early warning until they can answer questions that belong to the 72-hour notification or the final report. The regulation staged the timeline precisely so you do not have to know everything on day one.
2. Debating severity past the deadline. For incidents, Art. 14(5) frames what "severe" means — impact on the availability, authenticity, integrity or confidentiality of sensitive data or key functions, or the introduction or execution of malicious code. Genuine boundary cases exist; a case that is still being argued at hour 20 should be escalated to a decision-maker, not re-analysed.
3. Losing the awareness timestamp. Reconstructing when you "became aware" from chat scrollback, days later, is a bad position. Record it the moment the case opens.
4. Forgetting the users. Alongside the authority track, Art. 14(8) requires informing impacted users of an actively exploited vulnerability — and if the manufacturer does not, the coordinating CSIRT may inform them directly where it considers that proportionate and necessary. Draft the user notice early; do not let it sit.

Making 24 hours boring

Three preparations, each cheap:

• A skeleton. Pre-agree the early-warning structure so hour one is a fill-in exercise, not composition.
• A rehearsal. One tabletop run of the full flow — mock ticket, early warning, 72-hour notification, user notice — before 11 September. Teams that rehearse once stop fearing the number.
• A recorded trigger. Capture the awareness time in the incident ticket itself, confirmed by the named role, so every later clock hangs off a defensible timestamp.