Flagrante

A CVE in your product just hit CISA KEV. Here is what the next 24 hours actually look like

3 September 2026

There is no shortage of writing explaining that the Cyber Resilience Act requires an early warning within 24 hours. There is very little on what those 24 hours contain. This is the second thing.

Hour 0: what actually starts it

The clock starts when you become aware that a vulnerability contained in your product is actively exploited. Three conditions, and all three matter:

• Actively exploited is not the same as severe, or public, or proof-of-concept. It requires reliable evidence that a malicious actor has exploited it in the wild. A CVSS 9.8 with no exploitation does not start a clock.
• Contained in your product is your judgement, not the feed's. A KEV listing tells you the vulnerability is exploited somewhere in the world. It does not tell you the vulnerable code path is reachable in your build, or that the affected version is the one you ship.
• Awareness is the part people underestimate. It is not "when we ran the scan". If a component of yours entered KEV three weeks ago and you had no process that would have noticed, the defensible position is not that your clock started today.

Which is why "we scan quarterly" is a worse answer than it sounds. The interval between exploitation becoming public and you noticing is the part of the timeline you control, and it is the part a regulator can most easily inspect.

Hours 0–2: decide, and write down why

The single most useful artefact from this phase is not the report. It is the record of the decision.

1. Confirm the version. KEV entries name a product, not your build. Does the affected version range include what you actually ship, in the releases still under support?
2. Confirm reachability, or accept that you cannot. Is the vulnerable path present and callable in your product as configured? If you cannot determine this within the window, the conservative reading is to report — the regulation does not offer "we were still investigating" as a reason for silence.
3. Write the reasoning down with a timestamp, whichever way you go. A decision not to report, recorded with its basis at the time, is a defensible position. The same decision, unrecorded, is indistinguishable from not having noticed.

Hours 2–24: the early warning

The early warning goes to the CSIRT designated as coordinator for the Member State of your main establishment, and to ENISA, through the Single Reporting Platform. It is deliberately short — it is a warning, not a full analysis.

Field	Notes
The vulnerability	CVE identifier, and what the product is
Whether it is actively exploited	This is the trigger; say what your evidence is
Member States affected	Where the product is made available, to the best of your knowledge
Corrective measures	What you have done or plan to do, even if the answer is "assessment in progress"
Manufacturer and contact	Legal manufacturer, and a human who can be reached

An early warning that says "we are aware, we are assessing, here is who to call" is a valid early warning. Waiting until you have a complete picture is how the 24 hours get missed.

What comes after

When	What
24 hours	Early warning
72 hours	Vulnerability notification — fuller detail, severity, impact, any mitigations available
14 days	Final report, once a corrective measure exists

All three run from awareness, not from each other, and not from when you finished investigating.

The part you can prepare in advance

Almost none of the above is doable at speed unless three things already exist before the day you need them:

• An SBOM per release, retrievable. If answering "do we ship this component" takes a day, the 24 hours are gone before the question is settled. Generate it in CI and attach it to the release; syft and cdxgen do this free.
• A named owner and an out-of-hours path. Exploitation does not arrive on Tuesday morning. Someone has to be able to make the call, and the regulator's clock does not pause for a weekend.
• Continuous checking against exploitation, not severity. The triggering event happens on someone else's schedule: a CVE you already knew about becomes reportable the moment it starts being exploited, with no change on your side at all. That is the case a quarterly scan cannot catch by construction.

The last one is worth restating, because it is the one that surprises people. Nothing has to change in your code for a reporting obligation to appear. A component you shipped two years ago, unchanged, becomes reportable because an attacker somewhere started using a weakness in it. Your build did not move. The world did.