CRA Vulnerability Reporting: The Technical Reality of the 24-Hour Window

From 11 September 2026, manufacturers of products with digital elements face a reporting duty under the Cyber Resilience Act: vulnerabilities that are actively exploited, and severe incidents, must be reported, an early warning within 24 hours of becoming aware, a full notification within 72. Most of what has been written about this duty is legal commentary. This note is about the other side: what those hours look like inside a product organization, and what technical readiness actually means when the clock is running.

The dates matter less than the mechanism. Reporting obligations under Art. 14 CRA apply from 11 September 2026; the regulation's main obligations follow on 11 December 2027. The Commission published implementation guidance in July 2026, including reporting details. Reports go through a single channel, the CRA Single Reporting Platform, to the CSIRT of the manufacturer's establishment, with ENISA in parallel. But the platform is where the answer is filed. The 24 hours happen before that, in your engineering organization.

What the 24 hours are actually for

An early warning is allowed to be incomplete, that is its purpose. What is known: which product or product category, what was observed, whether exploitation is confirmed. The hard part is not writing that down. The hard part is knowing it. "Is the vulnerability actively exploited?" is a telemetry question, a log question, a repro question. Product teams without monitoring learn the answer to that question from the reporter, the worst possible source of your own status.

The 24-hour window is, in practice, a triage capability requirement. The chain is always the same: the report arrives, from a researcher, a customer, a CERT, and then: is it reproducible? Is it the product or the component? Which products, which versions? Is exploitation observable in the field? What is the actual impact? That chain is exactly the vulnerability triage workflow we describe in "Does This CVE Affect Our Product?", the CRA just attached a deadline to it.

The 72-hour notification: evidence, assembled

The full notification names affected products, versions, impact, and mitigation status. Producing that in 72 hours requires three artifacts to exist before the incident: a maintained SBOM per product version (which products contain the component), a version-to-device mapping (which deployed devices run which firmware), and a support process that can reach those devices or their operators. None of these can be built during the incident. All three are, independently, things a serious product security program should have anyway, the CRA merely makes their absence expensive.

The final report, and a habit worth stealing

After the corrective measure becomes available, a final report follows within 14 days for actively exploited vulnerabilities (within a month for severe incidents): what the vulnerability was, how it was exploited, how the report was handled. Teams that already run coordinated disclosure with researchers will recognize the shape. CRA reporting is coordinated disclosure with a statutory deadline and a fixed recipient. If your PSIRT process produces a good public advisory today, it will produce a good CRA final report tomorrow.

What technical readiness looks like

Condensed to a checklist we use with product teams:

• Know what you ship. SBOM per release, version-to-component, honest versions, backports tracked, not hidden behind version strings.
• Know what runs where. Firmware version telemetry or a support inventory that answers "which deployed devices run this build" without a week of manual correlation.
• Detect or admit you can't. If field exploitation is unobservable, that fact belongs in your incident plan, "unable to confirm exploitation" is a worse answer than "no exploitation observed", but both beat silence.
• Rehearse the chain. A dry run: one real advisory, one product line, the full four-stage triage, a drafted early warning. Once or twice a year. The first live run should not be the first run.
• Decide who files. Someone owns the Single Reporting Platform account, the CSIRT contact, and the legal/engineering handoff, before the Thursday afternoon when it matters.

The part nobody says out loud

The CRA's reporting duty punishes the organization that has no idea what it ships, and it is largely neutral toward the organization that knows, triages honestly, and fixes fast. That asymmetry is the actual design. A team that can answer "are we affected?" with evidence in an afternoon meets the 24-hour window almost incidentally. A team that cannot will miss it with any regulation you care to write. If the CRA does nothing else for product security, it turns invisible engineering hygiene into a compliance deadline, and that, cynically or not, is a budget argument security engineers have been waiting decades to have.