CRA 24-hour early warning: a reporting playbook

The 24-hour clock under Article 14 does not start when a vulnerability is first reported in a ticket or mentioned in a forum. According to the Commission's guidance on applying the regulation (Annex to C(2026) 5252, section 9.1), a manufacturer becomes aware once an initial assessment gives it reasonable certainty of active exploitation. Until that point, the team is still establishing whether the issue is a vulnerability in its product, whether it is being exploited, and whether the clock has started at all. Your playbook should name who can make that call, usually a product security lead with authority to escalate to the legal and incident response functions, and it should record the time the determination was made, since that timestamp anchors every later deadline.

Triage notes should show the reasoning, not only the conclusion. For each candidate event, document the affected product and versions, the source and time of the first signal, the indicators checked for exploitation (such as telemetry, customer reports, public proof-of-concept code or threat intelligence), who reviewed the evidence, and why the team concluded either that exploitation was or was not reasonably certain. Because the assessment is the basis for the clock, an assessor or market surveillance authority will ask to see this record. Give the initial assessment a fixed time budget agreed in advance, so that analysis does not drift for days while the 24-hour window runs. Confirm the budget and escalation path with your legal counsel and the CSIRT you plan to notify, since the guidance does not set a duration for this step.

The assessment is a way to establish awareness accurately, not a way to postpone reporting. If evidence of active exploitation is already strong, the 24-hour early warning should be submitted without waiting for a complete root cause analysis. For exploitation that the manufacturer already knew about before 11 September 2026, the guidance says it need not be reported retroactively. That exemption applies to events known before the reporting obligations began, not to anything that becomes known afterward. Confirm with your counsel how your organization will date and record pre-September 2026 knowledge, so that the boundary between old and new events is documented at the outset.

Your first report is rarely your last. Article 14(6) lets the CSIRT that receives a notification ask for an *intermediate report* on relevant status updates. Treat that request as a standing obligation to keep the file current, not as an exceptional event. In practice, the reporting owner should keep a running log for each notified vulnerability or incident that records every material change: a patch reaching a new build, a confirmed scope expansion, a new mitigation, a change in what is known about the threat. Ask the CSIRT early which updates it expects and through which channel, because the platform itself does not replace a direct conversation with the receiving authority. Confirm with the CSIRT and ENISA guidance how quickly it expects an update after a material change, since no fixed interval is set in the regulation text supplied for this topic.

A CSIRT may hold a notification back from other CSIRTs, but it does not hold it back from the regulator's clock. Delegated Regulation (EU) 2026/881 sets the conditions under which the receiving CSIRT may delay passing a notification to other CSIRTs. The example the regulation gives is a manufacturer that expects to deliver a mitigation within 72 hours. A delay of this kind changes who else sees the notification, not when you must file. Your own deadlines still run from awareness. Build your playbook so that the 24-hour early warning, the 72-hour notification and the final report are all due on your calendar regardless of whether a delay applies, and record in the log whether the CSIRT has told you it is applying one.

Send one notification per event, and make internal coordination your job. ENISA's platform FAQ states that one notification is enough for each actively exploited vulnerability or severe incident, even when the manufacturer has several EU subsidiaries or a parent company outside the EU. The duty to route information internally sits with the manufacturer. Name a single reporting owner, define who in each subsidiary must send facts to that owner within hours, and agree in writing which entity is the manufacturer of record for the product. Filing duplicate notifications from several group entities creates conflicting records for the same event, which is the situation a clear internal chain of command is meant to prevent.

The manufacturer owns every reporting decision under Article 14. That includes deciding that a vulnerability or severe incident is actively exploited or has an impact on product security, deciding when awareness started, approving what each submission says, and signing off the final report. Under the Commission's guidance, awareness is tied to an initial assessment that gives the manufacturer reasonable certainty of active exploitation, so the people who run that assessment must be employees with the authority to conclude it. A partner can shape the process around that decision, but it cannot make the decision or accept the consequences of it.

An implementation partner such as DeployOpen can prepare the machinery the organization needs to act within 24 hours. Typical work includes a triage runbook that defines the awareness checkpoint, role cards for the person who submits and the person who approves, submission templates that map each field to the internal evidence that fills it, logging that records timestamps for every decision, and tooling that routes vulnerability data from scanners and component feeds to the response team. The partner can also run tabletop and live rehearsals against a realistic but illustrative scenario, then document the gaps they expose. Confirm in writing which of these deliverables are in the agreed scope and who maintains them after handover.

National CSIRTs and ENISA receive, process and disseminate notifications, but they do not certify products, approve reports or confirm that a manufacturer is compliant. No partner can attest to compliance on the organization's behalf either. Only an independent auditor, assessor or certification body issues reports or certificates, and under the CRA the conformity route depends on product classification. When an assessor later reviews your reporting records, the evidence they will test is the organization's own: the timestamped decisions, the submitted content and the internal approvals. Keep those records under the organization's control from the first notification onward.