The CRA's 24-Hour Clock: What Exploit Triage Has to Look Like Now

As of September 12, 2026.

If you sell software in the EU, the time between learning that a bug in your product is being exploited and telling a regulator about it is now 24 hours. Filing the warning takes minutes. Deciding, inside that window, that the evidence counts as exploitation is the step most teams have never had to do on a clock.

What became binding on September 11

The Cyber Resilience Act (Regulation (EU) 2024/2847) mostly applies from December 11, 2027. Article 71 carves out one piece early: Article 14, the reporting duty, applies from September 11, 2026. The same day, ENISA launched the Single Reporting Platform, the one place those reports go.

Article 14 covers two kinds of event, each on the same opening clock.

For an actively exploited vulnerability in a product with digital elements:

• an early warning within 24 hours of becoming aware of it, naming, where known, the member states where the product is sold;
• a vulnerability notification within 72 hours, with the general nature of the exploit, the fixes or mitigations taken, and what users can do;
• a final report no later than 14 days after a fix or mitigation is available, describing severity, impact, any known attacker, and the update.

For a severe incident affecting a product's security, the 24-hour warning must also say whether the incident is suspected to be malicious, the 72-hour notification gives an initial assessment, and the final report is due within a month of that notification.

The Commission's summary puts the routing plainly: manufacturers report once, through the platform, to the CSIRT of the member state where they have their main establishment, and ENISA sees the same report. A manufacturer with no EU establishment follows a fallback order set out in Article 14(7): the state of its authorized representative, then its importer, then its distributor, then the state with the most users.

Article 14(8) adds a duty that does not go to any regulator. Once aware, the manufacturer must tell affected users about the vulnerability or incident and what they can do about it, in a machine-readable format where appropriate.

It covers what you already shipped

Most of the CRA's product rules will apply only to products placed on the market after December 2027. Reporting is the exception. Article 69(3) applies Article 14 to every in-scope product placed on the market before December 11, 2027, so the installed base is covered from September 11, including versions you stopped selling but customers still run.

Open-source software stewards, the foundations and similar bodies that support free software used commercially, are on a later schedule. Both the Commission and ENISA put their reporting duty at December 11, 2027. A company that ships an open-source component inside a commercial product is a manufacturer for that product and is on the clock now.

What "actively exploited" means

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 permission of the system owner."

Three things follow from that wording.

• A public proof of concept is not enough on its own. A working exploit on GitHub shows the bug can be exploited, not that someone has done it to a system that did not consent.
• Your own evidence counts. A customer's incident report, a honeypot hit, a crash signature in your telemetry that matches the exploit, or a vendor or researcher reporting exploitation in the wild can all be reliable evidence.
• The clock starts at awareness, before the investigation ends. The early warning asks for little: that the vulnerability is being exploited and where the product is sold.

The severe-incident definition reaches further than many teams expect. Article 14(5) counts an incident as severe if it has led, or could lead, to "the introduction or execution of malicious code" in a product or in a user's systems. A poisoned release of your own package, like the force-pushed Trivy tags in March, fits that description.

Triage on a 24-hour clock

Most vulnerability programs triage by severity: a CVSS score decides how fast a fix ships. The CRA asks a different first question. Before "how bad is it," the team has to answer "is anyone exploiting it," because that answer starts the clock.

That changes who has to be awake. Someone must be able to call evidence "reliable" on a Saturday, and every channel that can carry an exploitation report, from the security inbox to a support ticket, has to reach that person. A report that waits two days in a support queue has already missed the window.

It also changes what has to exist before the report arrives. The early warning names the member states where the product is sold, and the notification needs affected versions. Both come from knowing which products contain which components, which is what an SBOM is for. When the exploited bug sits in a dependency, you still report for your product, so the dependency inventory has to answer "are we affected" in hours rather than days.

What to do now

1. Decide whether you are a manufacturer under the CRA for any product sold in the EU, including software-only products and versions you no longer sell.
2. Identify your coordinating CSIRT (your main establishment, or the Article 14(7) fallback) and register on the reporting platform.
3. Name an owner for the exploitation call, with weekend and holiday cover. If the call needs legal, put legal in the rotation now.
4. Route every exploitation signal into one queue that owner watches: security inbox, bug bounty, support escalations, threat intel, your own telemetry.
5. Make the product inventory queryable in minutes: products, versions, components, and the member states each ships to.
6. Write templates for the three reports. The 24-hour, 72-hour and final reports ask for set fields, and a template filled in on a calm day is faster than one written mid-incident.
7. Set up the user advisory channel Article 14(8) requires, in a machine-readable form such as CSAF or OSV where you can.
8. Make "has this been exploited, and since when did we know" the first field in vulnerability intake.

The slow step moved

For years the measure of a security team was time to patch. The CRA adds a second measure that starts earlier: time from the first credible sign of exploitation to a named person deciding it is real. A team that can patch in a day but takes three days to notice a customer's exploitation report will miss every early warning, however good its patching is.