EU Product Liability Directive 2024: Software Is Now a Product — SaaS Developer Exposure Guide

The EU's new Product Liability Directive (Directive 2024/2853/EU) entered into force on December 9, 2024. Member states have until December 9, 2026 to transpose it into national law. When they do, software — including SaaS components — becomes explicitly subject to EU product liability for the first time in history.

This is not a marginal regulatory update. The previous PLD (Directive 85/374/EEC) explicitly excluded software. Courts across Europe spent four decades debating whether software was a "product" or a "service." The 2024 directive resolves that debate: standalone software, embedded software, and software that enables or controls physical products are all products under EU law.

If your SaaS platform processes EU user data, controls physical devices, makes automated decisions affecting users, or includes security-sensitive code — read this guide before the December 2026 deadline.

What Changed: The Old PLD vs. Directive 2024/2853

The 1985 Directive: Software Excluded by Design

The original Product Liability Directive (85/374/EEC) defined "product" as "all movables, with the exception of primary agricultural products and game, even though incorporated into another movable or into an immovable." Courts consistently held that software supplied as a service was not a "product" under this definition — because software is intangible and services were excluded.

SaaS developers operated in a product liability vacuum: you could cause harm through defective code and face no strict liability claim under the PLD. Users had to rely on contract law, tort law, or GDPR remedies — all of which require proving fault or negligence.

Directive 2024/2853: The Paradigm Shift

Article 4(1) of the new directive defines "product" to include:

• Movables (as before)
• Electricity
• Software — standalone or embedded
• Digital manufacturing files (e.g., CAD files for 3D printing)

Recital 12 makes the developer impact explicit: "Software, including its source code and updates, can constitute a product within the meaning of this Directive where it is placed on the market or put into service independently or in conjunction with a product."

Article 4(8) defines "software" broadly: "any executable code that processes data, including code incorporated in devices or code that controls their operation." This covers web applications, APIs, firmware, ML models, and automated decision systems.

The Core Liability Framework: Strict Liability for Defects

No Fault Required (Article 4(6) + Article 9)

Product liability under the directive is strict — the injured party does not need to prove that the software developer was negligent. They must prove three things:

1. The product was defective
2. They suffered damage
3. The defect caused the damage

That's it. You can have followed every best practice, implemented OWASP recommendations, passed all security audits — and still be liable if a defect caused harm.

What Is a Software Defect? (Article 7)

A product is defective when it "does not provide the safety which a person is entitled to expect, taking all circumstances into account." For software, the directive specifies relevant circumstances including:

Article 7(1)(a): The presentation of the product — including instructions and warnings. If you ship software without adequate security documentation, the lack of instructions itself can constitute a defect.

Article 7(1)(b): The reasonably foreseeable use — including misuse. If your API can be used in ways that cause harm, and that misuse was foreseeable, you may be liable even if the user misused it.

Article 7(1)(e): Any regulatory requirements the product must comply with. Software that violates GDPR Article 32 (inadequate security) or NIS2 Article 21 (insufficient cybersecurity measures) may be defective under the PLD — creating a dual regulatory exposure.

Article 7(1)(f): The moment the product was placed on the market or put into service.

Article 7(2) — The Critical Software Provision: "A product shall also be considered defective where, after it has been placed on the market or put into service, the necessary security updates have not been provided within the period during which the operator could legitimately expect such updates."

This is the most significant clause for SaaS developers. Failing to provide security updates — even after the initial release — can create liability. There is no statute of limitations restart with each update; the 10-year liability period runs from first placement on market.

Does the Directive Apply to Your SaaS?

The SaaS vs. Software Distinction

The directive creates an important nuance. "Services" as such remain outside the PLD scope. But SaaS is not purely a service: it includes software components that can be defective independently of the service relationship.

Scenario 1 — Pure API Service: Your SaaS provides a hosted API endpoint. Users send requests, you process and respond. No standalone software is distributed. This is likely a service under the directive — PLD probably does not apply directly.

