EU Product Liability Directive 2024: Software and Cyber

From 9 December 2026 software sold or supplied in the EU becomes a "product" under a strict liability regime, and a security vulnerability or a missing security update can make it defective. The new Product Liability Directive, Directive (EU) 2024/2853, replaces the 1985 directive and gives anyone who suffers death, injury, property damage or loss of non-professional data a right to compensation without proving fault. It covers software however it is supplied, including software as a service, and treats providers of AI systems as manufacturers. This guide explains who is liable, how cyber security shapes "defectiveness", the timeline, how claims are brought, and what the change means for the credentials, signing keys and AI agents inside software products. It is written for security, product and legal teams at software vendors, SaaS providers and manufacturers of connected devices. The AI-specific angle is covered in the AI Liability and Product Liability Guide.

Status line (checked 27 October 2026): the Directive was adopted on 23 October 2024, published in the Official Journal on 18 November 2024 and entered into force on the twentieth day after publication. Member States must transpose it by 9 December 2026, when the 1985 Directive 85/374/EEC is repealed. It applies only to products placed on the market or put into service after 9 December 2026; older products stay under the old rules. In March 2026 only Germany and the Netherlands had published implementing proposals. It also applies in Northern Ireland under the Windsor Framework; Great Britain has not legislated; the Law Commission of England and Wales opened a consultation on reform on 8 October 2026 (reported).

Key takeaways

Software is a product. Stand-alone software, embedded firmware, apps, SaaS and AI systems are covered, irrespective of how they are supplied, while mere source code and information are not.
Cyber security is part of safety. Courts must consider safety-relevant cybersecurity requirements when judging defectiveness, and a cybersecurity vulnerability can on its own make a product defective.
Updates keep you on the hook. A manufacturer cannot use the "defect arose later" defence for defects caused by software updates or by the lack of security updates needed to maintain safety, while the product is within its control.
Attackers do not reduce liability. Liability is not reduced because a third party, such as an attacker exploiting a vulnerability, contributed to the damage.
Claims get easier. Courts can order disclosure of evidence, presume defectiveness or causation in defined cases, the old EUR 500 property threshold is gone and contracts cannot exclude liability to the injured person.

Scope: who and what is covered

Concept	Meaning under Directive (EU) 2024/2853	Software and cyber implication
Product (Art 4(1))	All movables, including electricity, raw materials, software and digital manufacturing files	Applications, firmware, operating systems, AI systems and SaaS (recital 13)
Related service (Art 4(3))	A digital service integrated into or inter-connected with a product, without which the product cannot perform a function	Cloud back ends of connected devices, companion apps, update services
Component (Art 4(4))	Any tangible or intangible item, raw material or related service integrated into a product	Libraries, SDKs and third-party modules; their makers can be liable
Damage (Art 6)	Death or personal injury, including medically recognised psychological harm; damage to property not used exclusively for professional purposes; destruction or corruption of data not used for professional purposes	Ransomware or wiper damage to consumers' files is in scope; business data losses are not
Free and open-source software (Art 2(2))	Excluded when developed or supplied outside the course of a commercial activity	Supplying for a price or for personal data counts as commercial (recital 14)
Application (Art 2(1))	Products placed on the market or put into service after 9 December 2026	Releases before that date stay under the 1985 regime

Pure economic loss does not by itself trigger liability, and property used for mixed private and professional purposes is now covered; only property used exclusively for professional purposes is excluded. An injured person's own fault, such as failing to install an offered update, can reduce compensation (Art 13(2)).

Who can be liable

Manufacturer: the developer or producer of the product, including the provider of an AI system (Art 8(1)(a), recital 13).
Component manufacturer: the maker of a defective component, including software or a related service, integrated under the manufacturer's control (Art 8(1)(b)).
Non-EU manufacturers: the importer, the authorised representative and, where neither exists in the EU, the fulfilment service provider (Art 8(1)(c)).
Substantial modifier: anyone who substantially modifies a product outside the manufacturer's control and then makes it available is treated as a manufacturer (Art 8(2)). For AI systems, a substantial modification through continuous learning is treated as making the product available at that point (recital 40).
Distributors and online platforms: liable if they fail, within one month of a request, to identify an EU-based operator, and platforms are covered under the same conditions where Digital Services Act Article 6(3) applies (Art 8(3) and 8(4)).
Open-source developers: where a manufacturer integrates non-commercial open-source software into a commercial product, the manufacturer can be liable for its defects, but the original developer generally is not (recital 15).

Key obligations

