Product Liability for Software: Why Your Code Will Be Liable Like a Machine from December 2026

IT Law · Digital Law Series, Part 1 | Part 2: Cyber Resilience Act | Part 3: NIS2 · As of: October 2026

A faulty update disables the smart home thermostat, the heating fails in January and a water pipe bursts. Until now, the affected customer would hardly have been able to hold the software provider liable under the Product Liability Act. That is changing, however: product liability for software is becoming the rule – regardless of fault, without a liability cap and with significantly easier proof for injured parties.

In this article, you will learn which software will be considered a product in future, who is part of the liability chain, which damage becomes compensable and the seven steps you can take to protect your company by the cut-off date.

Key points at a glance

• Software is a product – regardless of how it is provided (Section 2(1) no. 3 ProdHaftG-E). This includes SaaS, cloud solutions and AI.
• Updates are relevant to liability: Anyone who retains control after placing a product on the market is liable for faulty updates and for failing to provide security updates.
• No more caps: The EUR 85 million cap for personal injury and the EUR 500 deductible for property damage will be abolished.
• Data loss becomes compensable, provided the data is not used exclusively for professional purposes.
• Courts can order the disclosure of technical documents. Anyone who refuses therefore risks a presumption of a product defect.

What is new? From the 1989 Product Liability Act to Directive 2024/2853

The current Product Liability Act dates from 1989. However, it defines a product as a movable item or electricity. Whether pure software without a physical data carrier is covered was disputed for decades – in practice, however, this was mostly denied. Software providers were therefore mainly liable under contract or tort law, i.e. generally only in the event of fault.

The EU has closed this gap with Directive (EU) 2024/2853 . It entered into force on 9 December 2024 and completely replaces the old Directive 85/374/EEC. Germany is implementing it through a completely revised Product Liability Act.

Timeline at a glance

Important for your planning is the transitional rule (Section 23 ProdHaftG-E): the old law continues to apply to products placed on the market or put into service up to and including 8 December 2026. However, this boundary can quickly become blurred for software with continuous releases – more on this below.

Which software is covered by product liability?

The legislator has deliberately refrained from defining software. Instead, the concept of a product is formulated in a technology-neutral way and is intended to cover future developments as well. In particular, the following are covered:

• Standard software, apps and operating systems, installed locally or downloaded
• SaaS and cloud solutions, regardless of where the code runs
• AI systems, for example for controlling vehicles, machines or medical technology
• Embedded software and firmware in devices and systems
• Digital manufacturing files, for example CAD files or templates for 3D printers (Section 2(1) no. 4 ProdHaftG-E)
• Related digital services, without which a product cannot perform a function (Section 4(2) sentence 2 ProdHaftG-E)

Related services: When the app becomes part of the hardware

A digital service becomes a component of a product in particular if it is essential for its function and was integrated with the manufacturer’s consent. The example from the explanatory memorandum: an autonomous vehicle uses a third-party navigation data service. If the service fails and causes an accident, for example, both the vehicle manufacturer and the service provider may be liable. For manufacturers of connected devices, this means that the partner app or cloud connection must be part of their own risk assessment.

Open-source software: An exception with narrow limits

Free and open-source software is only exempt if it is developed or supplied outside the course of a commercial activity . Anyone who offers, supports or distributes open source commercially as part of a product, on the other hand, falls under the law – even if the download is free of charge. If you integrate an open-source library into your product, you are therefore liable as the manufacturer of the overall product. The government draft makes it clear that it is then you, and not the developer of the open-source component, who will be held liable.

Practical tip: Maintain a software bill of materials (SBOM). In the event of a dispute, it shows which component was installed in which version.

Who is liable? The liability chain in product liability for software

In product liability for software, there are also significantly more potentially liable parties than before. The aim is that injured parties in the EU always find a tangible defendant – even if the manufacturer is based in a third country.

Several responsible parties are also liable as joint and several debtors (Section 15 ProdHaftG-E). You can, however, regulate the internal recourse between them contractually. Towards the injured party, on the other hand, liability can neither be limited nor excluded (Section 18 ProdHaftG-E).

Caution with far-reaching software upgrades

An upgrade can also be a ‘substantial modification’. The decisive factor is in particular whether it changes the performance, purpose or type of the product and thereby creates new risks or increases the level of risk (Section 5(2) ProdHaftG-E). Anyone who equips third-party hardware with their own firmware and resells it, for example, may become a manufacturer themselves.

What damage will be compensable in future?

Product liability, however, is not warranty law. It does not apply because software works poorly, but because it fails to meet legitimate safety expectations and thereby harms people or their property.

