CRA 24-hour reporting: what to do when a vulnerability is actively exploited

Under Article 14 of the Cyber Resilience Act, a manufacturer that becomes aware of an actively exploited vulnerability in its product must send an early warning within 24 hours. This guide walks through those first 24 hours, hour by hour, with a template you can copy.

The rule in one paragraph

Since 11 September 2026, manufacturers of products with digital elements must notify any actively exploited vulnerability in their product through the single reporting platform, to the CSIRT designated as coordinator and to ENISA [1][3]. The early warning is due without undue delay and in any event within 24 hours of the manufacturer becoming aware of it [2][4]. Where applicable, it must say in which Member States the manufacturer knows the product has been made available [2]. A fuller notification follows within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available [2][4].

When does the clock start?

The clock starts at the moment you become aware, not when you have finished your analysis. That is why the first message is called an early warning: it is meant to be short and incomplete.

"Actively exploited" is narrower than "vulnerable". The regulation defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner [1][2]. A theoretical weakness reported by a researcher, with no sign of use in the wild, does not by itself start this 24-hour clock. It still belongs in your normal vulnerability handling process.

Typical ways awareness arrives:

A customer or partner shows you logs of an attack that used a flaw in your firmware or software.
A national CSIRT or a security vendor tells you your product is being exploited.
Your own monitoring sees exploitation in a product you operate or support.
A public advisory lists a component you ship as exploited in the wild, and you confirm your product is affected.

Write down the exact date and time of that moment, and who learned it. Every later deadline depends on it.

The first 24 hours, step by step

Hour 0: log the moment of awareness. Record the time, the source of the information and the evidence that the vulnerability is being exploited.
Hours 0 to 2: assemble the minimum team. One person who understands the product, one who can submit the report, one who decides. In a small company this may be two people. Agree who submits.
Hours 2 to 8: confirm the basics. Which product and which versions are affected? Is the evidence of exploitation reliable? Do not wait for a root cause; that belongs in later reports.
Hours 8 to 16: list where the product is sold. Use sales or distribution data to name the Member States where you know the product has been made available [2]. If you sell through distributors across the EU, say so plainly.
Hours 16 to 20: draft the early warning. Keep it factual and short. Use the template below.
Before hour 24: submit. Submit through the single reporting platform [1][3]. Save a copy of exactly what you sent and the time you sent it.
After submitting: plan the next two deadlines. The 72-hour notification is due three days after awareness. The final report is due 14 days after a fix or mitigation becomes available [2][4].

The 24 hours run through nights and weekends. If the person who submits is unreachable on a Sunday evening, you will miss it. Decide this before an incident, not during one.

Worked example

A small company makes a smart thermostat sold in Germany, the Netherlands and Belgium. On Friday at 17:40 a customer's IT contractor emails logs showing attackers used an authentication bypass in firmware 3.2 to take over devices.

Awareness: Friday 17:40. Early warning due Saturday 17:40. Notification due Monday 17:40.
Friday evening: the firmware lead confirms the logs match a known weak code path in versions 3.0 to 3.2. The founder is named as the person who submits.
Saturday morning: sales data confirms the three Member States. The early warning is drafted and submitted at 11:15, well inside the 24 hours.
Monday: the 72-hour notification adds the general nature of the exploit, the interim mitigation (disable remote access in settings) and how sensitive the company considers the information [2].
Following Thursday: firmware 3.3 with a fix is released. The final report is now due 14 days later.

Note what the early warning did not contain: no root cause, no patch, no customer count. It was on time because it did not wait for those.

Copyable early warning template

The platform has its own fields; use this as a working draft to fill them quickly.

EARLY WARNING: actively exploited vulnerability
Manufacturer: [legal name, address, contact person, phone, email]
Product: [name, model, affected versions]
Became aware: [date and time, time zone]
Source of awareness: [customer report / CSIRT / own monitoring / advisory]
Evidence of active exploitation: [one or two sentences]
Member States where the product is made available, as far as known: [list]
Current status: [investigating / mitigation in progress]
Next update: notification within 72 hours of awareness, by [date and time]
Internal case reference: [ID]

What goes in the 72-hour notification

Within 72 hours you send a notification with, where available, general information about the product concerned, the general nature of the exploit and of the vulnerability, any corrective or mitigating measures taken and those users can take, and an indication of how sensitive you consider the information to be [2]. Start drafting it as soon as the early warning is out.

Tell your users

After you become aware of an actively exploited vulnerability or a severe incident, you also inform the impacted users of your product, and where appropriate all users, about it and about any measures they can take [2]. A plain notice works best: what is affected, what to do now, and when a fix is expected.

Common mistakes

Waiting for a full analysis before sending anything.
Counting the 24 hours from the next working day.
Not knowing who has access to the reporting platform.
Losing track of the final report deadline after the urgent part is over.
Forgetting that older products already on the market are covered too [3].

For the full picture of who must report and what, read the reporting obligations guide. To prepare before anything happens, use the vulnerability handling checklist, and compare ways to organise this in spreadsheet vs tool vs consultant.

Related guides

Sources

This guide explains the rules in plain language. It is not legal advice. Check your own country's law and, when in doubt, ask a qualified adviser.