From September 11 the EU Cyber Resilience Act Puts a 24-Hour Clock on Exploited Vulnerabilities and Most Makers Have No Runbook

The change and the date

From 11 September 2026, Article 14 of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to report any actively exploited vulnerability and any severe incident through a new EU Single Reporting Platform. The clock is the headline: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available for a vulnerability, or within one month after the incident notification for a severe incident.

This is the first binding obligation of the CRA to take effect. The regulation entered into force on 10 December 2024, but its main provisions, including the CE-marking and essential-requirements regime, only apply from 11 December 2027. The reporting duty lands more than a year ahead of that, which is exactly why it catches teams off guard: people are planning for 2027 while a 24-hour clock starts in September 2026.

Who is actually on the hook

Read the scope carefully before you panic or relax. The obligation falls on manufacturers placing products with digital elements on the EU market. That covers hardware and software products, both final products and components placed separately on the market, not every company that runs servers. If you operate a pure software-as-a-service platform, your incident-reporting duties are largely governed by NIS2, not the CRA. The CRA reaches a SaaS-style component only when it is a remote data processing solution integral to a product, that is, software the product needs to perform one of its functions and for which the manufacturer is responsible.

So the right audience here is anyone who ships a thing: connected devices, firmware, downloadable or embedded software, commercially supplied components, appliances. An internal platform team running someone else's product is not the filer; the maker of that product is. Getting this distinction right matters, because over-scoping leads to wasted compliance spend and under-scoping leads to a missed legal deadline.

What the failure mode looks like

The trap is not understanding the rule. The trap is the 24-hour early warning. Most organizations cannot currently answer, with confidence, three questions inside one business day: is this vulnerability being actively exploited in the wild, is the affected component one of our products in scope, and who is authorized to submit the regulator notification.

A realistic bad day: a maintainer flags exploitation of a dependency on a Friday evening. The on-call engineer is not sure whether the affected build is shipped to EU customers. Legal is offline. Nobody knows the credentials for the Single Reporting Platform or which national CSIRT is the coordinator for the company's main establishment. By Monday, the 24-hour window is long gone. That is a process failure, not a security failure, and it is the one the CRA actually penalizes.

The mechanics: you notify the CSIRT designated as coordinator for your main establishment, with the notification shared simultaneously to ENISA, and reports flow through the Single Reporting Platform that ENISA is tasked to operate and that is to be operational by the 11 September 2026 date. The early warning can be terse (an indication that exploitation is occurring, plus, where applicable, the Member States where the product has been made available), but it has to exist within 24 hours.

What to do before September

Treat this as an operational readiness exercise, not a policy memo. The question to answer honestly is: if exploitation were confirmed at 22:00 tonight, could we file a conformant early warning by 22:00 tomorrow?

• Map your product portfolio against CRA scope and write down which SKUs, firmware lines, and bundled software are in, and which fall under NIS2 instead.
• Identify your main establishment in the EU and the national CSIRT that acts as your coordinator, and confirm now how you will reach the Single Reporting Platform.
• Define the trigger: a written, testable standard for what counts as actively exploited and what counts as a severe incident under Article 14.
• Name the people. A 24-hour clock that runs nights, weekends, and holidays needs a named on-call decision-maker with authority to file, plus a legal backstop, not a committee.
• Pre-draft the early-warning, 72-hour, and final-report templates so the team fills in facts under pressure rather than composing prose.
• Run a tabletop. Use a real past CVE in one of your products and time yourselves end to end. If you cannot hit 24 hours in a drill, you will not hit it in a real event.
• Wire detection to the decision. Threat intel, exploitation feeds, and your software bill of materials need to converge on a single triage owner, not sit in three different tools.

A managed security and compliance engagement is one way to stand this up quickly, but the work is the same whether you do it in-house or with help: scope, route, decide, drill.

The honest caveats

This is real, but it is not a doomsday for everyone. Manufacturers that qualify as microenterprises or small enterprises may not be fined specifically for failing to meet the 24-hour early-warning deadline, so the deadline-specific penalty risk is concentrated on larger makers. Open-source software stewards sit under a lighter regime and are not subject to penalties for infringements of the CRA in the same way. The 24-hour notification is an early warning, not a full forensic write-up, so the standard is speed and a good-faith indication, not perfection on day one.

And the penalties are a ceiling, not a tariff. Under Article 64, infringement of the Article 14 reporting obligations sits in the highest fine tier: up to 15 million euros or, if the offender is an undertaking, up to 2.5 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. National authorities decide the actual amount case by case, weighing the nature, gravity, and duration of the infringement. Nobody is promising 15 million euros for a single late filing. The point is that the legal exposure now exists where it did not before.

One related deadline worth holding in the same view: the OpenSSL 3.0 end of life in September 2026 lands in the same window, and an unpatched cryptographic dependency is precisely the kind of issue that can become a reportable, actively exploited vulnerability under this regime.

How a senior team de-risks it

The de-risking move is to treat the 24-hour clock as an SLA and engineer backward from it, the same way you would for any production incident. You instrument detection, you assign a single accountable owner, you remove the handoffs that eat hours, and you rehearse until the path from signal to filed report is muscle memory. The teams that will be fine in September are not the ones with the best policy document. They are the ones that ran the drill, found out their notification path was broken, and fixed it while it was still cheap to fix.

Sources

• European Commission: Reporting obligations for actively exploited vulnerabilities and severe incidents under the CRA
• European Commission: The Cyber Resilience Act summary and application timeline
• Regulation (EU) 2024/2847, Article 14: reporting obligations of manufacturers
• Regulation (EU) 2024/2847, Article 64: administrative fines