On 9 December 2026 the reformed product liability regime takes effect - and it changes the rules for everyone who develops, operates or earns money with software. For the first time, software, apps, plugins and even security updates explicitly count as a product (Directive EU 2024/2853). A faulty piece of code will then be liable under the same strict rules as a defective physical device: no-fault, with a markedly eased burden of proof and without the previous liability cap. For anyone running an online shop and for all who use or sell custom software, this is not an abstract side issue but a tangible risk - and the right moment to put your update and documentation duties in order now.
What Changes on 9 December 2026
The European Union adopted the new Product Liability Directive (Directive EU 2024/2853) on 23 October 2024; it has been in force since 8 December 2024. Member states must transpose it into national law by 9 December 2026 (Directive EU 2024/2853). This ends, after 39 years, the era of the old 1985 directive that shaped product liability law until now (ADVANT Beiten). In Germany the transposition happens through the Act to Modernise Product Liability Law, whose draft was debated in a first reading in the Bundestag on 4 March 2026 and currently sits with the Committee on Legal Affairs and Consumer Protection (Bundestag).
The key point for practice is the cut-off date: the new rules apply to products placed on the market or put into service after 9 December 2026 (Directive EU 2024/2853). Older products initially remain under the old law - unless they are substantially modified after that date, for example through an extensive software upgrade. Precisely in e-commerce, where shops are continuously extended, connected and updated, this boundary blurs quickly. Anyone planning today should assume that new features and larger releases fall under the new regime from the cut-off date.
9 December 2026 is not a soft target but the binding transposition deadline of the EU directive (Directive EU 2024/2853). Unlike some transitional arrangements, there is no multi-year buffer for existing products once they are substantially modified. Building clean processes for documentation and updates takes lead time - the earlier you start, the more calmly you reach the deadline.
Software Becomes a Product - Who Is Now Liable
The previous product liability law essentially recognised movable physical items as products. Software fell under it only indirectly, for example as part of a device. That changes fundamentally: in future software explicitly counts as a product, regardless of the manner of its provision or use - whether as a download, a pre-installed component, embedded in a device or as a cloud service (PwC Legal). This covers standalone software, AI systems, digital components and digital manufacturing files; even electricity is included (Directive EU 2024/2853). Free and open-source software remains exempt, provided it is supplied free of charge outside a commercial activity (PwC Legal).
For shop operators and developers this means concretely: a custom shop extension, a self-built plugin, a connected app or a digital product you sell can fall within scope. Whoever manufactures software - or substantially modifies an existing product - counts as a manufacturer and bears manufacturer liability. This expansion affects not only classic software houses but every business that builds or significantly adapts digital functions itself. The following comparison shows the most important shifts at a glance.
| Topic | Until now (since 1985) | New (from 9 Dec 2026) |
|---|---|---|
| Software | no standalone product liability | software, apps and AI count as a product |
| Fault | no-fault for physical items | no-fault also for software |
| Security updates | not explicitly covered | omitted updates can be a defect |
| Burden of proof | largely on the injured party | disclosure duty and presumed defect |
| Data loss | not a recoverable damage | destruction of data is recoverable |
No-Fault Liability and an Easier Burden of Proof
Product liability is a no-fault liability. The injured party therefore need not prove intent or negligence, only the defect of the product, the damage and the link between them (Directive EU 2024/2853). New and particularly consequential are the evidentiary reliefs: the law introduces disclosure duties as well as legal presumptions of defectiveness and causation. There is no blanket reversal of the burden of proof, but the position of injured parties is factually strengthened considerably (Ebner Stolz).
The interplay is decisive: if a claimant presents plausible indications for their claim, the court can order the defending side to disclose relevant evidence - such as design documents, test reports or security concepts. If it fails to do so, the defectiveness of the product is legally presumed (Directive EU 2024/2853). A presumption likewise applies where proof would be excessively difficult due to technical complexity - for example with AI systems. And the concept of damage grows: alongside personal injury and property damage, the destruction or corruption of data also counts as recoverable damage in future (Directive EU 2024/2853).
Anyone who cannot present solid records in a dispute risks the court assuming defectiveness. This turns clean, traceable development and test documentation from tiresome formalism into a tangible shield. Audit-proof records of requirements, tests, security checks and releases are, in our experience, the most effective lever for demonstrating your own diligence when it matters.
Update Duty: When a Missing Security Update Creates Liability
One of the biggest changes concerns the lifecycle after the sale. A product can be defective not only at the moment it is placed on the market, but also because a required update is missing. As long as the manufacturer retains control - for example because updates fall within its responsibility - the legitimate safety expectations remain decisive. An omitted security update or inadequate cybersecurity can therefore constitute a liability-relevant defect (Ebner Stolz). This idea closely links product liability with the duties under the Cyber Resilience Act and makes reliable patch and update management in hosting a core task.
For online shops this means: security gaps in self-developed code, outdated dependencies or a stalled update are no longer merely an operational risk but potentially a liability case. A structured process that detects, assesses and promptly closes vulnerabilities is therefore doubly valuable - it protects ongoing operations and at the same time documents your own diligence. How closely security, recovery and evidence go together is also shown by a look at backup and contingency planning.
Routine bug fixes and minor patches generally do not change your legal position (Orrick). It is different when an update or upgrade significantly alters a product's function, performance or risk profile - then it counts as a substantial modification and thus as newly placing it on the market. If such a change is made outside the original manufacturer's control, the modifying party itself moves into manufacturer liability (Gibson Dunn).
Who Is Liable in the Supply Chain - Manufacturer, Retailer, Platform
The directive distributes responsibility along the entire value chain and deliberately closes gaps that arise with digital products and international suppliers (Directive EU 2024/2853). For shop operators this is especially relevant if they source software from third countries, resell digital products or act as an importer themselves. Four roles are worth knowing:
Manufacturer and developer
Whoever manufactures software or substantially modifies a product is liable as a manufacturer - including for self-developed extensions and plugins.
Importer and representative
If the manufacturer sits outside the EU, the importer or EU authorised representative moves into liability. This quickly applies to software sourced from third countries.
Fulfilment and platform
Fulfilment service providers and, under certain conditions, online platforms can also be held liable if no tangible manufacturer exists within the EU.
Retailer as fallback liability
If a retailer cannot name a responsible manufacturer or importer on request, it may be liable itself - an incentive to document your own supply chain cleanly.
What Is Removed: Deductible, Cap and Longer Deadlines
Besides extending liability to software, the reform noticeably lowers the hurdles for claims. Two previous barriers fall away entirely, and the deadlines become partly longer. This significantly increases the practical relevance of product liability.
The previous 500 euro deductible for property damage is abolished, as is the 85 million euro liability cap for personal injury (IHK Hannover). This makes even smaller property damages actionable and removes the cap on large claims. Together with the evidentiary reliefs, experts expect a rising number of product liability lawsuits (Ebner Stolz) - a risk that smaller providers in particular should not underestimate.
| Metric | Until now | New (from 9 Dec 2026) |
|---|---|---|
| Deductible for property damage | 500 € | removed |
| Cap for personal injury | 85 m € | removed |
| Limitation from knowledge | 3 years | 3 years |
| Expiry period | 10 years | 10 years, up to 25 for latent harm |
The regular expiry period stays at ten years after being placed on the market, but can be extended to up to 25 years for personal injuries that only become apparent late (Directive EU 2024/2853). For long-lived digital products that are in use for many years and receive regular updates, this considerably lengthens the window in which claims can arise.
What Shop Operators and Developers Should Do Now
The need to act is real, because software is already a prime target for attackers: the total economic damage from cyberattacks, data theft and sabotage in Germany reached around 289 billion euros in 2025 (Bitkom Economic Protection 2025), and 87 percent of companies were affected by data theft, espionage or sabotage (Bitkom Economic Protection 2025). Anyone offering digital products should therefore see the new liability situation not as a burden but as a reason for robust processes. The following steps have proven a sensible starting point:
- Inventory your software: which self-developed plugins, apps and digital products fall within scope?
- Establish an update and patch process - documented, traceable and with clear responsibilities
- Keep development and test documentation audit-proof so diligence is provable in a dispute
- Set up vulnerability and security management, since cybersecurity becomes a liability-relevant product feature
- Clarify roles and contracts in the supply chain: manufacturer, importer, representative and suppliers
- Review insurance cover and liability clauses with qualified legal advice
These points are best tackled together - technically in ongoing operations and organisationally in clear procedures. In consulting we classify your software inventory, and where data sovereignty and operations meet, a look at sovereign hosting and cloud operations helps. Anyone keeping further 2026 duties in view at the same time, such as the new EU payment rules PSD3 and PSR, bundles the effort sensibly.
Turning Software Liability Into an Advantage
At first glance the reformed product liability looks like an additional risk - in reality it rewards exactly the way of working that already stands for stable, secure software: clean development, traceable documentation and reliable update management. Anyone who anchors these building blocks early not only lowers their liability risk but also delivers better software.
Cleanly documented development
We develop your shop software with traceable test and release documentation - the basis for proving diligence when it matters.
Update and patch management
A structured process in hosting keeps dependencies current and closes security gaps promptly - logged and provable.
Secure architecture and cloud
We set up operations and cloud so that security and data sovereignty are considered from the start.
Processes instead of damage control
Together we align development, operations and documentation so the new duties become plannable rather than a surprise.
Whether a self-developed plugin, a connected app or a sold digital product: what matters is that before 9 December 2026 you know which software falls within scope and how to prove your diligence. We review your software inventory with you, set up documented update processes and bring your development onto a solid footing. Talk to our team to prepare your software for the new product liability in good time - this article, however, does not replace individual legal advice.
This article draws on Directive (EU) 2024/2853 on liability for defective products (scope for software and AI, evidentiary reliefs, deadlines, removal of the deductible and cap), assessments by IHK Hannover, PwC Legal, Ebner Stolz, ADVANT Beiten, Orrick and Gibson Dunn on the transposition, as well as the legislative status in the Bundestag (modernisation of product liability law, first reading 4 March 2026). The market figures come from the Bitkom Economic Protection 2025 report. The figures and dates cited may change during the legislative process; this article is for guidance and does not replace individual legal advice. Status: August 2026.
The EU Product Liability Directive (Directive EU 2024/2853) must be transposed into national law by 9 December 2026; the new German product liability law is intended to take effect at that time (Bundestag). The rules apply to products placed on the market after 9 December 2026. Older products initially remain under the old law, provided they are not substantially modified afterwards.
Yes. Software will explicitly count as a product, regardless of the manner of provision - whether download, pre-installed, embedded or as a cloud service (PwC Legal). AI systems, digital components and digital manufacturing files are also covered (Directive EU 2024/2853). Free and open-source software supplied free of charge outside a commercial activity remains exempt.
For self-developed extensions and plugins you may qualify as a manufacturer. In addition, an omitted security update can constitute a defect as long as control lies with the provider (Ebner Stolz). If you substantially modify an existing product, you also count as the manufacturer of the modified version (Gibson Dunn). Routine minor patches, by contrast, generally do not change the situation.
There is no blanket reversal of the burden of proof, but there are disclosure duties and legal presumptions (Ebner Stolz). If a claimant presents plausible indications, the court can order the disclosure of relevant records; if this is omitted, defectiveness is presumed (Directive EU 2024/2853). That is why solid development and test documentation is the most important protection.
The previous 500 euro deductible for property damage and the 85 million euro liability cap for personal injury are removed entirely (IHK Hannover). The limitation period from knowledge stays at three years and the expiry period at ten years; for personal injuries that become apparent late it can extend to up to 25 years (Directive EU 2024/2853).
We inventory the relevant software with you, develop with documentation and set up a provable update and patch management process in hosting. This way diligence and security can, in our experience, be organised in a provable manner rather than improvised in an emergency. For legal assessment in individual cases we work together with your qualified legal advisers - this article does not replace legal advice.