Transpose by 9 December 2026: What the Revised Product Liability Directive Means When Software Is ‘A Product’

For decades, software sat outside product liability by convention as much as by law. The revised Product Liability Directive ends that. Once national laws land by 9 December 2026, your software is a product, and a defect in it can trigger a claim without anyone proving you were careless.

This is a board briefing, not a legal seminar. Directive (EU) 2024/2853 was adopted in late 2024 and repeals the 1985 product liability regime that most European engineering teams have never had to think about, because that older regime was written for physical goods in an era when software shipped on a floppy disk with a disclaimer. The new text is written for a world where products are updated over the air, driven by machine-learning models, and shipped as pure code. Member States must transpose it into national law by 9 December 2026. Products placed on the market before their national transposition date stay under the old rules; everything after does not.

What changed in one sentence

The definition of “product” now expressly includes standalone software, firmware, integrated digital elements and digital manufacturing files, and the liability is no-fault. That second point is the one boards underweight. No-fault — strict liability — means a claimant does not have to show that your engineers were negligent, that your process was sloppy, or that anyone did anything wrong. They have to show the product was defective, that they suffered harm, and that the defect caused it. Whether you tried hard is not the question. Whether the product met the safety a person is entitled to expect is.

For a physical product that framing has been settled law for forty years. For software it is new, and it lands on estates that were built on the assumption that an end-user licence agreement and a limitation-of-liability clause did the heavy lifting. They will not do it here. This is a statutory liability to persons who suffered harm, not a contract term you negotiated with your customer.

A defect is now a moving target

The Directive lists factors that go to whether a product is defective, and several of them are unfamiliar to anyone who thinks of defects as manufacturing faults frozen at the point of sale. Cybersecurity requirements count. The ability of the product to keep functioning safely counts. And — this is the provision to read twice — the failure to supply the software updates or upgrades needed to maintain safety can itself make the product defective.

Read that against how software is actually delivered. A product you sold and stopped patching does not sit still. The threat landscape moves, a vulnerability is disclosed, and a fix exists but was never shipped to the affected version. Under the old regime the product was judged as it left the factory. Under the new one, a missing security update can be the defect, years after release, on a build you would rather forget. We have written separately on why a missing security update is now a defect and what engineering evidence answers it — the short version is that your patch cadence has quietly become a liability exposure, not just a security metric.

This dovetails with the EU Cyber Resilience Act, which already obliges anyone shipping software with digital elements to provide security updates across a defined support period. The CRA tells you to patch; the Product Liability Directive prices what happens when you did not. The two were designed to interlock, and a firm that treats them as separate compliance projects will find the same gap punished twice.

The burden of proof moved toward the claimant’s favour

The old regime asked injured claimants to prove defect and causation, which was hard to do against a black-box software product they could not inspect. The new Directive rebalances this in two ways that matter for engineering.

First, disclosure. A national court can order you to disclose relevant evidence in your possession where a claimant has presented a plausible case. Trade secrets get some protection, but the days of a claimant being unable to see how the thing worked are over. Second, presumptions. Where a claimant faces excessive difficulty proving defect or causation because of technical or scientific complexity — the Directive has AI and other opaque systems squarely in mind — a court may presume the defect or the causal link, leaving you to rebut it. A failure to comply with a disclosure order can itself trigger a presumption that the product was defective.

The engineering consequence is direct. If a supervisor’s-eye view of your build history, your dependency provenance, your update logs and your test evidence does not exist or cannot be produced coherently, silence is no longer neutral. It can be read against you. The evidence you can assemble on demand becomes part of your defence, and the evidence you cannot becomes part of the claimant’s case.

Who is on the hook, and for how much

Liability reaches the manufacturer of the product and of a defective component, the importer, the manufacturer’s authorised representative, and — where none of those can be identified in the Union — the fulfilment service provider. A party who substantially modifies a product already on the market and puts it back into circulation can be treated as its manufacturer for the modified version, which is worth pausing on if your business integrates, white-labels or materially alters someone else’s software. Distributors can be pulled in if they cannot identify an upstream operator within a set period.

The financial framing also hardened. The old lower threshold that excluded smaller property-damage claims is gone, and the categories of recoverable damage now include the destruction or corruption of data not used for professional purposes, alongside personal injury including medically recognised psychological harm. Data loss as a head of product-liability damage is a genuinely new exposure for anyone shipping software that touches user files.

What to do before the national laws land

Three things a board can ask for now, none of which require the final transposing statute to exist. First, a view of product-defect exposure across the software estate: what you ship, into which markets, on what support and patch commitments, and which builds are in the field unpatched. Second, confirmation that engineering evidence practices — build provenance, update records, security-fix traceability, test artefacts — would survive a disclosure order rather than embarrass you under one. This overlaps heavily with the conformity evidence the CRA CE-marking path already demands, so build it once. Third, a provisioning conversation: this is a balance-sheet risk, and someone should own the question of insurance, reserves and contractual allocation with your component suppliers before a claim, not after one.

The deadline reads like a legal date. It is really an engineering one. On 9 December 2026 the thing that was a licence becomes a product — and the code you shipped and stopped thinking about becomes the code a court can ask you to explain.