Software Is Now a Product in EU Liability Law: An Engineering Checklist Before 9 December

On 8 October 2026 the German Bundestag passed its new product liability law. It is Germany's version of the EU's revised Product Liability Directive, (EU) 2024/2853. The directive's central change is short: software is now a product. Every member state has until 9 December 2026 to put it into national law, and from then on the new rules cover products placed on the market or put into service.

Most coverage so far has been written for lawyers and for people who make physical goods. This post is for teams that ship software: web apps, mobile apps, SaaS, ERP extensions, booking and guest platforms. I'm not a lawyer, and this isn't legal advice. What I can do is take the directive text and turn it into engineering and operations questions you can answer before December.

What actually changed

The 1985 directive was written for physical goods, and whether software counted as a product was never settled. The new directive settles it. Article 4 defines "product" to include software. Recital 13 says this applies "irrespective of whether the software is stored on a device, accessed through a communication network or cloud technologies, or supplied through a software-as-a-service model." A developer or producer of software is treated as a manufacturer.

This is no-fault liability. A person who is harmed doesn't have to show that you were careless. They have to show that the product was defective, that they suffered damage, and that one caused the other. A product is defective when it "does not provide the safety that a person is entitled to expect or that is required under Union or national law" (Article 7). The things a court weighs explicitly include "safety-relevant cybersecurity requirements" and how your product behaves when it's connected to other products.

There are some important limits:

It protects natural persons. The right to compensation belongs to individuals who suffer damage (an insurer or representative can claim on their behalf). A business can't use it to recover its own losses from a software supplier. That remains a contract matter.
Damage is defined narrowly. It covers death or personal injury (including medically recognised harm to psychological health), damage to property, and "destruction or corruption of data that are not used for professional purposes" (Article 6). Property used exclusively for professional purposes is excluded.
Information isn't a product. The content of digital files and "the mere source code of software" are out of scope.
Non-commercial open source is excluded. But if you build open-source code into a commercial product, the liability lands on you as the integrator, not on the upstream project (recital 15).

Why software teams should care, even B2B ones

That damage list matters. If your product is a B2B ERP system and a bug wrecks a client's stock ledger, that's professional data and stays under your contract. In that case the directive changes little for you directly.

A lot of the software I see in small and mid-sized companies isn't purely B2B, though. Picture a hotel group whose guest app issues digital room keys, or a booking platform that stores travellers' passport scans and personal photos. Picture a fitness or health app, or a home-services platform that controls devices in people's homes. Each of these touches natural persons, their property or their personal data. Those are the cases the directive is written for.

Four provisions change how I'd run engineering on those products.

1. Updates keep you on the hook. Under the old rules a manufacturer could escape liability by showing the defect didn't exist when the product left its hands. Article 11(2) removes that defence where the defect comes from software, including updates and upgrades, or from "a lack of software updates or upgrades necessary to maintain safety", as long as these are within the manufacturer's control. Recital 51 says the directive doesn't create a duty to ship updates. What it does mean is that if you control the update channel and leave a known security hole open, that can count as a defect. If the user simply doesn't install an update you supplied, you're generally covered.

2. Big changes can restart the clock. If a software update makes a substantial modification, the modified product counts as placed on the market when that change is made (recital 40). The 10-year expiry period then runs from that date (Article 17). Products placed on the market before 9 December 2026 stay under the old 1985 rules (Article 21). For software that ships continuously, though, exactly how "placed on the market" applies is a question for your lawyer. Don't assume the old regime protects you.

3. You may have to hand over your evidence. Article 9 lets a court order a defendant to disclose relevant evidence once the claimant has made a plausible case. Courts have to protect trade secrets. If you fail to disclose, defectiveness is presumed (Article 10(2)(a)). Courts can also presume defectiveness or causation when technical complexity makes proof "excessively" difficult and the claimant shows a defect is likely. In practice, how well you can explain what you shipped, when, and why becomes part of your defence.

4. Contracts can't push it onto the injured person. Article 15 says liability toward the injured person can't be limited or excluded by contract. The "as is" clause in your terms of service doesn't help against a claim under this directive. Contracts between businesses still matter, though. Where several operators are liable, they're liable jointly and severally, and recourse between them is handled under national law. Article 12(2) lets a micro or small software company agree with the manufacturer that integrates its component that the integrator waives its right of recourse.

Where transposition stands

The directive harmonises fully. Member states aren't supposed to make the rules stricter or looser, except where the directive allows it. The national texts still differ in procedure. A June 2026 Jones Day review found that only Hungary had adopted its law at that point, while Germany, the Netherlands, Sweden, Finland, Poland and several others had published drafts. It also described differences in how drafts handle evidence disclosure and the development-risk defence.

The Bundestag vote on 8 October means Germany has now cleared its main parliamentary step. I haven't confirmed the date the law was formally published, so check the Bundesgesetzblatt if your main exposure is German. Whatever the status in each country, the date in the directive is 9 December 2026.

What I'd do this month

This is the drill I'd run with a team in November. Each item is small. The value comes from doing all of them.

Map your exposure. List every product you ship that people in the EU use as individuals rather than as businesses. For each one, note whether it can plausibly cause injury, damage personal property, or destroy or corrupt personal data. Many B2B tools will drop out here, and that's a useful result in itself.
Find your update channels. For each in-scope product, write down who controls updates: you, an app store, the customer's IT team, or a reseller. Article 11(2) depends on what's "within the manufacturer's control", so you need to know where that control actually sits.
Make releases reconstructable. Pick a release from six months ago. Can you show what code and dependencies it contained, what tests ran, who approved it, and when it reached users? If that takes more than an afternoon, fix it now: tagged builds, kept CI logs, a dependency inventory (an SBOM, if you already produce one), and release notes stored somewhere other than a chat thread. This is the evidence Article 9 can require.
Write down your security update policy. Say how long you support each version and how quickly you aim to fix known vulnerabilities. Then check whether your recent record matches. A policy you don't keep is worse than an honest, shorter one.
Add a "substantial modification" question to change review. For significant releases, ask one question: does this change the product's purpose or performance in a way the original risk assessment didn't cover, or does it change the risk? Record the answer. You don't need a new process, just one field in the one you already have.
List the open source inside your products. If a non-commercial library ends up in a commercial product, the integrator answers for it. Know what you depend on, how up to date it is, and who would notice a security advisory.
Review supplier and customer contracts. If you're a small software company supplying components to a larger manufacturer, ask your lawyer whether an Article 12(2) recourse waiver fits your situation. If you integrate other people's software, check your indemnities and insurance.
Ask your insurer one direct question. Does our current cover respond to no-fault product liability claims about software under the new national laws? Get the answer in writing.

If you also make products with digital elements that fall under the Cyber Resilience Act, much of this overlaps with work you're already doing. The CRA defines security obligations, and the PLD decides who pays when someone gets hurt. The same evidence serves both.

What I'm not sure about yet

I'd rather say so than guess. How courts will apply "placed on the market" to SaaS that deploys several times a day, and where the line falls between a "service" and a "related service", will only become clear through case law. Article 19 requires appeal and highest-court judgments to be published, and the Commission will collect them in a public database. Until then, plan around the directive text, and get advice on the national law where your users are.

Sources

If you'd like a second pair of eyes on your release evidence and update channels before 9 December, a two-week discovery and audit sprint is a good fit. Book a discovery call.