ENISA on Frontier AI: 5 Consequences for the CRA

In January 2026, curl shut down its coordinated vulnerability disclosure programme. AI-generated reports had buried the maintainers, and the project decided the intake cost more than it returned. ENISA now cites that shutdown in an official publication. Here is the part that matters for you: a CRA manufacturer can't make the same call. The Cyber Resilience Act makes a vulnerability disclosure intake a legal requirement from 11 December 2027. curl chose an exit. You won't have one.

That is one of five collisions between ENISA's new position paper and your CRA obligations. ENISA published its view on cybersecurity in the frontier AI era in July 2026. The 16 pages address national authorities, EU policymakers, defenders and service providers. Not one section is written for product manufacturers. The consequences land on your desk anyway.

What ENISA actually published

The paper is a 16-page position note, developed with the EU CSIRTs Network and EU-CyCLONe between May and June 2026. Its legal notice states that it does not create any regulatory obligation. Treat it as a signal of where ENISA's operational guidance is heading, and read it next to the CRA obligations that already bind you.

The core claim is measurable. The window between vulnerability discovery and exploitation has gone from years to months to minutes. Data ENISA cites puts weaponisation at 15 minutes after disclosure and median exfiltration at 72 minutes after initial access. NCSC-NL adds that autonomous agents remove the defender's advantage of private discovery: once an AI agent finds a vulnerability, building the exploit is a computation, not an engineering project. Some exploits now exist before the fix does, which the paper calls negative time-to-exploit.

ENISA is candid about the other side of the equation. The paper states that ENISA's own capacity, along with that of manufacturers and national CSIRTs, needs reinforcement or reconsideration to handle the coming wave of discovered vulnerabilities. The agency responsible for the Single Reporting Platform is telling you, in print, that volumes will strain everyone.

The five sections below each take one finding from the paper and follow it into a CRA obligation.

1. curl closed its vulnerability intake. You can't

By early 2026, AI-generated vulnerability reports had begun to overwhelm parts of the open-source disclosure pipeline. The paper names the damage: a global bug bounty platform paused new Internet Bug Bounty submissions after a surge of mixed-quality AI-assisted reports, and curl ended its CVD programme in January 2026 because maintainers couldn't absorb the volume and noise. The problem is signal dilution. Human reviewers spend their time separating real findings from repetitive, superficial or unvalidated submissions.

An open-source project can close the door. Under the CRA you can't. The regulation requires you to run and enforce a coordinated vulnerability disclosure policy, and to publish a contact address for reporting vulnerabilities in your product. Both duties apply from 11 December 2027. Here is the uncomfortable truth: the CRA was written on the assumption that reports are scarce and valuable. The paper documents a world where they arrive by the hundred, machine-written and unverified. The obligation stays. The assumption behind it is gone.

So your CVD policy needs an AI-era clause. Three things belong in it:

• Validation requirements: state what a report must contain to enter triage. Affected product and version, reproduction steps or a proof of concept, and the observed impact. A report without them gets a request for completion, not a triage slot.
• Deduplication before triage: AI tooling resubmits the same weakness in many wordings. Cluster incoming reports against your known findings first, and count clusters, not emails.
• Triage commitments by severity: publish response times you can hold at 10x today's volume. An acknowledgement SLA you break every week is worse evidence than a modest one you keep.

One more nuance from the paper: ENISA notes that recent months brought a real increase in AI report quality, so a blanket "no AI reports" rule throws away signal. Filter for completeness and reproducibility, not for authorship. Publishing the intake mechanics through security.txt keeps the contact-point duty auditable.

2. AI is inflating what "known exploitable" means

The paper carries a number that changes release engineering. An industry organisation told ENISA it went from about 80 CVEs in Q1 2025 to close to 500 in Q1 2026, and then to roughly 500 per day once it used frontier-AI-enabled tools. ENISA calls this the economic devaluation of discovery: finding flaws is becoming industrialised, so disclosure volume rises faster than anyone can remediate.

The CRA bans placing a product on the market with known exploitable vulnerabilities. Two words carry that rule. AI expands known mechanically: every scanner run against your SBOM surfaces more findings, every quarter. What AI does not change is exploitable, and that is where your compliance evidence now lives. The severity scoring work of separating inherent severity from exploit likelihood stops being an optimisation and becomes the release gate itself.