Scenario 2 — Client-Side Software Component: Your SaaS includes a JavaScript SDK, a desktop app, a mobile app, or a WebAssembly module that runs in the user's environment. This component is software placed on the market — PLD applies.

Scenario 3 — Embedded Software Controlling Hardware: Your SaaS controls IoT devices, industrial equipment, or vehicles via a cloud-connected software stack. The software component controlling the device is clearly a product.

Scenario 4 — AI/ML System Making Autonomous Decisions: Your SaaS includes an AI model that makes automated decisions affecting users (credit, hiring, healthcare). Recital 14 explicitly addresses AI systems: they can be defective under the directive. The AI Act cross-reference (Article 4(4)(c)) brings AI systems into scope.

The Economic Operator Definition (Article 4(3))

The directive introduces "economic operator" — a broader category than traditional manufacturer:

• Manufacturer — entity that develops or produces the software (or presents itself as such)
• Importer — brings software from outside the EU to the EU market
• Distributor — makes software available in the EU supply chain
• Fulfillment service provider — stores, packages, or ships on behalf of third parties
• Online platform operator — operates a marketplace where third-party software is offered

If you operate a platform where third-party developers publish apps, extensions, or integrations — you may be an economic operator liable for third-party software defects, unless you take active steps to disclaim and redirect liability to the original developer.

The Burden of Proof Shift (Article 10)

Standard Cases: Claimant Must Prove

In most cases, the claimant must prove the defect, the damage, and the causal link. For software, proving a causal link can be technically complex — claimants need to demonstrate that a specific code defect caused a specific harm.

The Critical Article 10 Presumptions

Article 10(2)(b): Where the claimant faces "excessive difficulty" in proving that the product is defective due to "technical or scientific complexity," national courts shall presume the defect if the claimant establishes:

1. The product contributed to causing the damage
2. It is likely the product was defective

This reversal is significant. For security breaches, data exfiltration, or AI-caused harm — courts can presume defectiveness once basic contribution is shown, shifting the burden to you to prove non-defectiveness.

Article 10(4) — The Complexity Limitation: Courts can refuse the presumption if the defendant demonstrates that "it was not feasible to establish the defect without exposing the proprietary information of the defendant." But relying on trade secret protection as a liability shield carries reputational and legal risk.

What Damages Are Covered? (Article 6)

The directive covers:

• Death and personal injury — including psychological harm
• Damage to property (€500+ threshold for minor damage claims)
• Destruction or corruption of data — explicitly included for the first time

The data destruction coverage is new and significant. Data loss caused by defective software is now a recoverable damage under the PLD. If your storage, backup, or database software has a defect that destroys user data — that's a PLD claim, not just a contract or GDPR claim.

The €500 threshold means that minor data corruption claims (under €500) are filtered out — but any substantial data loss easily exceeds this.

What Is NOT Covered

• Pure economic loss (lost profits) — outside PLD scope, requires contract or tort
• Business interruption without data damage — outside scope unless accompanied by covered damages
• Regulatory fines (GDPR, NIS2) — separate regime, not PLD

The 10-Year Liability Period (Article 14)

Claims must be brought within 10 years of "placing the product on the market or putting it into service." For software with continuous updates:

• The 10-year clock starts from the original release date
• Each security update does not restart the clock
• If you withdraw a software version from the market, the clock may stop for new claims based on that version

Practical implication: If you release v1.0 in January 2026, you're potentially liable for defects in that version until January 2036 — even if you've shipped v5.0 by then. Maintain your release archives and security documentation for 10+ years.

The Security Update Obligation in Detail (Article 7(2))

This provision deserves extended analysis because it directly affects SaaS developers' operational practices.

What Triggers the Obligation

You must provide "necessary security updates" during the period "operators could legitimately expect such updates." Courts will assess this based on:

1. Market practice — What do similar software vendors provide?
2. Product documentation — Did you promise updates? For how long?
3. Regulatory context — CRA Article 14 (24-hour active exploitation notification), NIS2 Article 21 (security monitoring) establish baseline expectations
4. Product lifecycle — A critical infrastructure SaaS component has different expectations than a personal productivity app

