The EU Cyber Resilience Act has been on everyone's "we'll deal with it later" list since it entered into force in December 2024. Later is arriving: vulnerability reporting requirements kick in September 2026, and full compliance is mandatory by December 2027.
The timing matters because of what's happening in parallel: most engineering teams have accelerated shipping velocity by leaning hard on AI coding assistants. Copilot, Claude, Cursor — pick one. The code ships faster. The bugs ship faster too. And under the CRA, you own every line of it.
"The AI did it" won't save you when EU regulators come knocking.
That's not just a headline. It's a structural feature of the regulation.
What the CRA actually requires
The CRA applies to any product with digital elements placed on the EU market — hardware, software, apps, APIs. If you have EU customers, it applies to you regardless of where you're incorporated.
The core obligations:
- No known exploitable vulnerabilities at market. You must ship with a clean bill of health — not "we'll patch it post-launch."
- Security updates for the product's supported lifetime, minimum five years.
- Report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware. Not 72. Not "when the patch is ready." 24 hours.
- CE marking required for covered products — same as medical devices and industrial kit.
- Fines up to €15 million or 2.5% of global annual turnover, whichever is higher.
The open source exemption is narrower than it sounds: if you commercialise it — bundle it in a paid product, offer it as a managed service — you're likely in scope.
The AI code liability gap
Here's where it gets interesting for engineering teams in 2026. AI-generated code ships with the same legal weight as hand-written code. The CRA doesn't care how a vulnerability got there — it cares that you shipped it and you're the manufacturer.
AI coding tools are not auditing for regulatory compliance. They're optimising for working code that passes tests. Security posture, patch surface area, long-term maintainability — those are your job, not the model's. The CRA formalises that responsibility into law.
The risk isn't hypothetical. Security researchers have already shown that AI-generated code reintroduces known CVE patterns at meaningful rates. Ship it into a CRA-regulated product without a review layer and you've built a compliance debt that comes due at the worst moment.
What to do
Before September 2026 (vulnerability reporting deadline):
- Inventory every product with EU customers — establish what's in scope
- Set up your 24-hour ENISA reporting pipeline now; it's an operational change, not just legal
- Know who owns the call when an exploited vuln is discovered at 3am
Before December 2027 (full compliance):
- Audit AI-assisted code paths for known vulnerability patterns — automated SAST is the floor, not the ceiling
- Document your vulnerability handling process; you'll need to demonstrate it
- Review your open source dependencies: if a critical upstream project is in your CRA-scope product, you're responsible for its security posture in that context
- Update SLAs to include security update commitments that match the five-year requirement
If you're building AI tooling for enterprise EU customers: you're almost certainly selling a product with digital elements, which means you're a manufacturer under the CRA, not just a software provider. Get legal eyes on this.
Source: The New Stack — "The AI did it" won't save you when EU regulators come knocking
✏️ Drafted with KewBot (AI), edited and approved by Drew.
Top comments (0)