The chaining point cuts both ways. ENISA warns that low-risk vulnerabilities can no longer be dismissed as harmless, because models chain them into working exploits. So "low CVSS, ignore" is dead as a triage rule. But a raw CVE-count gate in CI dies too: at 500 findings a day it blocks every release forever. What survives is documented exploitability per finding. The paper names the two instruments: EPSS from FIRST for exploit likelihood, and VEX for recording whether your product is affected at all.

3. Every patch you ship maps the hole in your older versions

The paper's section on N-day weaponisation states that patch diffs and binary changes have historically fed reverse engineering and exploit development, and that the exploitation window opens before patch deployment. Frontier AI compresses that reverse engineering from days of specialist work to a computation. The paper also notes that AI-assisted analysis accelerates code understanding of legacy systems.

Now put your own product line into that picture. You release a security fix for version N. The diff describes the vulnerability precisely. If version N-1 shares the affected code and sits past its end of support, your own patch is the best available exploitation guide against your own installed base. At human speed this was a known but slow risk. At machine speed it is same-day.

That changes what two CRA decisions mean:

• The support period, five years minimum in most cases, defines which versions still receive fixes. Versions outside it don't disappear from the field. They stay reachable, and every fix you publish for supported versions teaches attackers about them. Version sprawl is now attack surface, so fewer, longer-lived supported versions beat many short-lived ones. See support period for how the duration is set.
• The end-of-support disclosure you owe buyers before purchase becomes operational information, not shelf paperwork. A buyer running past the date you disclosed is running a product your own patch stream describes to attackers. Say so in the disclosure. The end-of-support disclosure page covers where the date must appear.

NCSC Ireland's advice in the paper is blunt: review asset inventories, prioritise patching discipline, and assess exposure to unsupported components. For a manufacturer the mirror-image duty is to stop the gap between "patched branch" and "abandoned branch" from widening quietly.

4. AI-written patches still ship under your CE mark

ENISA expects remediation to adopt the same tooling as discovery. The paper's verification bottleneck is the result: technical teams face a challenge of scale in auditing and validating AI-generated patches so they don't introduce new vulnerabilities into the codebase. It also describes the pressure on the other side, an Authority Gap where human change boards can't authorise interventions in the minutes available to counter autonomous exploits.

The CRA has no opinion on who or what writes your code. It has a firm opinion on who answers for it. The regulation requires effective and regular security testing of your product, and the declaration of conformity you sign under conformity assessment covers every patch you distribute during the support period. An AI-generated fix that opens a new hole is your non-conformity, at machine speed.

The practical consequence: your patch pipeline needs test evidence that scales with patch volume. Human review of every AI-written line won't scale to 500 findings a day. Documented, automated security testing on the patch path will, and it produces the artefacts your technical file needs. If you adopt AI-assisted remediation, record which patches were machine-generated and what validation each one passed. When a regulator asks how you kept your testing duty honest at that speed, the answer is a log, not a policy statement.

5. Your vulnerability reports become a public track record

The last consequence is the quietest one in the paper. ENISA writes that correlated EUVD data can identify supply-chain hotspots, systemic weaknesses and vulnerability trends accelerated by AI-assisted discovery. Then one sentence further: CRA-related reporting can help validate vendor hardening claims against real-world exploitability and incident patterns.

Read that as a manufacturer. From 11 September 2026 you file actively exploited vulnerabilities and severe incidents within 24 hours through the Single Reporting Platform, then a 72-hour follow-up, then a final report within 14 days of the fix. Each filing lands in an infrastructure that ENISA plans to correlate. Over time, that correlation is a per-vendor security history: how often you were exploited, how fast you fixed, how your record compares with your claims.

Two behaviours follow:

• Write product-security claims you can defend with your own reporting history. "Hardened" and "secure by design" on a datasheet will eventually sit next to your EUVD row. Marketing that outruns the data becomes a market-surveillance conversation.
• Treat reporting quality as reputation, not paperwork. A precise 72-hour notification with real corrective measures reads differently from a minimal one, and ENISA's stated goal is to close the gap between disclosure and coordinated response using this data. The reporting chain itself went live in stages this year, with ENISA onboarding its first CVE Numbering Authorities in May 2026.

The paper's executive summary says the SRP must be used, once functional, to address the challenges of new developments. ENISA committed to that in writing. Your reports are the input.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.