The Directive does not impose compliance duties in the way NIS2 or the Cyber Resilience Act do. It sets the conditions under which a producer must pay compensation. In practice, those conditions translate into engineering and lifecycle obligations, because they define what will be judged defective.

What makes software defective

A product is defective if it does not provide the safety a person is entitled to expect or that EU or national law requires (Art 7(1)). The factors a court must consider include:

Article 7(2) factor	What it means for software	Engineering response
(c) Ability to continue to learn or acquire new features after placement	Behaviour of AI components and feature updates counts	Change control and safety testing for model and feature updates
(f) Relevant product safety requirements, including safety-relevant cybersecurity requirements	Failing applicable cyber requirements is evidence of defect	Map to applicable product security law, such as the Cyber Resilience Act
(g) Recalls or other relevant interventions by authorities or operators	Security advisories and forced patches may be cited	Keep records of why and how each intervention was made
Art 7(3) carve-out	Not defective merely because a better product or an update later exists	Document the security state of the art at release

Recital 32 states that a product can be defective on account of its cybersecurity vulnerability. Recital 51 adds that manufacturers are not exempt where a defect results from failing to supply software security updates or upgrades needed to address vulnerabilities, although the Directive itself does not require updates to be provided. The obligation to patch comes from other laws; the PLD supplies the financial consequence.

The control test

Article 11(2) removes the "defect did not exist at placement" defence where the defect is due to a related service, software including updates or upgrades, the lack of updates necessary to maintain safety, or a substantial modification, provided these are within the manufacturer's control. Recital 19 explains that a product remains within the manufacturer's control while it can still supply software updates, itself or through a third party. Practically, as long as you operate an update channel, you carry the risk of not using it.

Evidence, presumptions and defences

Provision	Effect	Preparation
Art 9 disclosure	A claimant who shows a plausible claim can obtain disclosure of relevant evidence; trade secrets can be protected	Retain security testing, vulnerability handling and update records in disclosable form
Art 10(2) presumption of defect	Presumed if the defendant fails to disclose, the product breaches mandatory safety requirements, or there is an obvious malfunction in foreseeable use	Ability to show compliance with mandatory cyber requirements
Art 10(4) complexity presumption	Defect or causation presumed where technical complexity makes proof excessively difficult and the claimant shows likelihood	Explainability of AI and security design decisions
Art 11(1)(e) state of the art defence	No liability if science could not discover the defect at the time; Member States may derogate (Art 18)	Evidence of contemporary threat modelling and testing
Art 13 third parties	Liability not reduced by a third party's act, such as exploitation of a vulnerability	Do not rely on "the attacker caused it"
Art 15 no exclusion	Liability cannot be limited or excluded by contract against the injured person	Licence disclaimers do not help against claimants

Timeline and current status

Date	Event
23 October 2024	Directive (EU) 2024/2853 adopted
18 November 2024	Published in the Official Journal; in force on the twentieth day after publication
March 2026	Only Germany and the Netherlands have published national implementing proposals (reported)
9 December 2026	Transposition deadline; Directive 85/374/EEC repealed; new rules apply to products placed on the market or put into service after this date, including in Northern Ireland
9 December 2026	Deadline to notify existing national derogations from the state of the art defence
9 December 2030	First Commission evaluation, then every five years

Two points catch teams out. First, "placed on the market" for continuously updated software and SaaS is not a single date, and a substantial modification restarts the clock for that product (Art 17(1)). Second, the 1985 regime continues for older products, so for some years two regimes run in parallel across a product line.

Enforcement and penalties

There are no regulator fines in the PLD. It is a civil liability regime enforced by injured persons in national courts, and the exposure is uncapped compensation.

No-fault liability: the claimant proves defect, damage and causation, not negligence (Art 10(1)).
Joint and several liability: where several operators are liable for the same damage, each can be pursued for the whole, with recourse between them (Arts 12 and 14). A manufacturer that integrates software from a micro or small enterprise cannot claim recourse if it contractually waived it (Art 12(2)).
No minimum or caps: the old EUR 500 property damage threshold has been removed and Member States can no longer set financial ceilings on liability, which makes small and representative claims viable.
Limitation and expiry: three years from when the claimant knew or should have known of the damage, defect and liable operator (Art 16); rights expire 10 years after placement or substantial modification, or 25 years for latent personal injury (Art 17).
Transparency: Member States must publish appellate and final judgments under the Directive and the Commission will keep a public database (Art 19), so precedents on software defects will become visible.

What it means for AI agents and non-human identities

