EU Cyber Resilience Act: “The AI Did It” Is No Defense

The EU Cyber Resilience Act (CRA) makes companies legally accountable for the security of every connected product they sell in the EU — and it draws no line between human-written and AI-generated code. Vulnerability reporting obligations begin September 11, 2026, with full compliance by December 11, 2027. Penalties reach €15 million or 2.5% of global turnover.

If your engineering team is shipping AI-assisted code into products sold in Europe, the legal question is no longer whether a human or a model wrote the vulnerable line. It’s whether your company can prove it managed the risk either way. That is the shift the EU Cyber Resilience Act forces, and the first hard deadline is now less than four months out.

In a May 29, 2026 analysis for The New Stack, author Luis Villa put the point bluntly: excuses like “the AI did it” will not be accepted by regulators. The CRA treats AI-generated code exactly like code a developer typed by hand — same obligations, same liability.

What is the EU Cyber Resilience Act?

The EU Cyber Resilience Act (CRA), formally Regulation (EU) 2024/2847, is the first “horizontal” cybersecurity law in the EU — meaning it applies broadly across nearly every connected product or piece of software placed on the EU market, rather than to one sector. It has been in force since November 20, 2024, with its main obligations phasing in over the following years. The goal is secure-by-design products that stay patched across their lifetime.

In practice, the CRA requires manufacturers to perform a cybersecurity risk assessment, supply security updates for the product’s expected lifecycle, document that lifecycle clearly, and report actively exploited vulnerabilities and serious incidents. It also mandates a machine-readable Software Bill of Materials (SBOM) — an inventory of every component, including open-source dependencies, inside a product.

Does the CRA cover AI-generated code?

Yes. The CRA makes no distinction between human-written and AI-generated code. If a product with digital elements reaches the EU market, the manufacturer carries the same security obligations regardless of how the code was produced. An AI coding assistant introducing a flaw does not shift or dilute responsibility — it stays with the company that shipped the product.

This matters because AI-assisted development has changed how code enters production. As Villa noted in The New Stack, the law landing “in the midst of AI upending software development” is the whole point: regulators anticipated that teams would lean on generative tools, and wrote the obligations to be technology-neutral. The practical effect is a higher bar for transparency and traceability — immutable audit logs, vulnerability scans in the CI/CD pipeline, and a demonstrable record that someone owned the security review.

Why does this matter for your business?

The CRA converts software security from an engineering preference into a market-access requirement. Non-compliant products can be ordered withdrawn, recalled, or banned from the EU market by national surveillance authorities. For a company that depends on European customers, that is an existential operational risk, not a line-item fine.

The financial exposure is also real. The European Commission has projected that stronger product security could save as much as €290 billion annually in avoided cyber incidents against roughly €29 billion in compliance costs. The framing matters for how a board should read this: the regulation is built on the premise that prevention is an order of magnitude cheaper than cleanup — which is exactly the calculation a vCISO runs when prioritizing a security program against limited budget.

When do the deadlines hit, and what do they cost?

Two dates anchor CRA planning. Vulnerability and incident reporting obligations begin September 11, 2026 — manufacturers will have 24 hours to file an early warning and 72 hours for a full notification of an actively exploited vulnerability. Full compliance, including CE marking and conformity assessment, is required by December 11, 2027.

The penalty tiers, set in Article 64, are:

•       Up to €15 million or 2.5% of global annual turnover (whichever is higher) for breaching the essential cybersecurity requirements in Annex I or the manufacturer obligations in Articles 13 and 14.

•       Up to €10 million or 2% of global turnover for other obligations, such as documentation and market-access duties.

•       Up to €5 million or 1% of global turnover for supplying incorrect, incomplete, or misleading information to authorities.

Several compliance analysts, including Mend.io and HeroDevs, have noted the top tier mirrors GDPR in scale — and EU regulators have shown they will enforce GDPR-level fines. The 24-hour reporting window is the part most teams underestimate: you cannot file an accurate early warning if you don’t already know what components are in your product, which is why the SBOM requirement effectively becomes a 2026 problem, not a 2027 one.

