EU Product Liability Directive 2024/2853: What SaaS & Software Providers Need to Know

Post #1 in the sota.io EU Product Liability Directive Series

After four decades of product liability law built around physical goods, the European Union has rewritten the rules — and this time, your SaaS application is a product under the law.

Directive (EU) 2024/2853, the new EU Product Liability Directive (PLD), was published on November 18, 2024. It replaces Directive 85/374/EEC, a 1985 law written before the commercial internet existed. The new directive explicitly covers software, SaaS platforms, digital services embedded in products, and AI systems. EU member states must transpose it into national law by December 9, 2026.

If you ship software to EU users, customers, or businesses — this directive changes your legal exposure starting in late 2026.

Why the 1985 PLD Didn't Cover Software

The original Product Liability Directive from 1985 covered "products" — meaning movable physical items. Courts across the EU were divided on whether software qualified. Some jurisdictions treated software as a service, not a product. Others distinguished between software distributed on physical media (product) versus downloaded or cloud-delivered (service).

This ambiguity gave SaaS providers substantial de-facto immunity from strict product liability claims in many EU markets.

The new directive ends that ambiguity.

Software Is Now Explicitly a Product

Directive 2024/2853 defines "product" to include software in all its forms:

• Operating software (firmware, embedded software)
• Standalone application software (desktop and mobile apps)
• Cloud-delivered software (SaaS platforms, APIs, web applications)
• AI systems and models
• Digital manufacturing files used in 3D printing

The directive draws one important distinction: software embedded in a physical product (e.g., in a medical device or vehicle) has always faced stricter scrutiny. Now standalone SaaS and cloud software faces the same strict liability framework as physical products.

This is not a minor change. Under the old regime, a defective SaaS product that caused damage would typically be pursued under contract law or general tort. Now EU victims can bring strict liability claims directly against the software provider — without proving negligence.

What Is a "Defective Product" Under the New PLD?

The core test is unchanged: a product is defective if it does not provide the safety a person is entitled to expect. But the directive now provides clearer guidance for software:

Defects include:

• Security vulnerabilities that allow unauthorized access or data theft
• Bugs that cause incorrect computation with financial or safety consequences
• Missing updates that leave known vulnerabilities unpatched (this is critical for SaaS)
• AI systems that produce outputs outside their stated reliability parameters

The update obligation: One of the most significant provisions for SaaS providers is the ongoing duty regarding security updates. If a software provider releases a security update and a user suffers damage from a vulnerability that the update would have fixed, the provider may face liability based on the state of the software at the time of injury — not the time of original release.

This means SaaS providers cannot simply ship an update and consider the matter closed. If your update distribution is delayed, opt-in, or dependent on user action, you may still face exposure.

The New Presumption of Defect Rules

The 1985 directive placed the full burden of proof on the claimant — they had to prove the product was defective, that they suffered damage, and that the defect caused the damage. For software this was extremely difficult.

The new directive introduces presumption rules that substantially ease the plaintiff's burden in certain circumstances:

The Complexity Presumption

Where it is excessively difficult for the claimant to prove a defect due to the technical or scientific complexity of the product, the product is presumed defective if the claimant demonstrates:

1. The product contributed to the damage
2. The damage is consistent with the type of defect alleged

For SaaS providers, this is a major shift. A claimant who can show your platform was involved in an incident, and that the incident is consistent with a software defect pattern, can shift the burden to you to prove your software was not defective.

Courts will decide what "excessively difficult" means in practice, but complex cloud platforms, AI systems, and multi-layer SaaS stacks are obvious candidates.

The Non-Compliance Presumption

If your product is non-compliant with a mandatory EU safety standard or regulation, it is presumed defective. This creates a direct link between your compliance posture and product liability exposure:

• AI systems non-compliant with the EU AI Act → presumed defective under PLD
• Products not meeting the Cyber Resilience Act requirements → presumed defective
• Software not meeting NIS2 baseline security requirements (for in-scope services) → relevant to defect assessment

The compliance stack now has direct legal consequences beyond regulatory fines.

Damage Types: Personal Data Is Now Covered

The 1985 directive covered personal injury and property damage but had a minimum threshold of €500 for property damage claims. The new directive expands the scope:

Covered damage under 2024/2853:

• Personal injury (including psychological harm)
• Death
• Property damage (threshold removed in practice by national implementation)
• Destruction or corruption of personal data (new — explicitly covers data breaches, ransomware, and data loss events)
• Economic loss tied to the above

