The CRA's 24-hour reporting window is a data integration problem

A KEV entry appears at 9am. Under the reporting requirement the EU Cyber Resilience Act introduced on 11 September, a manufacturer of a product with digital elements may have until 9am the next day to notify the relevant authority if the vulnerability is actively exploited or the incident is severe. CSO Online reported on 2 October that practitioners closest to this expect it to end manual triage.

Most readers will hear that as a verdict on tooling. It is more precisely a verdict on whether anyone has written down what "actively exploited" means for a specific product, and where the evidence needed to answer that actually lives. That is the difference between treating CRA as a compliance document and treating it as an engineering change.

The evidence is scattered on purpose

The notification requires ground truth across systems that were never designed to answer a question together: a KEV entry, scanner findings, telemetry from the SIEM, the asset inventory, and an SBOM. CSO Online quotes Joe Brinkley of Cobalt saying an analyst cannot be expected to catch a KEV alert, manually grep a static SBOM, and then dig through SIEM logs to see if a box is "actively taking fire."

NCC Group's Louise Horton frames the same issue as governance: success will depend on mature vulnerability management processes, visibility across products and dependencies, and the ability to identify, assess, and report issues quickly and accurately. The clause nobody has drafted yet is who decides those things fast enough.

At a size where one security team covers both the product estate and the corporate network, the headache is not that the tools do not exist. It is that the person who understands the SBOM is also the person on the customer escalation call, and nobody else knows which servers run which component. The 24-hour window does not leave time to wait for the next stand-up. When the alert lands at 9am, the person on call may be the same engineer who wrote the component. That is an advantage if the evidence is accessible and a liability if the knowledge lives only in their head.

The requirement applies to products sold into the EU, wherever the manufacturer is based. A product team shipping to a European customer from outside the bloc sits inside the same clock. That matters in regions where the first CRA conversation is still seen as a European compliance matter rather than an operational one.

Write the triage rules before the integration

Automation is the right end state, but workflow tools will only accelerate a process if the thresholds and decision points exist on paper first. The first exercise is shorter than most teams expect: in one page, define what counts as active exploitation in your environment, which role can confirm each source, and how long each confirmation may take. Then map each condition to the actual system that holds the evidence.

That mapping is what turns an SBOM into what Brinkley calls "live data structures." A compliance export refreshed once a quarter cannot answer a query at 10pm. The SBOM has to be queryable from the alerting pipeline that handles the KEV entry, and the asset inventory has to return the product owner or build number, not just the server name.

An alert that arrives at 4pm on a Friday still has 24 hours. For a team without a 24/7 security operations rota, the window crosses the evening and the weekend. The process has to be executable by an on-call engineer who may not know the component map, so the documentation has to do the remembering for them. No dashboard fixes that.

This is where the regulation stops being a document and becomes an integration project. It has the same shape as building detection or incident response: alert, accessible evidence, a decision the on-call engineer can make without escalation. For teams that already carry a roadmap, this is the kind of execution work our implementation services exist to take on, and it is easier to justify now than after the first missed deadline.

The question that is harder than tooling

The legal question is which products fall in scope and when the clock starts; that is for counsel. The operational question is simpler. If a KEV entry lands for a component in something you ship, can you find the affected products and confirm whether they are being exploited before the working day ends? If the honest answer is that it probably depends on whether the right person is at their desk, the first useful investment is a one-page triage specification and a list of systems that must answer a query together.

The same requirement raises the bar for what a buying organisation should expect from its own suppliers. A vendor that cannot describe the data path from KEV to notification in under a day is one whose CRA readiness is still a policy document. That is a fair question in the next supplier review, and it is the same question a regulator will eventually ask.

If CRA lands alongside NIS2 or DORA obligations, adding it to the same framework mapping exercise shows where the gaps overlap: disclosure timeline, supply-chain visibility, accountable owner. That keeps the CRA from becoming another siloed compliance stream.

When the first KEV alert for your product lands at 9am, ask who can confirm exploitation by noon. If the answer is a person's name, the process is already fragile. If the answer is a documented data source, the quarter looks different.