Shipping Software in the EU Now Requires Proving How You Built It
On 11 September 2026, the Cyber Resilience Act made vulnerability reporting a 24-hour obligation. Coverage so far has focused on the deadline itself. The harder problem is what the regulation asks a manufacturer to explain, and how unprepared AI-assisted development pipelines are to produce that explanation..
The Cyber Resilience Act‘s reporting requirements went live this morning. Article 14 lays out a sequence: 24 hours for an early warning to ENISA and the national CSIRT, 72 hours for a fuller notification, 14 days for a final report. Article 69(3) applies this to products already on the market. Code shipped three years ago carries the same obligation as code shipped this morning.
The industry’s response has centered on the Software Bill of Materials, a list of the components inside a product. An SBOM tells a regulator what’s in the product. Which requirement each component satisfies, who approved its inclusion, and what specification justified the decision are different questions entirely, and answering them is what lets a team back up the account of origin and remediation the 72-hour notification and final report call for. The SBOM is necessary; it simply doesn’t reach that far on its own.
Two reporting tracks, both triggered the moment a manufacturer becomes aware. The first covers actively exploited vulnerabilities, defined as “a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” The second covers severe incidents, events that compromise the product’s ability to protect sensitive data or introduce malicious code.
Both definitions contain a clause that broadens the scope: “or is capable of.” An incident qualifies even if it did not succeed. A near miss dismissed because nothing was breached is reportable. Monitoring built around published CVEs will miss this category.
A vulnerability report gives a manufacturer 24 hours for the early warning, 72 hours for the detailed notification, and 14 days to finish it, or one month if the issue counts as a severe incident instead of a straightforward vulnerability. Article 69(3) covers products already on the market. Code shipped years ago, by teams that no longer exist, in products nobody actively maintains, carries the same obligation as a release from last week.
There’s one distinction worth holding onto here: the CRA’s full technical requirements aren’t binding until December 2027, and only the reporting duty is live today. The real question is whether the manufacturer can explain what happened within 24 hours, regardless of whether the product was otherwise secure.
The Third Reporting Clock
Organizations already handling GDPR breach notifications will recognize the pattern. GDPR requires 72 hours. NIS2 imposes similar timelines for essential and important entities. The CRA adds a third clock, running on a different trigger, through a different channel, to a different authority.
The three regulations share deadline structures but define “severe incident” differently. A single event can trip all three: a data breach with a security root cause in an AI-powered product sold in the EU triggers a GDPR notification, a NIS2 notification, and a CRA notification. Three clocks, three authorities, one event. For a risk function already stretched thin, the CRA simply adds a faster clock to the ones already running.
What the SBOM Misses
An SBOM answers one question: what is in the product. A complete SBOM, generated at build time and signed, lists the libraries, the transitive dependencies, the versions. When a CVE drops, a team can check whether the affected library appears in any product.
That’s useful for spotting whether a known vulnerable library made it into a product, but the 72-hour CRA notification asks for something more than an inventory check. The 14-day final report asks for a full account of the vulnerability’s origin, the affected components, and the remediation steps, explanation, not inventory.
None of that gets answered by the SBOM itself, why a component was included, what requirement it serves, who decided to add it and on what basis. It can identify a logging library down to its exact version, but it can’t show that an engineer pulled that library in two years ago, during a sprint, to satisfy a requirement nobody ever wrote down.
The gap between what and why is the distance between a component list and a report a regulator will accept. Many organizations have the list. Few have the explanation, and the CRA’s clock does not pause while someone goes looking for it.
Where AI Widens the Gap
AI generated code makes the problem structural. When a developer writes a function by hand, there is at least a commit message, a pull request, and a reviewer: an imperfect trail, but a trail. When a coding assistant generates the function, there is a prompt. The prompt is temporary, unversioned, unlinked to any requirement, gone the moment the session closes.
Six months later, a vulnerability surfaces, and the SBOM does not cover it, because it was never designed to. Article 13 SBOM obligations concern components sourced from third parties: libraries, packages, open source dependencies. AI generated code is proprietary, written for this product by this team. Dependency lists cover outside components; this code came from inside and was never going to appear on a list.
The only record of why it exists, if one exists at all, is the specification that produced it. Without that specification, the traceability chain breaks entirely. Somebody has to reconstruct what the code does, why it was written, and what requirement it fulfills, from scratch, under a deadline that does not care how the code was produced.
USENIX researchers measured a sharper version of this: commercial code models hallucinate nonexistent package names at a rate of at least 5.2 percent. Attackers register those names before developers do, a practice called slopsquatting. When a model recommends one of those packages and a developer installs it, the component enters the product without a specification, without a review, without a traceable decision record. The SBOM will eventually list it, once someone notices it is there. It will not explain why it was added, or who was responsible.
The Specification as the Source of Truth
Answering “why is this here” inside a regulatory deadline depends on one thing: whether the code, the dependency, and the decision behind it trace back to a written requirement. A requirement that outlives the prompt, the sprint, and the engineer who wrote it.
The industry default treats code as permanent and the specification as temporary, written during planning, discarded once implementation starts. Under the CRA, that model breaks. The specification becomes the permanent source of truth. Code gets regenerated from it, and dependencies get justified by it. When a vulnerability surfaces, the answer to “why is this here” sits in a documented requirement, something a departed employee’s memory or an expired chat log was never going to provide.
None of this prevents vulnerabilities. A team that complies fully with its own specifications can still ship an exploitable component; a specification proves what was intended, but unforeseen outcomes still happen. What changes is the 72 hours after a vulnerability is found: a team with traceability spends that window explaining, while a team without it spends it searching. The deadline does not wait.
This is the principle rinf.delivery is built around: a structured, machine-readable specification acts as the permanent reference point, and each artifact carries a traceability chain back to the requirement that produced it. When the clock starts, the answer is a lookup against a record that already exists, the kind of answer that used to take three days of piecing together repositories, pull requests, and colleagues who no longer work there.
Three Questions for the VP of Engineering
When a vulnerability surfaces in your product, can your team explain within 72 hours why the affected component is there and what requirement it serves?
If an AI generated the code or recommended the dependency, does a specification exist that justifies its inclusion, or is the only record a prompt that is already gone?
For products shipped years ago, by teams that have since dispersed, can you still trace a vulnerability back to the decision that introduced it?
Companies running on rinf.delivery can answer those questions from a specification that is still there long after the prompt session ended. The rest are reconstructing the answer from memory and chat logs, against a clock that does not wait for anyone to remember.