The clock starts at a moment nobody owns
EU Cyber Resilience Act reporting obligations apply from today. The twenty four hour clock is the half everyone prepared for. It starts at a moment almost no organisation records, and AI-assisted delivery makes that moment harder to locate, not easier.
From today, 11 September 2026, Article 14 of the EU Cyber Resilience Act applies. A manufacturer that becomes aware a vulnerability in one of its products is being actively exploited has twenty four hours to file an early warning, seventy two hours to file a fuller notification, and fourteen days from a corrective measure being available to file a final report. Severe incidents follow the same first two steps with a month for the final report. Everything goes once, through ENISA’s Single Reporting Platform, to the CSIRT designated as coordinator in the country of main establishment, with ENISA receiving it at the same time.
Most of the Cyber Resilience Act does not bite until December 2027. This part bites now, and it reaches back. Products placed on the EU market before full applicability are inside it. A service shipped in 2021 that nobody has thought about since generates the same duty as one released this morning.
Almost all of the preparation I have seen this year has gone into the twenty four hours. Reporting templates. Named owners. Escalation paths. Weekend cover. All of that is real work and none of it is wasted. But it addresses the second half of the sentence. The first half is where the difficulty actually sits.
The trigger is not what most teams assume
The clock does not start when exploitation begins. It does not start when you confirm the exploitation. It does not start when a patch exists. It starts when the manufacturer becomes aware.
Two things follow from that, and they pull in opposite directions.
The first is that severity is irrelevant to the trigger. A critical-scoring vulnerability that nobody is using against anyone carries no notification duty under Article 14. A modest-scoring one under real-world attack starts the twenty four hours immediately. Proof of concept code circulating on a mailing list is not exploitation. Reliable evidence that a malicious actor has used the flaw against a system without the owner’s permission is.
The second is that the regulation has chosen to measure something the manufacturer controls only indirectly. Exploitation is an external event with its own timestamp. Awareness is internal, distributed, and until now has almost never been recorded anywhere.
What awareness is taken to mean
The European Commission’s draft guidance reads awareness as reasonable certainty after an initial assessment, rather than full forensic confirmation. There is a short triage window in front of the clock, so receiving an unexamined report does not by itself start it. That window is not open ended, and a manufacturer that runs a slow assessment should expect the delay to be examined rather than accepted.
Two caveats belong on that reading. The guidance is draft and has not been formally adopted, so it is the best available signal of intent rather than settled law. And the construction is not new. The GDPR gave controllers seventy two hours from becoming aware of a personal data breach, and data protection regulators spent years building a body of interpretation on what awareness means and how long an initial assessment may reasonably take. Anyone who lived through that will recognise the shape of what is coming. I am treating the parallel as precedent rather than as a formal cross-reference, because whether the Commission has deliberately harmonised the two tests is not something I can currently evidence from a primary source.
Companies do not have a moment of knowing
This is the part I think is under-examined, and it is not a legal problem. It is an organisational one.
An obligation that begins at awareness treats the company as a single entity with a single state of knowledge. Companies are not like that. A scanner sees something at 02:14. An alert lands in a channel nobody is watching at 02:15. A duty engineer skims it at 07:40 and files it as noise. A customer email describing the same behaviour arrives at 11:20. Someone senior enough to make the call understands what they are looking at on Thursday afternoon.
Which of those was the moment of awareness? In most organisations the honest answer is that nobody knows, because nothing in that sequence was timestamped as a decision. The gap between the first system that saw the signal and the first person who understood it is pure unrecorded time, and under Article 14 it is deducted from twenty four hours you did not know you were spending.
When that question is asked for real, it will not be asked on the day. It will be asked months later, by someone reconstructing a timeline from logs, tickets and message history. If you have not decided when you became aware, somebody else will decide it for you, with hindsight and without your context.
The part that gets worse with AI-assisted delivery
I have spent a long time arguing that the answer to AI-written code is a record: what was generated, by which model under which configuration, who reviewed it, and how that record travels with the artefact. I still think that. It is the right answer to the question of what you shipped and who stood behind it.
Article 14 asks a different question, and provenance does not answer it. A provenance record is a record of authorship. This is a demand for a record of knowledge. Nothing in a software bill of materials or a review log timestamps the moment a signal arrived and somebody understood what it meant.
The more of the pipeline runs without a person in it, the sharper this gets. If an automated triage step is the first thing to see an exploitation signal, and it classifies and routes that signal without a human reading it, there is a serious argument that the organisation has become aware while no individual in it has. A clock is then running against a company that does not know the clock is running. I do not think anyone has a clean answer to that yet, and I would rather say so than pretend otherwise.
There is a fair counter-argument, and it deserves stating. An organisation with excellent external visibility learns about exploitation early, starts its clock early, and files reports that make it look accident-prone next to a competitor with worse instrumentation and a later moment of awareness. That asymmetry is real, and it rewards exactly the wrong thing. It is an argument for the supervisory authorities to read awareness sensibly, not an argument for anyone to instrument themselves less.
The duty is corporate, the act is personal
ENISA’s platform makes the point concretely at the other end of the process. Notifications are submitted by registered Assigned Representatives, with primary and secondary users. An obligation that belongs to a legal entity is discharged by a named individual with a login.
That is a detail with operational teeth. Someone has to be that person, and someone has to be the second person, before the day you need them. Registration and the supporting guidance were still being revised in the days immediately before the obligation took effect, which is an ordinary fact of a platform going live on the same date as the duty it serves, and also a reason not to discover the process for the first time under a twenty four hour clock.
What a first-signal record looks like
My current answer is thin, and I would rather publish a thin answer than a confident one that has not been tested. Four properties, at minimum.
- One place where every signal that could indicate exploitation lands, whatever its source: scanner, researcher inbox, customer report, threat feed, support ticket.
- A time on each signal, recorded at arrival rather than at triage, so the gap between the two is visible rather than invisible.
- A named person who decides whether a signal has crossed the line into reasonable certainty, and a written record of that decision including the decisions to say no.
- The ability to produce the hour twelve months later, to somebody hostile, without reconstructing it from message history.
The fourth is the one that matters, and it is the one almost nobody can do today. The first three exist to make the fourth possible.
An obligation that begins at awareness is an obligation to organise awareness.
The claim, and what would break it
Here is the prediction, offered so it can be shown wrong. The first serious enforcement argument under this regulation will not be about whether a manufacturer reported. Reporting is visible, and companies that have built a process will do it. The argument will be about when the manufacturer knew, and it will turn on evidence that was created for other purposes and never intended to answer that question.
What would break that prediction is a supervisory practice that treats the moment of awareness generously by default, or an industry convention for recording it that emerges faster than I expect. Either would be a good outcome. Neither is something to plan around.
The teams that come out of the next year well will not be the ones with the best reporting template. They will be the ones that can answer a simple question with a straight face: when did you know, and how do you know that.
Sources
- ENISA, CRA Single Reporting Platform, topic page and Assigned Representative guidance, verified 11 September 2026.
- European Commission, Cyber Resilience Act reporting obligations, on the twenty four, seventy two and fourteen day cascade and the single reporting route.
- European Commission draft CRA guidance of March 2026, superseded by a July 2026 draft, on awareness as reasonable certainty after an initial assessment. Not yet formally adopted.
- Freshfields, on the retroactive scope of the reporting duty and its coordination with parallel regimes, August 2026.
Written by Jason Cruz Falzon, creator of the Cognitive Delivery Framework and the Cognitive Delivery Index. Contact jason@cognitivedelivery.co.uk or visit cognitivedelivery.co.uk.
New material lands week by week
Research, the kernel devlog, news and the papers are all published here first. Get them by email, or follow the feeds.
The newsletter is moving in-house and relaunching soon. Until then, email us to be notified when it opens, or follow the RSS feed.
Or follow the work directly: Research · Kernel devlog · News · CDI assessment