Intersection with CRA

The Cyber Resilience Act (CRA), entering force in 2027, adds mandatory requirements for software security updates. CRA and PLD create a compliance reinforcement loop: CRA establishes the update obligations, PLD creates the liability when those obligations are breached.

A CRA violation (failing to provide security updates within 24 hours of exploiting an actively exploited vulnerability per CRA Article 14) can be presented to a court as evidence of a PLD-defect — the regulatory violation becomes the defect.

Practical SaaS Update Requirements

Based on the legislative history and Article 7(2) text:

Developer Defenses (Article 11)

The directive enumerates exemptions — you are not liable if you can prove:

Article 11(1)(a): You did not place the product on the EU market or put it into service. (Applies if you only serve non-EU users and a EU user obtained the software without your knowledge.)

Article 11(1)(b): The defect causing the damage did not exist when you placed the product on the market. (You released non-defective code; someone downstream modified it or an external attack introduced the defect.)

Article 11(1)(c): The product was not manufactured for economic purposes. (Relevant for non-commercial open-source, but not for commercial SaaS.)

Article 11(1)(d): The defect is entirely due to compliance with mandatory regulatory requirements. (Your software was required to implement a specific algorithm by law, and that algorithm is defective — rare in practice.)

Article 11(1)(e) — The Development Risk Defense: The state of scientific and technical knowledge at the time of placing on market was not such that the defect could have been discovered.

Critical limitation on Article 11(1)(e): The development risk defense does not apply to "digital products that could be updated or upgraded." This is transformative: for software with update capability — essentially all SaaS — the development risk defense is off the table. You cannot argue "we couldn't have known about this vulnerability" if you had update capability to fix it once discovered.

Open Source and the PLD (Recital 16)

The directive addresses open-source software explicitly in Recital 16:

"Software that is not supplied in the context of a commercial activity, such as free and open-source software, should not be covered by this Directive. However, where an economic operator places such software on the market or puts it into service in a commercial context, that operator should be subject to the rules of this Directive."

What this means:

• Non-commercial open-source developers: Generally not liable under PLD
• Companies using open-source in commercial products: They become the "manufacturer" for PLD purposes — and inherit liability for the open-source components
• Open-source platform companies (Red Hat, HashiCorp model): If you take open-source and sell a commercial version, you're a manufacturer under the directive

The supply chain implication: When you include an npm package, PyPI library, or Docker base image in your commercial SaaS, you may be assuming product liability for defects in that dependency. Your Software Bill of Materials (SBOM) — required under CRA Article 18 — becomes a liability document as well as a compliance artifact.

EU-Sovereign Hosting as a Liability Risk Reduction Strategy

The PLD's liability period (10 years), the security update obligation, and the burden of proof shift all create pressure to minimize defect risk. EU-sovereign cloud infrastructure contributes to this in two ways:

Jurisdictional Clarity

A product liability claim against a US-based SaaS company operating on US infrastructure faces complex jurisdictional questions. Which law applies? Can EU courts obtain evidence? Is there an establishment in the EU?

An EU-incorporated company operating on EU-sovereign infrastructure (no US-parent CLOUD Act exposure, no transatlantic data routing) has a cleaner jurisdictional story. EU courts have direct enforcement mechanisms. Defendants can engage without creating US discovery exposure.

CLOUD Act Exposure as a Contributing Factor

If a claimant alleges that a software defect enabled data exposure — and evidence emerges that your EU user data was routinely accessible to US law enforcement under CLOUD Act orders without notification — this can complicate your "no defect" defense. How can you argue your software protected user data adequately when a parallel access mechanism existed?

EU-sovereign infrastructure eliminates this complication. There is no CLOUD Act order history to discover, no jurisdictional ambiguity about where the data lived.

Security Update Infrastructure

