On 9 December, Your Software Becomes a Product. Strict Liability Comes With It.

The Directive That Turned Code Into a Product

For four decades, European product liability law was built around things you could drop on your foot. The 1985 directive imposed no-fault liability on the producers of movable, tangible goods, and the software industry grew up comfortably outside it — shipping under contracts with liability caps, warranty disclaimers, and the accumulated assumption that software is a service you license rather than a product you place on a market.

Directive (EU) 2024/2853 ends that. It entered into force on 8 December 2024, member states must transpose it into national law by 9 December 2026, and it applies to products placed on the EU market or put into service after that date. Its definition of a product expressly includes software, digital manufacturing files, and integrated digital elements. Legal analysis of the new regime is consistent on the breadth: the rules reach software in all forms — firmware, applications, AI systems, embedded, standalone, cloud-based and SaaS — regardless of how it is supplied or accessed.

The operative word is strict. Under a strict liability regime, a claimant does not need to establish that your team was careless, that your process was inadequate, or that a specific engineer made a specific mistake. They need to establish that the product was defective, that they suffered a recoverable kind of damage, and that the defect caused it. Your internal diligence is not the question at issue. It becomes relevant only as evidence, and only if you can produce it.

It is also worth knowing what did not happen. The Commission's proposed AI Liability Directive, which would have created a separate fault-based route for AI harms, was dropped from the 2025 work programme and formally withdrawn, with the notice published in the Official Journal in October 2025. The practical effect is not less liability exposure for AI — it is that the revised PLD is now the main harmonised instrument carrying it, applied through a product-defect lens rather than a bespoke AI one.

The Twelve-Month Window Where Liability Arrives Before the Obligations

Put the two flagship dates next to each other and something awkward appears. The PLD applies to products placed on the market after 9 December 2026. The Cyber Resilience Act's main manufacturer obligations — the essential cybersecurity requirements, the conformity assessment, the CE marking for products with digital elements — apply from 11 December 2027, with the vulnerability and incident reporting duties biting earlier, from 11 September 2026.

That leaves roughly a year in which civil liability for insecure software is fully live while the harmonised technical baseline defining secure software is not yet mandatory. Teams that have been sequencing their roadmap around the 2027 CRA date — a reasonable-looking plan four months ago — have quietly put the compliance work after the liability starts.

The interaction between the two regimes is the part that changes how you should think about compliance artefacts. The PLD lets a court presume defectiveness where a product fails to comply with mandatory safety requirements laid down in EU or national law. Freshfields' analysis of the AI Act interaction spells out the mechanism: demonstrating non-compliance with mandatory product safety requirements triggers a rebuttable presumption of defect, shifting the burden onto the manufacturer to prove the product was not defective. Berkeley Law's read on the CRA describes the same convergence from the other direction — the CRA effectively converts cybersecurity requirements into product liability law.

Read together, your CRA technical file, your AI Act risk management documentation, and your NIS2 vulnerability handling records stop being regulator-facing paperwork and become litigation-facing evidence. A gap in them is not just a supervisory finding; it is a presumption you will be arguing against in a civil claim. That reframing should change who owns those documents inside your organisation — from a compliance function that produces them once, to an engineering function that keeps them true.

Your Source Code, Test Reports and Training Data Are Now Discoverable

The provision engineering leaders should read most carefully is the one about evidence. For the first time in EU product liability law, a claimant who presents a plausible claim can ask a court to compel the defendant to disclose relevant evidence. Analysis of the disclosure rules notes that this reaches design documentation, source code, training data and test reports, and that the disclosure must be made in a form that is accessible and understandable. Practitioners have described it as importing something close to US-style discovery into a body of law that never had it.

There is a second, sharper edge. Failure to disclose, or disclosure that is not intelligible, can itself found a presumption that the product was defective. And where technical or scientific complexity makes it excessively difficult for a claimant to prove defectiveness or causation, the court may presume both if the claimant shows each is likely. Gibson Dunn's summary lists the triggers plainly: non-disclosure of evidence, malfunction during reasonably foreseeable use, excessive difficulty caused by technical complexity, or breach of mandatory protective requirements.