Does the CRA apply to US companies?

Yes, if your products reach the EU market. The CRA applies to manufacturers, importers, and distributors based outside the EU whenever their products with digital elements are sold there. A US software vendor with European customers is in scope, and Brexit does not exempt UK firms either — selling into the EU still triggers the obligations.

This is the detail that catches mid-market firms off guard. A company that has never thought of itself as “regulated” under EU law can fall squarely inside the CRA the moment a connected product or SaaS offering crosses the EU market threshold. The exposure is tied to the market, not to where the company is headquartered.

What should your team do this quarter?

Treat the September 11, 2026 reporting deadline as the forcing function and work backward. The goal this quarter is to be able to answer, within hours of a disclosure, “does this vulnerability affect a product we sell into the EU, and what’s in it?” Concrete moves:

1.     Build a machine-readable SBOM for every product sold into the EU, including all open-source and AI-generated components. You cannot meet the 24-hour reporting window without it.

2.     Map which of your products fall under the CRA based on EU market reach — not on where your company is based.

3.     Wire vulnerability scanning and integrity checks into your CI/CD pipeline so AI-generated code is reviewed before it ships, with an immutable audit trail.

4.     Stand up a coordinated vulnerability disclosure process and confirm someone owns the 24-hour / 72-hour reporting clock.

5.     Check your existing ISO 27001 or NIST work — it covers much of the underlying ground, but CRA-specific artifacts (technical documentation, SBOM, CE marking) still need to be built.

If your organization has European exposure and no clear owner for CRA readiness, a risk assessment that maps your products against Annex I and the Article 14 reporting duties is the fastest way to find the gaps before the September clock starts. Purple Shield helps regulated and EU-facing companies translate requirements like these into a prioritized plan, including the AI security governance needed to account for AI-generated code.

Frequently asked questions

Does the CRA apply to internal tools we don’t sell?

The CRA targets products with digital elements “placed on the market” in the EU. Purely internal tooling that you never sell or distribute generally falls outside its scope. But if a tool is offered to EU customers, bundled into a sold product, or distributed commercially, it likely counts — so the test is whether it reaches the market, not whether you call it “internal.”

We’re ISO 27001 certified — are we already compliant?

Not automatically. ISO 27001 and NIST alignment satisfy many of the underlying security practices the CRA expects, which gives certified firms a head start. But the CRA adds product-specific artifacts — a machine-readable SBOM, technical documentation, conformity assessment, and CE marking — that certification alone does not produce. Treat your certification as a foundation, not a finish line.

Who is legally responsible if a vendor’s AI wrote the vulnerable code?

Under the CRA, the manufacturer placing the product on the EU market carries the obligations, regardless of whether the flawed code came from an employee, a contractor, or an AI tool. “The AI did it” is not a recognized defense. If you integrate a component into a product you ship, you own the security responsibility for it — which makes vendor due diligence and your SBOM the places to catch problems early.

What’s the single most urgent CRA deadline to plan around?

September 11, 2026, when vulnerability and incident reporting obligations begin. From that date, an actively exploited vulnerability triggers a 24-hour early-warning filing and a 72-hour full notification. Meeting that window depends on already having an SBOM and a disclosure process in place, so the practical deadline for preparation is earlier than the date itself suggests.

The CRA rewards companies that can show their work — a clear inventory of what’s in their products, a record of how it was reviewed, and a process ready to fire when a vulnerability surfaces. If your team is facing the September reporting deadline without a clear owner or a complete SBOM, that’s a conversation worth having before the clock starts. Purple Shield works with EU-facing and regulated firms to turn requirements like the CRA into a prioritized, ownable plan.

By Yonatan Hoorizadeh — CISSP, CISM, CRISC, AAISM

Published By: Purple Shield Security

Published: June 1, 2026

Last updated: June 1, 2026