Maintaining a reliable security update pipeline requires controlled infrastructure. If your update distribution depends on third-party CDNs, US-hosted package registries, or cross-border certificate authorities — a jurisdiction-related incident could delay security updates and create Article 7(2) exposure.

EU-native infrastructure for update distribution means you control the update pipeline within EU jurisdiction.

Practical Developer Compliance Checklist

Before December 2026 (Transposition Deadline)

Classify your software:

• Identify all software components you distribute to EU users (SDKs, apps, agents, WebAssembly modules)
• Determine which SaaS features include client-executed code vs. pure server-side processing
• Document any AI/ML systems making automated decisions affecting EU users
• Map IoT or hardware integrations where your software controls physical devices

Review your documentation:

• Does your product documentation clearly describe security capabilities and limitations?
• Are security advisories and update instructions accessible to users?
• Do you have a public vulnerability disclosure policy (required under CRA Article 14 by 2027)?
• Are your SBOM artifacts up to date (required under CRA; also your liability supply chain map)?

Establish your update governance:

• Define your security update SLA — and publish it
• Ensure you have 24/7 incident response capability for critical vulnerabilities
• Document your update testing and release process
• Maintain records of all security-relevant releases for 10+ years

Review your contracts:

• Are your B2B contracts aligned with PLD liability allocation (indemnification clauses)?
• Do your terms of service adequately describe the scope of your software component?
• Do you have product liability insurance appropriate for your revenue and user base?

Audit your supply chain:

• Identify all open-source dependencies in commercial products
• Assess whether any dependency has known unpatched vulnerabilities
• Subscribe to security advisories for all critical dependencies

Key Dates and Timeline

Member states that miss the December 2026 deadline face Commission infringement proceedings. Germany, France, and the Netherlands are expected to transpose early. Nordic states and Baltic members have strong transposition track records.

Intersection with Other EU Regulations

GDPR Article 32

Security failures that expose personal data can trigger both GDPR Article 83 fines and PLD defect claims. A data breach caused by a software defect creates parallel enforcement: the DPA investigates for GDPR compliance, and affected users can sue under PLD for data corruption/loss damages.

NIS2 Article 21

Failure to implement NIS2-required cybersecurity measures can be presented as evidence of a software defect under PLD Article 7(1)(e) (failure to comply with regulatory requirements). A NIS2 enforcement action creates factual findings a private claimant can use in subsequent PLD litigation.

AI Act (Regulation 2024/1689)

Article 4(4)(c) of the PLD directive cross-references the AI Act. High-risk AI systems under AI Act Annex III are subject to heightened PLD scrutiny — defects in these systems carry presumed causation under Article 10(2). If your AI system is classified as high-risk under the AI Act, your PLD exposure is amplified.

CRA (Cyber Resilience Act)

The CRA (entering enforcement in 2027) creates the affirmative security update obligations that Article 7(2) of the PLD presupposes. CRA establishes the what (what updates are "necessary"), PLD creates the liability when those updates are not provided.

Summary: What SaaS Developers Must Do

The EU Product Liability Directive 2024 creates three new realities for software developers serving EU markets:

1. Software is a product. Strict liability applies for defects. No fault-proof needed by claimants.

2. Security update obligations are now liability-generating. Failing to update is as legally risky as shipping defective code initially. The development risk defense is gone for updatable software.

3. The burden of proof can shift to you. In technically complex cases, courts can presume defectiveness once basic contribution to harm is shown — you must disprove it.

With transposition beginning across EU member states by December 9, 2026, the window to audit your software supply chain, establish update governance, and review contractual liability allocation is now.

EU Product Liability Directive 2024 (Directive 2024/2853/EU) — OJ L, 2024/2853, 18.11.2024. See also: CRA Regulation 2024/2847 (enforcement ~2027), EU AI Act Regulation 2024/1689 (effective August 2024, tiered enforcement 2025-2027), NIS2 Directive 2022/2555 (implementation 2024, enforcement ongoing). This guide is for informational purposes only and does not constitute legal advice.