Now translate that into engineering terms, because this is where it becomes an engineering problem rather than a legal one. Whether your organisation can rebut a presumption of defectiveness in 2029 for a release shipped in 2027 depends entirely on artefacts that either exist by default in your pipeline or do not exist at all: the requirement the change traced to, the threat model at the time, the test evidence that ran against it, the review record, the dependency inventory, the decision log explaining why a tradeoff was made. Nobody reconstructs that retrospectively. Either your CI produced it and you retained it, or the story you tell in court is that you have no idea.

This is also the point where heavy AI-assisted development becomes an evidentiary problem and not only a quality one. Code that arrived from an agent, was skimmed, and merged under sprint pressure has an unusually thin trail behind it: no design discussion, no recorded reasoning, often no author who can explain the choice two years later. In a regime where the intelligibility of your evidence is itself a legal test, 'the model wrote it and it passed CI' is not a defence — it is a description of the defect that the presumption is designed to catch.

The Factory Gate Is Gone: Liability Follows Your Updates

Traditional product liability worked on what lawyers call the factory-gate principle: you were judged on the product as it left your control, at the moment it left. That model does not survive contact with software that you patch weekly and models that you retrain quarterly.

So the directive moved the line. Defectiveness is assessed by reference to the moment the product left the manufacturer's control — and for software, control frequently persists. The International Bar Association's analysis puts the reasoning bluntly: where manufacturers have the ability to keep software free of defects and cybersecure by means of updates or upgrades, they have an obligation to do so. Inadequate security and a failure to ship a needed patch are not merely operational lapses. They can be the defect.

That has a direct consequence for the state-of-the-art defence, which historically let a producer escape liability for a defect that could not have been discovered given the scientific knowledge available at the time. It still exists — but it erodes exactly where software lives. As commentary on the software implications notes, liability can now arise from defects that emerge after market placement, particularly where the manufacturer retains control via updates or remote access. You cannot claim nobody could have known about a vulnerability class in 2027 when you were still shipping releases into 2030.

Then there is the tail. The general long-stop is 10 years from placing the product on the market, extended to 25 years for latent personal injury, with a three-year limitation period running from when the claimant knew of the damage, the defect and the liable party. A decade is longer than most codebases keep their original team, longer than most vendor relationships, and considerably longer than most organisations retain CI artefacts.

The operational conclusion is unglamorous and expensive: maintenance stops being a cost centre you negotiate down and becomes a liability control you fund deliberately. That means an explicit security-update SLA, a published end-of-support policy so that the point at which you stop patching is a stated product decision rather than an accident of attrition, and a retention policy for build and test evidence measured in years rather than sprints. The most dangerous asset in an EU software portfolio after December is the product that still has users, still has a market presence, and no longer has an owner.

What Counts as Damage — and What Still Doesn't

Scope discipline matters here, because both over- and under-reading this directive lead to bad decisions. The recoverable heads of damage are death and personal injury — now expressly including medically recognised and medically certified damage to psychological health — damage to property, and the destruction or corruption of data. The old EUR 500 property damage threshold has been removed, which lowers the barrier for smaller claims considerably.

The important qualifiers: property damage and data destruction are covered where the property and data are not used for professional purposes. Pure economic loss — your customer's lost revenue because your API was down — remains a matter for contract law, not this directive. So a B2B workflow tool whose failure costs a client money is not the central case. A consumer-facing application, a connected device, a health or mobility or fintech product, or anything embedded in hardware that people put in their homes and bodies, very much is.

The addition of data corruption as a recoverable head of damage deserves particular attention from software teams, because it is the one that most directly matches how software actually fails. A defective sync routine that destroys a consumer's photo library, a bad migration that corrupts personal records, a botched update that bricks a device — these were previously awkward claims to bring. They are now squarely within a strict liability regime with no minimum threshold.

Insurance is where this lands next, and the market is already moving. Covington's January 2026 analysis of coverage implications recommends that companies expand policy definitions of 'product' to expressly include software and related services such as updates and components, broaden damage definitions to cover psychological harm and data destruction, raise limits with particular attention to defence costs, and extend run-off cover to match a liability tail that now runs to 25 years. Cyber and technology errors-and-omissions policies are the likeliest fit for defective software risk, but exclusions are still being written. If your renewal is before December and nobody has read the product definition in your policy against the directive's, that is a short meeting with a large downside.

