New EU Product Liability Directive: Software is now a product

The new EU Product Liability Directive (EU 2024/2853) fundamentally changes the rules: software is now classified as a product. Data loss becomes a ground for liability. The previous cap on damages has been removed. 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.

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. The delineation follows the CRA logic: mere provision in public repositories does not constitute placing on the market.

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: data loss and data destruction are now independent grounds for liability. If a vulnerability in an open source component leads to the loss of customer data, you are liable as manufacturer.

No cap on damages #

The old Directive capped liability at a maximum amount. This cap has been removed. In the event of a large-scale security incident affecting thousands or millions of users, there is no longer a statutory liability ceiling.

Extended disclosure obligations #

Injured parties can in future demand the disclosure of evidence. If you cannot present documentation of your open source governance, the court may order a reversal of the burden of proof: 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 #

For technically complex products — and software is by definition technically complex — the burden of proof is facilitated in favour of the injured party. This means: it becomes easier to successfully sue you as manufacturer.

Consequences #

No liability cap #

The removal of the cap on damages makes large-scale security incidents 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 missing documentation #

Those who cannot demonstrate due diligence in component selection and maintenance risk reversal of the burden of proof. This means: not the claimant must prove the defect, but you must prove that your product was free of defects.

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): Data loss 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 development risk defence for missing security updates
Art. 12: Joint and several liability of multiple economic operators, no liability cap

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, a reversal of the burden of proof becomes significantly less likely.

Implementation in Germany #

National transposition pending #

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 is running.

Interplay with the ProdHaftG #

The German Product Liability Act is based on the old EU Directive of 1985. It does not currently recognise software liability in the strict sense nor liability for data loss. The national transposition will close these gaps. Until then: the Directive is not directly applicable, but courts can already interpret national law in conformity with the Directive.

Divergences in other EU countries #

Since this is a directive, national transpositions may diverge. Companies that distribute products in multiple EU countries should monitor the respective national transposition.

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)