The EU Product Liability Directive Makes Software a Product on 9 December 2026: What Engineering Teams Need to Know

From 9 December 2026, software sold or supplied in the EU is a "product" for strict liability. If a defect in it, including a security vulnerability, causes injury, damages someone's property or destroys their data, the injured person can claim compensation from the software's maker without proving fault. That's the effect of the new EU Product Liability Directive, (EU) 2024/2853, which replaces the 1985 directive on that date. Member States have to transpose it into national law by the same day.

This post is for engineering and security leads at companies that ship software into the EU, whether as apps, firmware, SaaS or components inside someone else's product. It covers what the Directive says about software, where open source sits, why the "it was fine when we shipped it" defence mostly disappears, what changes in court, and the records worth keeping from now on. It quotes the Directive's text and isn't legal advice. Your counsel and your national implementing law have the final word.

The short answer

Directive (EU) 2024/2853 applies to products placed on the market or put into service after 9 December 2026 (Article 2(1)), and its definition of product explicitly includes software (Article 4(1)). Recital 13 says this holds "irrespective of the mode of its supply or usage", which covers software on a device, in the cloud, or supplied as a service. The maker of the software is a manufacturer. If the software is a component of someone else's product, both can be liable, jointly and severally (Articles 8 and 12). Free and open-source software developed or supplied outside a commercial activity is excluded (Article 2(2)). Liability can't be limited by contract (Article 15) and lasts up to 10 years from when the product was placed on the market (Article 17).

What counts as a product, and what doesn't

Article 4(1) defines a product as "all movables", and adds that it "includes electricity, digital manufacturing files, raw materials and software". Recital 13 lists operating systems, firmware, computer programs, applications and AI systems as examples.

Two further definitions widen the net:

• Related services (Article 4(3)) are digital services integrated with or connected to a product so that "its absence would prevent the product from performing one or more of its functions". The recitals give a navigation system's traffic feed and a voice assistant that controls devices as examples. They count as components. Internet access doesn't (recital 17).
• Components (Article 4(4)) include any tangible or intangible item integrated into or connected to a product, which covers libraries and SDKs that your product ships.

What isn't a product: information as such, including "the content of digital files" and "the mere source code of software" (recital 13). Publishing code isn't putting a product on the market. Executable software that someone supplies is.

Open source: excluded until someone sells it

Article 2(2) says the Directive "does not apply to free and open-source software that is developed or supplied outside the course of a commercial activity". Recital 14 adds that developing, contributing to or publishing such software on open repositories isn't making it available on the market. Supply by non-profit organisations is, in principle, not treated as commercial. The exclusion ends when software is supplied "in exchange for a price, or for personal data used other than exclusively for improving the security, compatibility or interoperability of the software".

Recital 15 then puts the liability with whoever commercialises it. A company that integrates non-commercial open source into a product it sells can be held liable for damage caused by a defect in that open source. The upstream maintainer can't. In practice, the open-source components in your product are your liability, the same as code you wrote.

Security vulnerabilities are defects

A product is defective when "it does not provide the safety that a person is entitled to expect or that is required under Union or national law" (Article 7(1)). The factors a court weighs include "relevant product safety requirements, including safety-relevant cybersecurity requirements" (Article 7(2)(f)) and the moment the product left the manufacturer's control (Article 7(2)(e)). Recital 32 says plainly that a product "can also be found to be defective on account of its cybersecurity vulnerability".

Two articles make this sharper for security teams:

• Attackers don't share the blame. Article 13(1) says liability is "not reduced or disallowed" when the damage is caused both by the defect and by a third party's act. Recital 55 gives the example of "a third party exploiting a cybersecurity vulnerability". A user's own fault can reduce it, for example negligently not installing an update you supplied (Article 13(2), recital 55).
• Shipping an update isn't an admission. A product isn't defective just because a better version or an update exists (Article 7(3)).

The Directive doesn't name the Cyber Resilience Act. But under Article 10(2)(b), defectiveness is presumed when a product breaks "mandatory product safety requirements" that protect against the damage suffered. How courts will treat non-compliance with the CRA's security requirements under that rule hasn't been tested yet. It's a reasonable thing to discuss with counsel now.

Updates keep you on the hook

Under the old directive, a manufacturer could escape liability by showing the defect didn't exist when the product left its hands. Article 11(1)(c) keeps that defence, but Article 11(2) switches it off for anything "within the manufacturer's control":

• a related service,
• software, including software updates or upgrades,
• "a lack of software updates or upgrades necessary to maintain safety", and
• a substantial modification.

"Manufacturer's control" includes simply having "the ability to supply software updates or upgrades, themselves or via a third party" (Article 4(5)(b)). For connected software, that's nearly always true. So the clock that matters is no longer the shipping date. It's the period in which you could have shipped a fix.

Recital 51 is careful here. The Directive "does not impose any obligation to provide updates". But if a vulnerability that a security update would have fixed causes damage while the product is still under your control, the "it arose later" defence isn't available. That makes your security-update policy, and the end-of-support dates you announce, part of your liability position.