Who Is Liable, and Why Your Contract Doesn't Fix It

The list of potentially liable economic operators is substantially longer than the old regime's. It includes manufacturers and software developers, the manufacturer of a defective component, importers and authorised representatives where the manufacturer is outside the EU, fulfilment service providers where no other EU operator exists, distributors who fail to identify the relevant upstream actor when asked, online platforms that present a product as their own, and — importantly for anyone who forks, integrates or heavily modifies third-party software — any party that substantially modifies a product after it has been placed on the market.

If you build software components that other companies embed and ship into the EU, read that list again. A development partner supplying a module, an SDK, a model wrapper or a service that becomes part of someone else's product is a component provider in this architecture, with joint and several liability alongside the integrator and a recourse fight to follow. Non-EU vendors do not sit outside it either; the importer and authorised representative provisions exist precisely to give claimants an EU-based defendant when the developer is elsewhere.

Now the part that surprises commercial teams: you cannot contract out of it. The directive's protections cannot be excluded or limited by contract or by national law as against the injured party. The liability cap in your MSA governs what your customer can recover from you; it does nothing about a consumer's statutory claim. What contracts can still do — and this is the actual work to be done before December — is allocate risk between businesses: PLD-specific indemnities, warranty language covering security updates and component defects, defined obligations for who patches what and how fast, evidence and cooperation clauses so that a disclosure order against one party does not become a scramble, and insurance requirements that match the expanded heads of damage. Note also the carve-out worth checking if you are the small party in the chain: micro and small enterprises can, under conditions, contractually limit recourse claims from an integrating manufacturer.

Open source deserves a precise note, because it is widely misread. The exclusion covers free and open-source software developed or supplied outside a commercial activity. Supply it in the course of a business — including, per the IBA's reading, where there is a chargeable service or a service provided in exchange for personal data — and the exclusion falls away. Commercial open core, paid support, and hosted versions of your own OSS project are inside the regime. The hobby project on GitHub is not.

The AI Code Quality Numbers Just Acquired a Price

Everything above would be a manageable governance exercise if software quality were trending upward. The measurements say it is not, and the gap between how fast code is being produced and how well it is being verified is precisely the gap that strict liability monetises.

Veracode's Spring 2026 GenAI Code Security update is the most direct evidence available. Testing across more than 100 models found the average security pass rate at 56% — almost exactly the 55% recorded when the benchmark started, despite a year of vendor claims about improvement. In other words, generated code introduces an OWASP Top 10 vulnerability in roughly 44% of tested tasks, and that number has flatlined. The category detail is worse than the average: 86% of samples failed to defend against cross-site scripting and 88% were vulnerable to log injection.

Production data points the same way. The Cloud Security Alliance's 2026 research note on AI-generated code vulnerabilities collects the enterprise numbers: AI-assisted developers producing commits at three to four times the previous rate while introducing security findings at ten times the rate, privilege escalation vulnerabilities up 322%, architectural design flaws up 153%, and around 20% of generated samples referencing packages that do not exist — the substrate for slopsquatting attacks. Georgia Tech's tracking of vibe-coding-attributable CVEs went from 6 in January 2026 to 15 in February to 35 in March, with researchers estimating the real figure across the broader open-source ecosystem is five to ten times higher.

The finding that ties this to liability is a perceptual one: close to 80% of developers believe AI tools generate more secure code than humans write, which no available evidence supports. That belief is what turns a tooling change into an exposure. It is the reason review gets lighter exactly where the defect rate is higher, and it is the reason a plausible-looking merged PR is now the most likely origin of a defect you will be asked to explain under a disclosure order.

None of this is an argument against AI-assisted development, and it should not be read as one. It is an argument that the control has to sit at the gate rather than the prompt. Generated code needs the same verification discipline as any other third-party contribution — because from December, that is legally what it resembles: a component of unknown provenance that you placed on the market under your own name.

What to Have in Place Before December

