Your Agent-Written Code Now Ships Into a 24-Hour Reporting Clock

The window is 24 hours. That is what a manufacturer now has to file an early warning once it becomes aware of an actively exploited vulnerability in a product with digital elements placed on the EU market. The obligation started on 11 September 2026, and it applies to products already on the market, not only to what ships from here on. The rest of the Cyber Resilience Act, the general product-compliance obligations, waits until 11 December 2027. The reporting clock did not wait.

The obligations are short enough to quote as our source states them. The early warning is due “without undue delay and, in any event, within 24 hours of the manufacturer becoming aware of the vulnerability or incident.” Within 72 hours the manufacturer must submit a more detailed notification covering “available information on the affected product, the nature, severity and impact of the vulnerability or incident, as well as any corrective or mitigating measures taken or available.” Then a final report: for an actively exploited vulnerability, generally no later than 14 days after a corrective or mitigating measure becomes available; for a severe incident, within one month after the 72 hour notification.

Treated as an engineering requirement rather than a legal one, that schedule asks a specific question of your codebase: within 24 hours, can someone at your company state what a given piece of code does, why it was written that way, and what else it touches?

The clock assumes a codebase somebody can explain

Two things trigger the clock. The first is an actively exploited vulnerability, defined as a security weakness “for which there is reliable evidence that a malicious actor has exploited” it. The second is a severe incident affecting the security of a product. Both triggers start from awareness, which is a state your own detection produces. A better monitoring stack means you become aware sooner, which starts the clock sooner, which is the correct outcome and also an uncomfortable one.

What the 72 hour notification demands is the part worth planning for. Nature, severity and impact of the vulnerability. Corrective or mitigating measures taken or available. That is a causal account of a defect: how it got in, what it reaches, what closes it. In my experience, producing that account in three days depends on something informal: the existence of a person who remembers the change, or a review trail detailed enough to stand in for that person.

Code written by an agent and merged with a thin review trail weakens both. Nobody holds the memory, and the artifact that would substitute for memory is the review, and the review is the step I would expect to compress first when code arrives faster than a human can read it. The provenance question is not about blame. It is about retrieval time under a deadline you did not choose.

Who actually holds the duty

The obligated party named in the regime is the manufacturer. The source names no one else: not the agent vendor, not the model provider, not the open-source maintainer whose library the agent pulled in. The company that placed the product on the EU market answers to the clock.

This matters because the reflex I see when agent-written code causes a problem is to look upstream. That reflex has nothing to point at in the reporting duty as this source describes it. Whatever produced the code, the manufacturer files the early warning, writes the 72 hour account, and ships the final report. We have written before about how compliance requirements accumulate onto whoever owns the artifact, and the CRA reporting duty is a clean instance: the cost lands where ownership sits, regardless of where the typing happened.

Scope is broader than hardware. As the analysis puts it, the Act “applies to hardware and software products made available in the EU whose intended or reasonably foreseeable use involves a direct or indirect connection to a device or network,” and that explicitly includes “software applications … accounting and finance software, games and apps, as well as open-source software supplied in the course of a commercial activity.”

One caveat, because the temptation to over-read this is strong. The source this analysis rests on covers software products made available in the EU. It does not address whether a service delivered purely over the network falls inside the same definition, and it does not use the words SaaS or cloud anywhere. If your product is a hosted service rather than something a customer installs, treat the scope question as open and read Article 2 and the Article 3 definition of “product with digital elements” before you conclude either way.

The prerequisite with a lead time

Reports go to the CRA single reporting platform, operated by the EU Agency for Cybersecurity (ENISA), and are made available to the coordinating CSIRT. Advance registration with the platform is not required.

An EU LOGIN account is a different matter. The guidance is explicit that one should be set up in advance, and the person submitting has to hold that account and be registered as an Assigned Representative of the manufacturer. Both of those are identity steps, and identity steps in any organisation are the ones that take days for reasons unrelated to the technical work: someone is on leave, someone has to approve, someone has to decide whose name goes on the filing.

Discovering that at hour two of a 24 hour window is an avoidable failure. It is also the cheapest item on this page to fix, and it can be done this week by a person who does not need to touch the codebase.

A separate obligation runs alongside the regulator filing. Manufacturers must inform impacted users without undue delay and, where appropriate, all users. No hour figure is attached to that one, which means the timing is a judgement call your communications process has to be able to make quickly rather than a deadline you can plan against.

What to have in place before you need it

The 24 hour filing is an early warning; the source spells out required content only for the 72 hour notification. The 72 hour notification is where the work concentrates, and the inputs to it are things you either have already or spend the three days trying to reconstruct.

Reconstruction is where agent-written code costs you. If your review record says a change passed, but not what it changed or why the reviewer accepted it, you have an audit trail that proves process and explains nothing. The same failure mode shows up in operations that drift without anyone noticing, where the record of what ran exists but the record of what it meant does not. A reporting deadline turns that from an annoyance into a legal exposure.

The useful discipline is the one that makes the harness produce the explanation as a byproduct, rather than asking a human to write it later. Governing the process that generates code, not the model that writes it, gives you something to hand an investigator: what the rulebook required, which mechanical checks ran, which review gate the change passed, and what a reviewer actually looked at.

Do this now

Set up the EU LOGIN account and name the Assigned Representative this week, before anything is on fire. Then run one rehearsal on a real past defect in a product you have placed on the EU market: pick a vulnerability you already fixed, and time how long it takes your team to produce the 72 hour content for it, the affected product, the nature and impact, the measures available. If that takes more than a day, the shortfall is in your change record, and the fix is to make the harness write down why a change was safe at the moment it merges rather than months later when a regulator asks.

This analysis synthesizes Cyber Resilience Act: 11 September 2026 as Key Starting Point for Reporting Obligations (Squire Patton Boggs / The National Law Review, September 2026).

Victorino Group helps engineering teams make agent-written changes explainable fast enough to survive a regulatory deadline. Let us talk.