Substantial modifications matter too. A product substantially modified after it was placed on the market is treated as a new product (recital 39), including when the change comes through a software update (recital 40), and the 10-year expiry period restarts (Article 17(1)(b)). On our reading, a major update to a product first sold before December 2026 could bring it under the new Directive. Ask your counsel how your national law treats this.

What changes in court: evidence and presumptions

The claimant still has to prove defect, damage and causation (Article 10(1)). But two things change the balance for complex software.

Disclosure. If a claimant shows their claim is plausible, a court can order the defendant to disclose relevant evidence, with protection for trade secrets (Article 9). It can also require that evidence to be presented "in an easily accessible and easily understandable manner" (Article 9(6)).

Presumptions. Defectiveness is presumed if the defendant doesn't disclose, if the product breaks mandatory safety requirements, or if there's an "obvious malfunction" (Article 10(2)). Where technical complexity makes proof excessively difficult, a court must presume defect or causation, or both, once the claimant shows they are likely (Article 10(4)). Recital 48 names machine learning and "the inner workings of an AI system" as examples of complexity. The defendant can rebut every presumption (Article 10(5)).

The practical consequence: if you can't produce records of what was in a release, which vulnerabilities you knew about and when you fixed them, that gap can work against you.

Who can claim, and for what

Only natural persons can claim (Articles 1 and 5). The compensable damage is limited to three kinds (Article 6(1)):

• death or personal injury, including medically recognised psychological harm,
• damage to property, except the defective product itself and property "used exclusively for professional purposes", and
• "destruction or corruption of data that are not used for professional purposes".

Data loss is new. Recital 20 says compensation includes the cost of recovering or restoring data, separates it from data breaches (which stay under GDPR), and says there's no loss if a free backup exists. Pure economic loss and privacy infringements don't trigger liability on their own (recital 24).

So exposure depends heavily on who your users are. Consumer apps, connected devices and anything that stores people's personal files sit squarely in scope. Software used only by businesses on professional data is mostly outside the damage categories, though mixed-use property is covered (recital 25), and a business customer's employees are natural persons who can be injured.

Two small-company provisions are worth knowing. Micro and small software makers can agree contractually that the product maker integrating their component won't seek recourse from them (Article 12(2)). Neither can contract out of liability to the injured person (Article 15).

Scope your products in five minutes

This script encodes the articles above as a first-pass check, so engineering and legal can start from the same facts. Edit the PRODUCTS list to describe your own products and run it.

#!/usr/bin/env python3
"""First-pass scoping of a software product under the EU Product Liability Directive
(EU) 2024/2853. Not legal advice: it encodes the Directive's articles so engineering
and legal can start from the same facts. Edit PRODUCTS and run."""
from datetime import date

CUTOVER = date(2026, 12, 9)   # Art 2(1), Art 21

PRODUCTS = [
    dict(name="Consumer mobile app (paid)", first_placed=date(2027, 3, 1), commercial=True,
         oss_noncommercial=False, users_natural_persons=True, touches_personal_data_or_devices=True,
         can_push_updates=True, substantial_update_after_cutover=False),
    dict(name="B2B SaaS, business data only", first_placed=date(2025, 6, 1), commercial=True,
         oss_noncommercial=False, users_natural_persons=False, touches_personal_data_or_devices=False,
         can_push_updates=True, substantial_update_after_cutover=True),
    dict(name="Hobby OSS library on GitHub", first_placed=date(2027, 1, 10), commercial=False,
         oss_noncommercial=True, users_natural_persons=True, touches_personal_data_or_devices=True,
         can_push_updates=True, substantial_update_after_cutover=False),
    dict(name="Smart-home firmware, sold 2025", first_placed=date(2025, 9, 1), commercial=True,
         oss_noncommercial=False, users_natural_persons=True, touches_personal_data_or_devices=True,
         can_push_updates=True, substantial_update_after_cutover=True),
]

def assess(p):
    notes = []
    if p["oss_noncommercial"] and not p["commercial"]:
        return ["Out of scope: free and open-source software outside a commercial activity (Art 2(2)). "
                "A company that ships it inside a commercial product is liable for it instead (recital 15)."]
    new_regime = p["first_placed"] > CUTOVER or p["substantial_update_after_cutover"]
    if not new_regime:
        return ["Old regime: placed on the market before 9 Dec 2026, so Directive 85/374/EEC still applies (Art 21)."]
    if p["first_placed"] > CUTOVER:
        notes.append("New Directive applies: placed on the market after 9 Dec 2026. Software is a product (Art 4(1)).")
    else:
        notes.append("Probably the new Directive: a substantial modification after 9 Dec 2026 makes it a new "
                     "product (recitals 39 and 40, Art 17(1)(b)). Our reading, untested in court.")
    if p["users_natural_persons"] and p["touches_personal_data_or_devices"]:
        notes.append("Exposure: injury, damage to non-professional property, and destruction or corruption "
                     "of non-professional data are compensable (Art 6(1)).")
    else:
        notes.append("Lower exposure: only natural persons can claim, and data or property used exclusively "
                     "for professional purposes is excluded (Art 6(1)(b)(iii), (c)). Check for mixed use.")
    if p["can_push_updates"]:
        notes.append("Within your control: no 'defect arose later' defence for software, updates, or missing "
                     "security updates needed to keep it safe (Art 4(5)(b), Art 11(2)).")
    notes.append("A third party exploiting a vulnerability does not reduce your liability (Art 13(1)); "
                 "contract terms cannot cap it (Art 15).")
    notes.append("Expiry: 10 years from placing or substantial modification (Art 17); keep evidence that long (Art 9, 10).")
    return notes