Credentials and machine identities embedded in a product are part of its security, and several of the most common vulnerability classes are identity failures. The points below are practical interpretation, not text from the Directive.

NHI issue in a product	Why it matters under the PLD	Control
Hard-coded or default credentials in devices and apps	A well-known vulnerability class that a court may treat as below expected safety	Unique per-device credentials, no shared secrets in firmware
Update signing keys	Theft lets an attacker ship malicious updates through your channel, and you remain in control of that channel	Keys in HSMs, separation of duties, signed and verified updates
API keys and tokens in the related service	The cloud back end is a related service; its compromise can disable or misuse the product	Short-lived tokens, secret scanning, rotation
AI agents acting through product APIs	Providers of AI systems are manufacturers; agents that change behaviour through learning raise substantial modification questions	Scoped agent identities, action logging, change control for models
Machine identity logs	Article 9 disclosure and presumptions reward the side that can show what happened	Retain authentication and update logs for the product's support life

The Salesloft Drift breach, where OAuth tokens stored in a vendor's cloud environment were stolen and used to export data from the Salesforce instances of hundreds of customers, shows how a vendor's machine credentials become a product-level failure for every customer at once. See the Secrets Management Guide and the Machine Identity, PKI and Certificate Lifecycle Guide.

Compliance steps

Inventory products in scope. List software, firmware, SaaS and AI systems that will be placed on the EU or Northern Ireland market after 9 December 2026, and identify related services and third-party components.
Define the support period. Decide and publish how long each product will receive security updates. While you can supply updates the product remains within your control.
Align with product security law. Map products to applicable safety-relevant cybersecurity requirements, especially the Cyber Resilience Act. See the EU Cyber Resilience Act Guide.
Industrialise vulnerability handling. Run coordinated disclosure, triage against safety impact and timely patch delivery, with records of each decision. See the ISO/IEC 29147 and 30111 Vulnerability Disclosure and Handling Guide.
Secure the update chain. Protect signing keys, build systems and update servers as crown jewels, and remove embedded default credentials.
Know your components. Maintain SBOMs and supplier contracts that cover vulnerability notification and recourse. See the SBOM Guide.
Prepare for disclosure. Keep design decisions, threat models, test results and update histories so they can be produced under Article 9 without exposing more than necessary.
Review contracts and insurance. Recognise that licence disclaimers do not limit liability to injured persons, revisit recourse clauses with suppliers, and check product liability cover for software.

Framework mapping

PLD pressure point	NIST CSF 2.0	NIST SP 800-53 Rev 5	ISO/IEC 27001:2022 Annex A
Vulnerabilities as defects	ID.RA-01	RA-5, SI-2	A.8.8
Security updates within control	PR.PS-02	SI-2, SA-22	A.8.8, A.8.32
Components and suppliers	GV.SC-05, GV.SC-07	SR-3, SA-9	A.5.19, A.5.21
Embedded credentials and signing keys	PR.AA-01	IA-5, SC-12	A.5.17, A.8.24
Secure development	PR.PS-06	SA-8, SA-11	A.8.25, A.8.28
Evidence for disclosure	DE.AE-03	AU-11	A.8.15

Common failure patterns

Assuming SaaS is a service, not a product: recital 13 brings software as a service into scope whatever the delivery model.
Relying on licence disclaimers: Article 15 prevents excluding or limiting liability to the injured person.
Undefined end of support: without a clear support period the argument that a product was still within your control, and should have been patched, gets stronger.
Blaming the attacker: Article 13 and recital 55 mean third-party exploitation does not reduce liability.
No evidence trail: missing records of testing and patch decisions make presumptions under Article 10 harder to rebut.
Ignoring components: an integrated SDK or library can make the whole product defective, and joint liability means you may pay first.

Practitioner checklist

List products and related services placed on the market after 9 December 2026.
Publish a security update support period for each product.
Map each product to applicable cybersecurity requirements.
Run documented vulnerability handling with safety-based triage.
Protect update signing keys and remove default credentials.
Maintain SBOMs and supplier recourse terms.
Retain design, testing and update evidence for disclosure.
Treat AI model updates as possible substantial modifications.
Review product liability insurance and contracts.

Standards and references

Related NHI Mgmt Group resources: AI Liability and Product Liability Guide · EU Cyber Resilience Act Guide · Software Liability and Secure by Design Policy Guide · Patch Management Guide. This guide summarises the EU Product Liability Directive (EU) 2024/2853 as at 27 October 2026 and is not legal advice.

EU Product Liability Directive 2024 Guide: Software, Security Updates and No-Fault Liability