Tech trends19 October 20266 min. Reading time

On 8 October 2026, the Bundestag adopted the law on the modernisation of product liability law. It implements the EU Product Liability Directive (EU) 2024/2853 and is scheduled to be implemented on 9 September. Entry into force on December 2026. The most important change for anyone who develops, sells or incorporates software into products: In the future, software will explicitly be considered a product – with strict liability, as previously only for physical goods. This post explains what changes, who it hits and what you should do specifically in the remaining weeks.

Note: This article classifies the new regulation from a technical point of view and does not replace legal advice. For the examination of your contracts and liability risks, talk to your legal department or a specialist lawyer.

What fundamentally changes

The previous product liability law dates back to 1989 – a time when software was sold on disks and nobody thought about updates from the cloud. Whether software is a “product” in the sense of the law has been controversial for decades. This question is now answered: software is a product, regardless of how it is provided or used Whether as an installed application, as firmware in a machine, as an app or as a cloud service. Also explicitly covered are AI systems.

Product liability means: The manufacturer is liable for damage caused by a defective product, without having to prove a fault. It is sufficient that the product was defective and damage was caused.

The five most important innovations for software

1. Updates are part of the product

Until now, it was the state of the product when it was placed on the market that mattered. In the future, what happens afterwards also counts: As long as the manufacturer controls the software via updates or upgrades, he remains responsible. An update that introduces an error can trigger liability – and so can an missing security updatethat would have been necessary to keep the product safe.

2. Cybersecurity becomes part of the error question

Whether a product is defective is measured by the security, which can legitimately be expected. In future, this will explicitly include cybersecurity requirements. Who has binding security requirements – for example, from the Cyber Resilience Act – does not comply, must expect that a court suspects the defectiveness.

3. Anyone who changes significantly becomes a manufacturer

Anyone who significantly changes a product outside the control of the original manufacturer and re-markets it is liable as a manufacturer. This applies, for example, to integrators who profoundly rebuild an existing solution or companies who embed and adapt software into their own products.

4. Easier evidence for victims

Damaged persons have so far hardly been able to prove errors in complex software. The new law therefore provides that courts can order the disclosure of evidence and knows presumption rules: Those who do not provide relevant documents or where technical complexity makes it excessively difficult to prove may have to prove themselves that their product was error-free. At the insistence of business, a special procedure for the protection of trade secrets has been introduced – Source code and design data therefore do not have to go unprotected to the opposite side.

5. More stakeholders in the supply chain

In addition to the manufacturer, importers, authorised representatives, fulfillment service providers and online platforms can also be liable under certain conditions – especially if the manufacturer is located outside the EU. For companies that redistribute software or components from non-European providers, this becomes relevant.

What damages are covered – and which are not

Here is a point that is lost in many reports: Product liability primarily protects Consumers. Personal injury, damage to privately used objects and – new – the Loss or damage of data that is not used professionally. Damage to objects or data that are used exclusively for work is not included.

Does this mean that pure B2B software is not affected? Not quite. First, B2B software can cause personal injury – for example as control software for a machine, in medical technology or in the vehicle. Secondly, software often ends up at the end customer via detours, for example as a component in a device that is sold to consumers. And thirdly, the manufacturer of the final product will try to keep himself harmless at the supplier of the faulty component.

When does the new law apply?

The law shall be 9. December 2026 enter into force. It applies to products placed on the market or put into service from that date. For software with regular updates, however, this deadline is less clear than for a machine that is delivered once: A significant change after the deadline can bring the product under the new law. Anyone who continuously develops software should therefore assume that the new law will become relevant for him practically immediately.

Who is particularly affected

  • Software vendors and SaaS providerswhose products are used by consumers or may cause personal injury.
  • Machinery and equipment manufacturers with own control and operating software – especially from the 20th. January 2027 also the new Machinery Regulation with extended requirements for software and cybersecurity applies.
  • Automotive suppliers with control unit software and over-the-air updates.
  • Medical technology and healthcarewhere software errors can directly endanger people.
  • AI function providerswhose behavior changes through learning or model updates after delivery.
  • Integrators and dealers, which incorporate software from non-European manufacturers into their products or distribute it in the EU.

What you should do technically now

Liability cannot be excluded contractually from victims. What you can influence is the risk of making a mistake at all – and your ability to prove in the event of a dispute that you have worked carefully. Five measures are central to this:

  1. Software inventory and SBOM. You need to know which components and libraries are in your products, in which version and by whom. A software parts list (SBOM) becomes mandatory for products with digital elements anyway with the Cyber Resilience Act and is the basis for everything else.
  2. Update and patch process. Specify how long you will deliver security updates, how quickly critical gaps will be closed, and how customers will receive the updates. A documented process is worth gold in a dispute.
  3. Understandable development. Version management, code reviews, automated testing and clean release documentation aren’t just good practice – they’re your proof that an error isn’t due to a lack of care.
  4. Keep AI functions controllable. Where AI is used, model versions, training data stands and test results should be documented. An AI system whose behavior changes unnoticed is a liability risk.
  5. Examine suppliers and contracts. Clarify with suppliers of software components, who is responsible for what in the internal relationship, and have your contracts and your company liability checked for the new situation.

Conclusion

The new product liability law ends a decades-old grey area: software is liable like any other product, and the responsibility does not end with the delivery, but continues over each update. For most companies, this does not mean a completely new world, but a shift of priorities – away from “the main thing, it is running” to traceable development, well-maintained dependencies and a reliable update process. Whoever tackles this in the coming weeks is on the 9. December not under pressure.

What other mandatory dates 2027 are coming to IT, we have in our overview of the Mandatory IT dates 2027 put together. If you want to check how your software performs in terms of update process, dependencies and documentation, talk to us we support them in the Development as well as the inventory of existing systems.

From practice to practice

Would you like to implement this in your company? We support you pragmatically – from the idea to the operation.