for p in PRODUCTS:
    print(p["name"])
    for n in assess(p):
        print("  - " + n)

Consumer mobile app (paid)
  - New Directive applies: placed on the market after 9 Dec 2026. Software is a product (Art 4(1)).
  - Exposure: injury, damage to non-professional property, and destruction or corruption of non-professional data are compensable (Art 6(1)).
  - Within your control: no 'defect arose later' defence for software, updates, or missing security updates needed to keep it safe (Art 4(5)(b), Art 11(2)).
  - A third party exploiting a vulnerability does not reduce your liability (Art 13(1)); contract terms cannot cap it (Art 15).
  - Expiry: 10 years from placing or substantial modification (Art 17); keep evidence that long (Art 9, 10).
B2B SaaS, business data only
  - Probably the new Directive: a substantial modification after 9 Dec 2026 makes it a new product (recitals 39 and 40, Art 17(1)(b)). Our reading, untested in court.
  - Lower exposure: only natural persons can claim, and data or property used exclusively for professional purposes is excluded (Art 6(1)(b)(iii), (c)). Check for mixed use.
  - Within your control: no 'defect arose later' defence for software, updates, or missing security updates needed to keep it safe (Art 4(5)(b), Art 11(2)).
  - A third party exploiting a vulnerability does not reduce your liability (Art 13(1)); contract terms cannot cap it (Art 15).
  - Expiry: 10 years from placing or substantial modification (Art 17); keep evidence that long (Art 9, 10).
Hobby OSS library on GitHub
  - Out of scope: free and open-source software outside a commercial activity (Art 2(2)). A company that ships it inside a commercial product is liable for it instead (recital 15).
Smart-home firmware, sold 2025
  - Probably the new Directive: a substantial modification after 9 Dec 2026 makes it a new product (recitals 39 and 40, Art 17(1)(b)). Our reading, untested in court.
  - Exposure: injury, damage to non-professional property, and destruction or corruption of non-professional data are compensable (Art 6(1)).
  - Within your control: no 'defect arose later' defence for software, updates, or missing security updates needed to keep it safe (Art 4(5)(b), Art 11(2)).
  - A third party exploiting a vulnerability does not reduce your liability (Art 13(1)); contract terms cannot cap it (Art 15).
  - Expiry: 10 years from placing or substantial modification (Art 17); keep evidence that long (Art 9, 10).

It won't replace legal review, especially for the substantial-modification question and for mixed professional and personal use. But it gets the right questions onto the table quickly.

What to put in place before 9 December

1. Inventory what you place on the EU market, including firmware, apps, SaaS features that devices depend on, and the components each one ships. The open source inside is your liability.
2. Write down your support and security-update commitments per product, and keep them consistent with what you can deliver. Article 11(2) ties your defence to what was within your control.
3. Keep per-release evidence for at least ten years: what was in each release, which vulnerabilities were known and when, and when fixes shipped and were offered to users. A software bill of materials per release, with its vulnerability history, is the obvious backbone. That's the kind of record Safeguard SCA keeps for each project.
4. Make updates easy and record their delivery. A user who negligently ignores an update can have their claim reduced (Article 13(2)), but only if you can show the update existed and was offered.
5. Review contracts with component suppliers and customers. Recourse terms between businesses still matter (Articles 12 and 14). Liability caps toward injured people don't.
6. Read this alongside the CRA. If you're already preparing for the CRA's vulnerability reporting duties, much of the same evidence serves both.

The fair counter-argument

None of this means every bug becomes a lawsuit. Claimants must still show damage of a covered kind, and most software defects cause inconvenience or business loss, which the Directive doesn't compensate. The development-risk defence remains: if the state of scientific and technical knowledge couldn't reveal the defect while the product was in your control, you aren't liable (Article 11(1)(e)), although Member States may restrict that defence (Article 18). And the evidence rules cut both ways, since defendants can request disclosure too (Article 9(2)).

What does change is the default. Software is now treated like any other product, a vulnerability is a possible defect, and the period of responsibility runs as long as you can ship an update. For companies that already keep good release and vulnerability records, that mostly turns existing hygiene into evidence. For companies that don't, December is close.