New EU Product Liability Directive: Software is expressly a product

The new EU Product Liability Directive (EU 2024/2853) fundamentally changes the rules: software is expressly classified as a product. The loss of privately used data becomes a ground for liability. There is no general liability cap. For companies that manufacture software or integrate open source components into their products, a new liability risk arises that directly affects the due diligence required in component selection.

The new rules apply to products placed on the market or put into service after 9 December 2026.

Who is affected? #

Software manufacturers #

Any company that develops software and makes it available on the EU market falls under the new product liability — regardless of whether the software is distributed independently or delivered as part of a larger product.

Integrators of open source components #

If you integrate open source software into your product, you are liable as manufacturer for the entire product. This applies to transitive dependencies as well: a vulnerability in a library used by your library can trigger your liability.

Importers and distributors #

Those who import or distribute software into the EU may also be held liable under certain circumstances — particularly when the manufacturer is based outside the EU and is not reachable.

Who is not affected? #

Open source developers who do not place their software on the market in the course of a commercial activity are not subject to product liability. What matters is solely the absence of commercial activity, not where the code is published. Anyone who provides open source in a commercial context therefore does not escape liability merely because the code sits in a public repository.

What changes? #

Software is classified as a product #

The previous Product Liability Directive of 1985 was designed for physical goods. The new Directive clarifies: software — whether standalone or embedded — is a product within the meaning of liability law. This includes operating systems, applications, libraries, firmware, and SaaS components.

Data loss as a ground for liability #

Previously, product liability was limited to personal injury and property damage. The new Directive expands the concept of damage: the destruction and corruption of data are covered, provided that data is not used for professional purposes. If a vulnerability in an open source component destroys your users' private data, you are liable as manufacturer. So check who ultimately operates your software: as soon as consumers are among them — the norm for apps, portals, shops, and connected devices — this ground for liability is open against you.

No general liability cap #

The old Directive allowed member states to set a maximum amount. The new one provides for no general liability cap. In the event of a large-scale security incident affecting thousands or millions of users, the recoverable damage adds up unchecked.

Extended disclosure obligations #

Injured parties can in future apply for a court order to disclose evidence. If you fail to comply with such an order to disclose relevant evidence, the defectiveness of your product is presumed: you must then prove that your product was not defective — instead of the injured party proving the defect.

Cybersecurity as a defect criterion #

Art. 7 of the Directive defines when a product is considered defective. The criteria list in Art. 7(2) names under letter (f) expressly the "safety-relevant cybersecurity requirements". Cybersecurity is thus no longer merely a regulatory obligation under the CRA but a liability law characteristic: if your product fails to meet relevant cybersecurity requirements, it is assessed as defective under product liability — regardless of whether the actual functionality is still given. Unpatched vulnerabilities, missing security updates, or an unmaintained open source supply chain are direct indicators of defect.

Facilitation of burden of proof for injured parties #

Where excessive technical complexity makes proof unduly difficult and the injured party establishes that the defect or the causal link is likely, the burden of proof is facilitated. This means: it becomes easier to successfully sue you as manufacturer.

Consequences #

No liability cap #

Without a general liability cap, large-scale security incidents become an existential risk. If a vulnerability in an open source library affects millions of users, the total damage can threaten the existence of your company.

Reversal of burden of proof for failure to disclose #

Anyone who fails to disclose evidence ordered by a court risks reversal of the burden of proof: the claimant no longer has to prove the defect, you have to prove that your product was free of defects. In practice this means you have to be able to produce what you did about selecting, testing, and maintaining your components — and you cannot disclose what you never documented.

Legal references (Directive EU 2024/2853) #

The key articles of the new Product Liability Directive:

Art. 4 No. 1: Software is a product within the meaning of the Directive
Art. 6(1)(c): Destruction or corruption of data not used for professional purposes as compensable damage
Art. 7(2)(f): Cybersecurity requirements as a criterion of defectiveness
Art. 8: Manufacturer's liability for defective products and components
Art. 9: Disclosure obligation for evidence upon request
Art. 10: Facilitation of burden of proof in cases of technical complexity
Art. 11(2): No "became defective later" defence where necessary security updates within the manufacturer's control are missing
Art. 12: Joint and several liability of multiple economic operators

Interplay with the CRA #

The Product Liability Directive and the Cyber Resilience Act complement each other: the CRA defines which security requirements products must meet. The Product Liability Directive defines what happens when they do not. A violation of CRA requirements can be used as evidence of product defectiveness. Conversely, compliance with the CRA does not automatically protect against product liability claims — but it is strong evidence of due diligence.

Liability for the entire supply chain #

You are liable for your entire product, including all integrated components. A vulnerability in a transitive dependency can trigger your liability, even if you never consciously selected the component. The duty of care extends to your entire software supply chain.

What OTTRIA covers #

Liability risk	OTTRIA service
Lack of due diligence in component selection	Documented assessment of all OSS dependencies: project health, maintainer maturity, known vulnerabilities
Unpatched vulnerabilities	Ongoing monitoring, upstream fixes, patches including for abandoned projects
Missing documentation	Audit-ready remediation history: what was done when, by whom, with what result
Unknown dependencies	SBOM evaluation and monitoring including transitive dependencies
No evidence for burden of proof	Systematic OSS governance documentation as evidence of due diligence
Abandoned projects in the supply chain	Take over maintenance or provide patches

What OTTRIA does not cover #

Your liability: Product liability lies with the manufacturer. OTTRIA reduces your risk through documented due diligence but does not assume your statutory liability.
Your product decisions: Which components you use and which risk you accept is your decision.
Non-OSS components: OTTRIA covers exclusively open source dependencies.
Your systems: OTTRIA does not work in your systems.
Legal advice: OTTRIA provides technical governance and documentation, not legal counsel.

What do you present to the auditor? #

In a liability case, the documentation decides.

OTTRIA delivers #

Evidence of systematic OSS governance: processes, responsibilities, regular assessments
Documentation of due diligence in component selection: which components were assessed, against which criteria, with what result
Remediation history for vulnerabilities: when was a vulnerability identified, when assessed, when remediated
SBOM with complete dependency structure
Evidence of ongoing monitoring and proactive maintenance

You add #

Your product decisions and risk assessments
Integration into your internal development processes
Your overall documentation for the product

This reduces your liability risk through documented due diligence: if you can demonstrate that you proceeded systematically and in accordance with the state of the art in the selection and maintenance of your open source components, you can examine and rebut allegations on the substance instead of having to accept them. It does not undo a genuine product defect. But it decides what you bring to the proceedings.

Implementation in Germany #

National transposition by December 2026 #

The new EU Product Liability Directive is a directive, not a regulation. It must be transposed nationally. In Germany, it will amend or replace the existing Product Liability Act (ProdHaftG). The transposition deadline for member states ends on 9 December 2026.

Interplay with the ProdHaftG #

The German Product Liability Act is based on the old EU Directive of 1985. The new Directive expressly covers software and extends liability to the destruction or corruption of data not used for professional purposes. The new rules apply only to products placed on the market or put into service after 9 December 2026; older products remain under the previous regime.

Divergences in other EU countries #

The Directive largely harmonises the liability rules — national divergences are permitted only where it expressly allows them. For you this means a cleanly documented open source governance carries across every EU market you ship to; you do not need country-specific evidence. What can diverge are national procedural rules, for instance on court jurisdiction.

Documented due diligence is your best protection against product liability claims. Let us examine together how your open source governance is set up.

Schedule initial consultation

Download Product Liability factsheet (PDF)