Cyber Resilience Act: The 24-Hour Vulnerability Report Rule

On 11 September 2026 a new clock starts. If you sell software or a connected product into the EU and you become aware that a vulnerability in it is being actively exploited, you have 24 hours to file an early warning.

Most coverage of the Cyber Resilience Act treats this as a legal question. It is not. Twenty-four hours is a detection problem wearing a compliance costume, and the regulation is silent on the hard part: nothing in it tells you how to find out that a component you ship is under attack.

This is engineering guidance, not legal advice. Scope determinations for a specific product belong with your counsel.

What the Cyber Resilience Act Actually Regulates

The CRA is Regulation (EU) 2024/2847. It is worth reading the actual text on EUR-Lex rather than a vendor summary, because the obligations are more specific than most summaries suggest.

Its subject is products with digital elements: hardware and software placed on the EU market whose intended use includes a direct or indirect data connection. That is deliberately broad. A SaaS product is generally out of scope as a service, but the software you distribute is in scope, and so is the firmware in anything you ship.

The Scope Test: Are You a Manufacturer of a Product With Digital Elements?

Three questions decide whether Article 14 applies to you:

1. Do you place a product on the EU market under your own name or trademark?
2. Does that product have digital elements, meaning software or firmware, with a data connection?
3. Are you the manufacturer, as opposed to an importer or distributor, who carries separate and lighter obligations?

If you develop a commercial application and sell it to European customers, assume yes to all three until counsel says otherwise. Open-source stewards have a distinct and much lighter regime, which is one of the more carefully negotiated parts of the regulation.

Article 14 and the Three Clocks

Article 14 runs two parallel chains, and conflating them is the single most common error in CRA coverage.

The actively exploited vulnerability chain:

The severe incident chain, which is about an incident affecting the security of the product rather than a vulnerability in it:

Note the asymmetry: the vulnerability chain's final report is keyed to when a fix exists, and the incident chain's is keyed to a fixed calendar period. That difference matters when you build the workflow, because one of them can be triggered by an engineering event and the other by a timer.

What Counts as Becoming Aware, and Who Owns That Moment

Both clocks start at awareness. The regulation does not define the term in operational detail, which means you get to define it, and you should do so in writing, before the first incident rather than during it.

Awareness is not a system event. It is a state your organisation enters, and organisations enter states messily: a support engineer sees an odd ticket on Friday, a researcher posts on Mastodon on Saturday, and the security lead reads it on Monday. Afterwards, a regulator asks when you knew.

The only defensible design is:

• One named role owns the awareness determination. Not a committee, not a rota with gaps.
• A written definition of the triggering signals: a KEV listing for a component you ship, a vendor advisory stating exploitation, a credible report from a customer, your own telemetry.
• A timestamped log of when each signal arrived and what was decided.

The log is the artefact that makes a late report look like diligence rather than negligence.

Where the Reports Go: the Coordinating CSIRT, ENISA and the Single Reporting Platform

Notifications go to the CSIRT designated as coordinator for the relevant member state and to ENISA, submitted through a single reporting platform established for the purpose. This is a genuinely useful piece of design: it is one submission, not twenty-seven.

Practical consequence: find out now which CSIRT is your coordinator, register for platform access, and test the submission path before you need it at 3am.

Annex I Part II: The Vulnerability Handling Obligations Behind the Reporting

Reporting is the visible part. Annex I Part II contains the machinery that makes it possible, and these are the requirements that actually change engineering practice:

• Identify and document the components contained in the product, including a software bill of materials covering at least the top-level dependencies.
• Address and remediate vulnerabilities without delay, including by providing security updates.
• Apply effective and regular tests and reviews of the security of the product.
• Once a security update is available, publish information about fixed vulnerabilities, including a description, the affected products, the impact and severity, and information helping users remediate.
• Put in place and enforce a coordinated vulnerability disclosure policy.
• Provide a contact address for reporting vulnerabilities found in the product.

If you are new to bills of materials, our guide to what an SBOM is and why it matters covers the formats and the tooling. And the disclosure policy requirement is a good moment to settle your position on responsible versus full disclosure, because you now have to publish one.

The Support Period, and Why It Changes How You Pick Dependencies

The CRA requires security updates for a defined support period, with a default expectation of at least five years unless the product's expected lifetime is shorter.

This has a design consequence that engineering teams should absorb immediately: a dependency you cannot patch for five years is a five-year liability, not a one-sprint decision. Pinning an unmaintained library because it works today is now a decision with a regulatory tail. So is choosing a vendor whose own support horizon is shorter than yours.

The Timeline

The staggering is deliberate, and it is also a trap: the reporting obligation lands fifteen months before the full conformity regime. You will be legally required to report exploitation of vulnerabilities in your components more than a year before the rest of the framework you might have been planning to build alongside it.

Building the Detection Side: Monitoring Your Own Bill of Materials

Here is the gap nobody advertises. The CRA obliges you to report an actively exploited vulnerability in your product. It does not tell you how to learn that one exists, and no regulator sends you a notification.

In practice the free public exploitation signal is the CISA KEV catalog, plus vendor advisories for the components you embed. KEV is not European and has no legal standing here, but it is the most reliable public statement that a specific CVE is being exploited in the wild, which is precisely the trigger condition Article 14 describes. Our guide to the KEV catalog covers how it is compiled and what its inclusion criteria actually are.

The requirement, stated as an engineering task, is this: continuously match exploitation signals against your own component list. Not quarterly. Not at release time. Continuously, because the clock is 24 hours.

That matching step is the whole job. A CVE published somewhere in the world is not actionable. A CVE published somewhere in the world *that affects a component you ship* is the input the clock needs, and turning the first into the second is exactly what stack-matched CVE alerting does: you declare the technologies and versions you actually ship, and only matches reach you. If you are weighing whether to build that matching yourself or buy it, our pricing page lays out what each tier includes.

A Readiness Checklist for the 24-Hour Clock

• A component inventory that is current, machine-readable, and covers at least top-level dependencies.
• Continuous monitoring of KEV and vendor advisories against that inventory, not against the whole CVE firehose.
• One named owner of the awareness determination, with a deputy.
• A written definition of what counts as becoming aware.
• A timestamped decision log.
• Registered access to the reporting platform, tested before it is needed.
• A published coordinated vulnerability disclosure policy and a working contact address.
• A defined support period per product, with dependency choices reviewed against it.
• A rehearsed 24-hour runbook, exercised at least once before September 2026.

The last item is the one teams skip and the one that decides how the first real event goes. A clock you have never run is a clock you will miss.