The Reporting Clock - The Countdown to CRA Compliance

EXECUTIVE BRIEF: We look at required reporting becoming effective September 11, 2026 and what it means for the installed base.

24 h EARLY WARNING AFTER AWARENESS

72 h FULL NOTIFICATION VIA THE SRP

€15M / 2.5% MAXIMUM FINE (GLOBAL TURNOVER)

On 11 September 2026, the first operative obligation of the EU Cyber Resilience Act takes effect: manufacturers of products with digital elements sold into the EU must report actively exploited vulnerabilities and severe incidents to their coordinating national CSIRT and ENISA, through a single filing on the new Single Reporting Platform. The compliance press is treating this as a software-industry milestone — a deadline for SaaS teams and consumer-device firms to wire up a notification workflow. For OT manufacturers, the event is structurally different, and structurally harder. The obligation does not attach to the product roadmap. It attaches to the installed base — including devices placed on the EU market years before the regulation was drafted, running firmware nobody is yet legally required to be able to patch.

Reporting First

The CRA arrives reporting-first. The Article 14 duty to report applies from 11 September 2026; the Article 13 and Annex I duties to operate a vulnerability-handling process — triage, remediation, coordinated disclosure — do not bind until December 2027.

The sequencing matters because of scope. Under Article 69(3), the reporting obligation applies to every in-scope product already made available on the EU market, not merely to products launched after the deadline. A flow computer shipped in 2013, a protection relay with a 20-year service commitment, a dosing controller long out of active development — if it is still on the EU market, its manufacturer must report active exploitation from September. The result is a fifteen-month window in which manufacturers must confess but need not cure: the duty to tell a regulator about an exploited vulnerability arrives more than a year before the duty to maintain the machinery that fixes it.

The CRA arrives reporting-first. For fifteen months, manufacturers must disclose but need not resolve exploitable vulnerabilities in the field— and the disclosure obligation covers the entire fielded installed base and not just products that are intended to be compliant. Vendors need to take note of this and plan accordingly

For IT vendors this gap is an administrative curiosity; their patch pipelines already exist. For OT vendors it is the whole problem. The installed base is precisely where patching is slowest, service relationships are most intermediated, and product knowledge is thinnest — and it is the installed base that the reporting clock now covers.

The Cadence and the Triggers

Article 14 defines two reportable events, and neither is score-based. An actively exploited vulnerability is a factual determination: reliable evidence that a malicious actor has used the vulnerability against the product without permission. There is no CVSS threshold, no EPSS percentile, no KEV-listing prerequisite. A severe incident is defined in Article 14(5): an incident that negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions — or that has led, or could lead, to the introduction or execution of malicious code in the product or in a user’s network. Note the modal verbs. “Capable of” and “could lead to” pull the trigger well before confirmed impact.

Once a trigger fires, the cadence is fixed:

•    Within 24 hours of awareness: an early warning notification, indicating where applicable the Member States in which the affected product has been made available, and whether unlawful or malicious action is suspected. This is a duty to notify, not a duty to have completed the analysis — no CVE identifier or scoring is required at this stage.

•    Within 72 hours: a fuller notification — the general nature of the exploit and the vulnerability, corrective or mitigating measures taken, measures users can take, and a sensitivity flag on the disclosed information.

•    Final report: within 14 days of a corrective measure becoming available for an exploited vulnerability; within one month of the 72-hour notification for a severe incident. The coordinating CSIRT may also demand intermediate status reports in between.

One filing on the Single Reporting Platform reaches both the coordinating CSIRT and ENISA simultaneously; subsequent events affecting the same product can be routed to the same coordinator. The enforcement ceiling is €15 million or 2.5% of global annual turnover, whichever is higher. The SRP itself is scheduled to be operational on the deadline date, with an ENISA-run testing period, registration instructions, and dry-run support in the months before — which makes registration during the test window a concrete, dated action item rather than a someday task.

The Awareness Problem

Every deadline in Article 14 is measured from the moment the manufacturer “becomes aware.” For IT vendors with product telemetry, crash reporting, and bug-bounty pipelines, awareness is near-instantaneous and well-instrumented. OT manufacturers occupy the opposite corner of the visibility landscape. Devices run air-gapped or behind unidirectional gateways. There is no phone-home channel, often by explicit customer requirement. Exploitation evidence sits in asset owners’ historians and SIEMs, not the vendor’s. And the path from a plant floor anomaly to the vendor’s product-security function typically runs through a system integrator, a distributor, or a regional support desk — each adding days.

It is tempting to read this as regulatory arbitrage: less visibility means a later clock start. The reading fails on three counts. First, awareness arrives through channels the manufacturer does not control — a CISA KEV listing, a researcher’s conference talk, a customer email to a regional sales inbox. Any of these starts the clock, whether or not the organisation has noticed that it has noticed. Second, awareness is organizational, not departmental.