What this means for B2B software

However, only natural personsare entitled to claim. Your business customer itself therefore cannot assert a claim under the Product Liability Act. However, if an employee of the customer is injured because your control software operates a machine incorrectly, that employee is entitled to a claim. Pure B2B providers are therefore by no means off the hook.

Practical example: data damage

After a faulty sync update, a photo app deletes the private holiday photos of thousands of users. In future, those affected will therefore be able to demand the costs of recovery from the manufacturer regardless of fault. With a large user base, even small individual amounts quickly add up – especially as the former deductible no longer applies.

When is software defective within the meaning of product liability?

A product is defective if it does not provide the safety required by law or that a person is entitled to expect (Section 7 ProdHaftG-E). What is new, however, is that digital factors expressly count in product liability for software:

• Self-learning systems: If an AI system develops dangerous behaviour after delivery through continued learning, this can constitute a defect.
• Interactions: Foreseeable effects of interaction with other products, for example in a smart home, are taken into account.
• Cybersecurity: Safety-relevant cybersecurity requirements are part of the concept of defect. Consequently, a known, unpatched vulnerability alone can constitute a defect.
• Recalls: Official measures are an indication, but do not in themselves give rise to a presumption of defect.

The update trap

If you retain control over your product after placing it on the market – for example because you roll out updates – you are also liable for defects caused by a later update and for failing to provide security updates (Section 8(2), Section 9(2) ProdHaftG-E). The patch process thus turns from an IT issue into a liability issue.

However, it remains open how courts will apply the cut-off date rule to continuously delivered software. Case law will have to clarify whether a release after 8 December 2026 counts as a new placing on the market. As a precaution, plan as if every new major version will fall under the new law.

Proof in product liability for software: Disclosure and presumptions

Until now, many lawsuits failed in particular because injured parties could not prove the defect. The new law, however, noticeably shifts the balance in favour of claimants.

Disclosure of evidence (Section 19 ProdHaftG-E)

If the claimant makes their claim plausible, the court may, upon application, order you to disclose relevant documents – for example test reports, security concepts or findings from product monitoring. However, disclosure is limited to what is necessary and proportionate. Trade secrets remain protected under the German Trade Secrets Act (GeschGehG) . This is not comparable to US-style discovery, but it still requires a change of mindset.

Statutory presumptions (Section 20 ProdHaftG-E)

A product defect is presumed if

1. you refuse a court-ordered disclosure,
2. the product does not meet mandatory safety requirements, or
3. an obvious malfunction during foreseeable use caused the damage.

In addition, causation is presumed if the damage is typically attributable to the defect identified. Particularly relevant for AI is the complexity clause: if proof is excessively difficult due to technical complexity, it is sufficient for the claimant to demonstrate likelihood (Section 20(3) ProdHaftG-E).

The consequence is therefore clear: in court, it is not automatically the party that developed carefully that wins, but the party that can prove it.

Product liability for software: 7 steps to the cut-off date

1. Clarify whether you are affected: List your products and determine your role for each product – manufacturer, importer, platform or modifier. The answer may also differ within one company.
2. Make an inventory of components: Record third-party and open-source components in an SBOM, including versions.
3. Structure your technical documentation: Requirements, architecture, tests and security concept must be retrievable for each release. Also mark trade secrets from the outset.
4. Formalise update management: First define approval, testing and rollback processes. Also determine how long you will provide security updates and document every rollout.
5. Adapt contracts: Regulate recourse, information obligations and cooperation internally with suppliers, integrators and platforms. Liability exclusions towards injured parties, on the other hand, are ineffective.
6. Review your insurance: Many IT liability policies do not automatically cover no-fault product liability. You should therefore clarify sums insured without a cap, data damage and serial loss clauses.
7. Monitor the legislation: Review the final text of the law once it has been adopted and adjust your measures accordingly.

Conclusion: Product liability for software is a matter for top management

The new product liability law thus ends the special status of software. Here are three key takeaways:

• Any software can give rise to liability – from SaaS tools to AI models, regardless of fault and without a cap.
• Updates are part of liability, not just of support.
• Documentation decides lawsuits. If you cannot prove your development, testing and releases, you will lose in case of doubt.

9 December 2026 is only a few weeks away. Use the time for a structured review.

Would you like to know how strongly your software product is affected? Arrange a no-obligation initial consultation – we will review your portfolio, your contracts and your update process for any need for action.

Request an initial consultation

FAQ: Frequently asked questions about product liability for software

This article is for general information purposes only and does not replace legal advice in individual cases. Section references refer to the government draft (BT-Drs. 21/4297); the adopted version may differ.