The CRA's 24-Hour Clock: EU Cyber Resilience Act Reporting from Sept 11

What this is. Opinion + Experience + Fact (25% opinion · 20% experience · 55% fact). Written in collaboration with AI — I discuss, I do not outsource.

From 11 September 2026, the EU Cyber Resilience Act starts a reporting clock for connected products: an actively exploited vulnerability or a severe incident triggers a 24-hour early warning. This is a plain reading of what the clock requires — and the argument that meeting it is an engineering problem, specifically a fleet-visibility problem, well before it is a legal one.

Most compliance dates arrive quietly and apply "someday." This one is different: it is near, it is specific, and it is measured in hours. From 11 September 2026, manufacturers of products with digital elements placed on the EU market carry active reporting duties under the Cyber Resilience Act — and the first of those duties has a 24-hour fuse. Let me lay out exactly what the clock demands, why the hard part is knowing your own fleet, and why the work to meet it has to be done before an incident, not during one.

---

1. The clock is real, and it's specific

Here is the mechanism, plainly. From 11 September 2026, when a manufacturer becomes aware of an actively exploited vulnerability in its product, or a severe incident affecting the product's security, a staged reporting sequence begins: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available (within a month for severe incidents). Reports go simultaneously to ENISA and the coordinating CSIRT, through ENISA's single reporting platform.

Two details make this bigger than it first looks. It applies to products already on the market, not only new launches — so an existing fielded product is in scope. And non-compliance carries real weight, with penalties running up to €15 million or 2.5% of global annual turnover. This is not a distant, aspirational rule; it is a near-term operational obligation with a short fuse.

▸ First principle. The 24-hour clock is a specific, near-term obligation — not a someday-compliance item.

2. You can't report what you can't see

Now the part that turns a legal duty into an engineering one. Twenty-four hours is not enough time to go and discover which devices you have in the field and what they are running. The early warning has to carry facts: what is affected, how widely, which fielded units are exposed. If the honest source of that information is a spreadsheet someone last updated months ago, the clock is half-lost the moment it starts.

The difficulty was never the form. It is knowing the truth of your fleet — its population, versions, and exposure — fast enough to fill the form accurately while the countdown runs. That is an observability capability, and you either have it on an ordinary Tuesday or you don't have it during an incident.

▸ First principle. A 24-hour reporting duty is an observability problem before it's a legal one.

3. Build the visibility before the incident, not during it

The teams that will meet this clock comfortably are the ones who already know their fielded population and versions on any given day. Field inventory, telemetry, and a pre-answered "who's affected?" are the whole game — and none of them can be assembled at hour zero. You design them in ahead of time.

That reframes the date. 11 September 2026 isn't the day to start thinking about incident reporting; it's a deadline for readiness. The right question to ask now is not "what's the reporting form?" but "if a vulnerability were disclosed today, could we name the exact affected units and file an accurate early warning by tomorrow?" If the answer is no, the work to fix that is fleet visibility, and it's cheaper to build before the clock than during it.

▸ First principle. You earn the 24 hours before the incident — by being able to see your fleet on any ordinary day.

4. Make the visibility part of the platform

Field visibility isn't a compliance bolt-on; it's the same fleet foundation that makes updates, recalls, and audits possible — the reporting clock just raises the stakes on having it. Building that foundation at the device layer is what I've been doing in the open: EmbedIQ, an Apache-2.0 framework for embedded and edge. Meet the clock or not, a fleet you can see on demand is simply a better-run fleet.

▸ First principle. The capability that meets the reporting clock is the same one that makes a fleet manageable at all — so build it once, for both.

Sources

CRA reporting obligations begin 11 September 2026: a 24-hour early warning, 72-hour notification, and 14-day final report to ENISA and the coordinating CSIRT via a single reporting platform, applicable to products already on the market, with penalties up to €15 million or 2.5% of global turnover — verified August 2026 against the European Commission (digital-strategy.ec.europa.eu, "CRA — Reporting obligations"), Jones Day, DLA Piper, and cyberresilienceact.eu (Article 14). Re-verify against the primary EU source before publishing.

FAQ

When do the CRA reporting obligations start?
The reporting obligations under the EU Cyber Resilience Act apply from 11 September 2026. Most other CRA obligations apply later, from 11 December 2027, but the reporting duties come first.

What are the 24-hour, 72-hour, and 14-day deadlines?
When a manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting a product's security, it must submit an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available (within a month for severe incidents), to ENISA and the coordinating CSIRT via a single reporting platform.

Does the CRA reporting rule apply to products already on sale?
Yes. The reporting obligations cover products with digital elements already placed on the EU market, not only newly launched products. Penalties for non-compliance can reach up to €15 million or 2.5% of global annual turnover.

Why is meeting the 24-hour clock an engineering problem?
Because an accurate early warning requires knowing which fielded units are affected and what they run — and 24 hours is not enough time to discover that from scratch. Teams that meet the clock already have field inventory and telemetry in place, so the affected population is a query, not an investigation.

This is an embedded / IoT field note, and a follow-up to my earlier piece on the Cyber Resilience Act. The short version lives on my LinkedIn; the longer story, and the open-source layer that makes fleet visibility a default, live on my profile. — Ritesh | ritzylab.com