How do EU product liability regulations support innovation and what to do to protect against liability risks?

The EU's new Product Liability Directive (PLD), or Directive (EU) 2024/2853), is built for a digital, connected economy. From 9 December 2026, it will apply across the EU on a maximum harmonisation basis. It updates who is liable, what counts as a product and how “defectiveness” is assessed. An artificial intelligence (AI) specific liability law was planned but ultimately withdrawn, due to overlap with the PLD and AI Act, lack of political agreement, and complexity and competitiveness concerns. For now, AI related claims are handled through national rules and the PLD.

Interaction with the current tech legal framework

The PLD does not stand alone. It interlocks with the Product Safety Regulation, the AI Act, the Data Act, the Cyber Resilience Act (CRA) and the General Data Protection Regulation (GDPR). Together, these create a single regulatory envelope for any product with digital components or that processes data. Product safety and conformity obligations shape design and market surveillance. The CRA hard wires baseline cybersecurity and sustained security updates. The AI Act brings risk based governance and documentation for AI features. The Data Act opens access and sharing of connected product data. The GDPR governs personal data from design to decommissioning. These regimes influence each other: weak security can translate into defectiveness under the PLD; wider data access can raise exposure if controls are thin; AI documentation can become evidence in litigation. The strategic takeaway for this is: engineer in safety, cybersecurity, data and AI governance from "day one"  and maintain them throughout the lifecycle.

PLD: 'product' scope and tech challenges 

The PLD significantly broadens what counts as a “product”. It now covers all movables (including those integrated into or interconnected with other goods or immovables), electricity, raw materials, software and digital manufacturing files. Intangibles are in scope: operating systems, firmware, applications and AI systems are products whether embedded, supplied standalone or accessed over a network, including software as a service. The content of digital files can also matter where errors affect safety. Digital manufacturing files—the “recipe” for automated tools or 3D printers—are expressly included, bringing their accuracy, integrity and cybersecurity into the safety equation.

This wider scope requires new reflexes. Defects may stem from code or digital templates not just hardware. Governance over repositories, build pipelines and access control becomes part of product safety by design. Free and open source software (FOSS) remains out of scope when it is non commercial and openly shared, but falls within scope if provided in the course of a commercial activity (including where exchanged for a price or for personal data used for purposes other than exclusively improving security, compatibility or interoperability). Even if the FOSS itself was not commercialised, liability can sit with the manufacturer that integrates it into a product placed on the market. For example, if an open source analytics module in a heart monitor fails and causes patient harm, liability would generally rest with the device manufacturer. 

Beyond the 'factory gate' principle

Liability no longer stops at first placement on the market if the manufacturer retains control. Control exists where the manufacturer provides or directs software updates or upgrades, substantially modifies the product, or keeps the practical ability—directly or via a third party—to deliver updates. General technical assistance or brand recommendations do not, by themselves, amount to control. 

The implication is lifecycle responsibility: monitor field performance, manage vulnerabilities and plan updates to avoid introducing new risks. Where a service is necessary for the product to perform as expected—such as a cloud health monitoring service or a voice assistant—it can be treated as a component for liability purposes. The PLD also recognises destruction or corruption of data as compensable damage, underlining that data integrity is now part of product safety and resilience (back ups, integrity checks, secure updates) is essential. 

Defectiveness: new criteria for digital and connected products

The core test remains whether the product provided the safety the public is entitled to expect. The PLD extends the criteria to fit modern products. If software can learn or acquire new features after market placement (for example, AI enabled behaviour), that adaptive capability is part of the safety assessment. The assumption is that behaviour remains controllable; liability may arise where learning leads to hazardous outcomes that prudent design or governance should have prevented. 

Interconnection matters too: foreseeable interactions with other devices, systems or services can affect safety. Compliance with safety relevant cybersecurity requirements is expressly relevant, reflecting the link between cyber weaknesses and harm. A product is not defective purely because a newer model or update exists; the question is whether it was reasonably safe at the relevant time, judged against these updated factors.

Liabilities along the supply chain

The PLD modernises responsibility so there is always an identifiable EU counterparty. The starting point is the manufacturer of the finished product, with potential joint liability for a component manufacturer if the component caused the defect and that manufacturer retained control (for example, through updates). If the manufacturer is outside the EU, liability can pass to the importer, an authorised representative, or – if neither exists – to a fulfilment service provider performing at least two of warehousing, packaging, addressing or dispatching (excluding postal, parcel delivery and transport services). 

Any operator that substantially modifies a product may be treated as a manufacturer for the resulting defect. If a distributor, when asked, fails within one month to identify the responsible EU operator, the distributor can be held liable. Online platforms are generally outside the PLD as economic operators, but can be treated as “apparent traders” under article 6(3) of the Digital Services Act where their presentation would lead an average consumer to believe the product is provided by the platform or under its control.

Litigation: evidence and defences

To address information asymmetry, once a claimant makes a plausible case, courts can order disclosure of documents and information that are necessary and proportionate. Confidential information and trade secrets remain protected, but non compliance has consequences. Defectiveness may be presumed if ordered evidence is not produced, if mandatory product safety requirements were breached, or if the product obviously malfunctioned during reasonably foreseeable use. Where a product is shown to be defective, courts may presume the causal link if the damage is of a kind typically consistent with that defect. 

Familiar defences remain – such as showing the product was not placed or made available on the market, compliance with applicable legal requirements, or that the state of scientific and technical knowledge did not permit discovery of the defect – but there is no exemption where the product remains under the manufacturer’s control and defectiveness is due to a related service, software (including updates or upgrades), a lack of necessary updates or upgrades, or a substantial modification. In short: strong compliance and contemporaneous documentation are your best defence.

Practical recommendations

• Assign ownership and form a cross functional taskforce (R&D and engineering, product, compliance, procurement, data and privacy, information security, sales and marketing, customer operations).
   
• Map scope and control: inventory products, software (including SaaS), digital files and related services; identify third party components and where you retain post market control (updates, remote features, substantial modifications).
   
• Build secure by design: harden development and digital manufacturing file pipelines; implement integrity checks, back ups and restoration; and align with CRA requirements on risk assessment, vulnerability handling and long term updates.
   
• Govern AI and interconnection: set guardrails for learning features; document intended use and limits; assess foreseeable integrations, and define compatibility and safety requirements.
   
• Contract for accountability: ensure an identifiable EU operator; update supplier and service contracts to allocate update, documentation, cooperation and incident response duties; brief commercial teams to avoid “apparent trader” risks on platforms.
   
• Be evidence ready: maintain clear safety, cybersecurity and AI documentation; track updates and changes; prepare plain language summaries and a disclosure playbook to protect trade secrets while complying with court orders.
   
• Train teams: educate engineers on the expanded “product” scope and FOSS governance; train sales and marketing on statements that shape safety expectations and correct labelling of EU economic operators; prepare customer notices and patch and recall workflows.

Osborne Clarke conclusion

The new PLD modernises liability for a digital, connected economy. It can foster innovation by rewarding safe design, robust cybersecurity and transparent documentation. But it will discourage “move fast, break things” approaches where updates, services or data handling are not engineered for safety and accountability from day one.

With full application in December 2026 and interlocking duties under the AI Act, Data Act, CRA and Product Safety Regulation, now is the time to assess product portfolios, update governance, and close contractual and evidential gaps. 

If you would like to discuss how these changes affect your products, roadmap or liability posture, our Product and Risk experts at Osborne Clarke are here to help