The inclusion of personal data destruction or corruption as recoverable damage is significant. A data breach at your SaaS platform that results in users losing personal data is now potentially a product liability claim, not merely a GDPR enforcement matter.

Who Is Liable: The Economic Operator Chain

The new directive establishes a liability chain covering multiple actors:

For SaaS providers with EU customers:

• If your company is outside the EU, your EU-based importer or distributor faces liability
• If you have no EU presence, establishing who bears liability may require court interpretation
• API providers whose services are integrated into another company's product may also face exposure if their service contributed to a defect

Practical implication: If you are an EU SaaS company reselling or integrating a US-developed product, you may bear liability that the US developer does not.

The 10-Year Liability Window

One often-missed provision: the directive introduces a 10-year liability period running from when the product was placed on the market. This is longer than the typical contractual limitation periods in software agreements.

For long-lived SaaS platforms:

• Liability for defects in code you ship in 2026 can potentially be pursued until 2036
• Security vulnerabilities introduced in legacy code remain a liability source
• Incident records, security logs, and change histories become legally significant for a decade

Additionally, there is a 3-year prescription period from when the claimant knew (or could reasonably have known) about the damage, the defect, and the economic operator.

What This Means for Your SaaS Architecture

The PLD 2024/2853 has architectural implications beyond legal department planning:

Security Must Be Baked In, Not Patched In

The update obligation and defect definition incentivize shift-left security — catching vulnerabilities before release rather than shipping patches reactively. Every unpatched vulnerability is a potential strict liability exposure window.

Documentation as Legal Defense

Proving your product was not defective requires evidence. SaaS providers should maintain:

• Security assessment records (penetration tests, vulnerability scans)
• Architecture decision logs showing security controls
• Change management records for every release
• Incident response timelines documenting when issues were known and remediated

AI System Liability is Real

If you integrate AI models into your SaaS — for recommendations, decisions, automation — those AI outputs are now part of your product. Incorrect, harmful, or unexpected AI outputs may constitute a defect. Document your AI system's intended use, its known limitations, and the guardrails you've implemented.

Contractual Limitations Have Limits

Many SaaS agreements include limitation-of-liability clauses capping damages at subscription fees paid. Under the new PLD framework, these clauses cannot limit liability for personal injury or death caused by product defects. For other damages, contractual limits may be challenged if courts interpret the directive broadly.

Transposition Timeline: What Happens December 9, 2026

EU member states must implement the directive by December 9, 2026. From that date:

• National courts will hear PLD 2024/2853 claims for products placed on the market after the transposition date
• Existing claims under the 1985 PLD continue under the old rules
• Member states may apply stricter standards in some areas

The transition means products shipped after December 9, 2026 face the new regime. For SaaS, this effectively means any customer using your platform after that date is using a "product" under the new rules (since SaaS is continuously delivered).

Immediate Actions for SaaS Teams

Legal / Business:

• Audit your terms of service and limitation-of-liability clauses against PLD 2024/2853 requirements
• Review your EU entity structure — who is the "economic operator" for PLD purposes?
• Assess product liability insurance coverage
• Brief your legal team on the shift from "service liability" to "product liability" framework

Technical:

• Implement continuous vulnerability scanning and documented remediation SLAs
• Create a security update distribution policy that minimizes the window between patch availability and user protection
• Document AI system boundaries, intended use cases, and known limitations
• Establish 10-year data retention for security and incident documentation

Product:

• Add defect reporting mechanisms for users (required for the disclosure procedures under the directive)
• Audit third-party components and AI models you embed — their defects may become your liability

Coming Up in This Series

This is Post #1 of 5 in our EU Product Liability Directive 2024/2853 series:

1. [This post] Introduction & SaaS Scope — what the new PLD covers
2. PLD Software Defect Presumption — how the complexity presumption shifts burden of proof for AI and SaaS
3. PLD Data Loss & Privacy Liability — personal data as damage, intersection with GDPR
4. PLD & EU AI Act Intersection — the double liability framework for AI systems
5. PLD Finale: Complete Legal Risk Checklist — December 2026 transposition preparation

The EU is building an interlocking compliance framework where CRA, NIS2, EU AI Act, and now PLD create overlapping obligations. Understanding how they interact is essential for EU-compliant SaaS development.

sota.io provides EU-sovereign hosting for SaaS applications — built for compliance with European data protection and the emerging EU regulatory stack.