There are about four months left, which is enough time to establish a defensible position and not enough to fix everything. Sequence it by exposure.

First, classify the portfolio. For every product and service you place on the EU market, answer three questions: is it software or does it contain software, is it reachable by consumers or non-professional users, and could a failure cause personal injury, property damage or destruction of personal data. That triage separates products in the strict liability hot zone from those where contract law still governs the realistic failure modes. Do not let this become a legal-department spreadsheet exercise — engineering knows where the risky code paths are and legal does not.

Second, build the evidence pipeline rather than the evidence. A one-off documentation sprint produces artefacts that are stale by March. What holds up is a pipeline that emits evidence as a by-product of shipping: requirement-to-commit traceability, test results retained with build provenance, SBOMs generated per release, dependency and licence inventories, threat models updated when architecture changes, decision records for consequential tradeoffs, and review records that show who verified what. Then set retention to match the liability window, not your storage bill.

Third, make patching a commitment with a name attached. Define and publish a security-update SLA and an end-of-support date for every product in scope. Instrument vulnerability intake so that 'we did not know' is never the honest answer. Because failure to supply a needed update can constitute the defect, an unmaintained-but-live product is now the highest-risk asset in the portfolio, and someone senior should own the decision to keep it alive or to withdraw it.

Fourth, gate the generated code. Static and dependency scanning as blocking checks, not advisory dashboards. Human review that is required to be substantive on security-relevant paths — authentication, authorisation, input handling, cryptography, data deletion. Package existence and provenance verification to kill the slopsquatting vector. And a rule that any code merged into a product in the hot zone has a human who can explain it, which is both a quality control and, given the intelligibility requirement in the disclosure rules, a legal one.

Fifth, run the contract and insurance pass in parallel. PLD indemnities and patching obligations into supplier and component agreements. Evidence-cooperation clauses so disclosure orders do not stall on a vendor that has gone quiet. And a read-through of your product liability, cyber and tech E&O wording against the directive's definitions of product and damage, with attention to defence costs and run-off. None of the legal work is blocked by the engineering work, so both should be running now.

Where a Dedicated Team Changes the Economics

This category of work has a specific shape, and it is worth being honest about why internal teams struggle with it. It is cross-cutting, unglamorous, produces no features, has a hard external date, and then — the part that defeats most organisations — has to keep being true for a decade. Nothing in a normal product roadmap is optimised to produce that.

It is also, structurally, a good fit for a dedicated nearshore team, and for reasons that have little to do with hourly rates. The liability window here is 10 years, extending to 25 for latent personal injury. Whatever evidence pipeline you build has to survive team turnover, and it has to be maintained by people who understand why each artefact exists. A team that stays with the system is not a nice-to-have in that timeframe; it is the mechanism.

This is how we approach it at StepTo. Traceability and evidence generation are treated as delivery infrastructure rather than compliance overhead — build provenance, SBOM generation, test evidence retention and decision records wired into the pipeline from the first sprint, so the artefacts exist because shipping produced them, not because an audit demanded them. AI-assisted development is normal on our teams and on our clients' teams; the control we insist on is the gate, not the prompt. Generated code passes the same scanning, the same substantive review on security-relevant paths, and the same rule that a named engineer can explain what was merged. And maintenance is scoped as an ongoing accountability with a defined update SLA, because a partner who disappears at handover leaves you owning a liability tail with nobody who can answer questions about it.

Timezone alignment matters more for this work than for feature delivery, which is a point worth making concretely. Preparing for the PLD is a continuous negotiation between engineering, legal counsel interpreting national transposition, security, and product — which artefacts are needed, what the update SLA can realistically be, which products should be withdrawn rather than maintained. That is a same-business-day conversation. Senior engineers in Serbia are inside European working hours, which turns those decisions into a morning call rather than a 24-hour round trip per clarification on a programme measured in weeks.

And there is a positional advantage worth naming for European buyers. An EU-adjacent partner operating inside the same regulatory and legal frame you are — GDPR, NIS2, CRA, and now the PLD — is not learning your compliance environment from the outside. The engineers doing the work already understand why the evidence trail matters, because their other clients are answering the same questions on the same deadline.