EU Product Liability Directive (2024/2853): what software makers must be able to show — and how to evidence it

Last reviewed 2026-08-21 · 9 min read · mapped against our regulatory mapping v1

From 9 December 2026 the recast Product Liability Directive (EU) 2024/2853 treats software placed on the EU market as a product under strict liability. Courts can order disclosure of how it was built; failing to disclose can create a presumption of defectiveness. A contemporaneous, tamper-evident development record is the documentation that answers such an order.

What it is

For forty years, EU product liability ran on Directive 85/374/EEC — a regime written for tangible goods: a defective toaster, a faulty brake caliper. Software sat in a grey zone. Courts and regulators disagreed on whether code, on its own, was a “product” at all, and claimants often had to fall back on national contract or tort law, which is slower and puts more of the evidentiary burden on the injured party.

Directive (EU) 2024/2853 — the recast Product Liability Directive, often shortened to “PLD” — closes that gap directly. It brings software inside the definition of “product”: standalone or embedded, supplied on a device, via the cloud or as a service, and including AI systems. Digital manufacturing files and digital services that are integral to a product’s operation come along with it. The notion of compensable damage is widened too — destruction or corruption of data now sits alongside death, personal injury and property damage.

The liability is strict: a claimant does not have to prove negligence, only that the product was defective, that damage occurred and that the one caused the other. What makes the directive an engineering matter rather than a legal footnote is how it deals with evidence. It gives national courts a lever to order the manufacturer to disclose “necessary and proportionate” evidence about how the product was built and controlled — and it attaches consequences to not producing it.

One carve-out matters for many of our readers: free and open-source software supplied outside the course of a commercial activity stays outside the directive’s scope. The moment such software is supplied commercially, the ordinary analysis applies.

Who it applies to and when

The directive addresses the economic operators in a product’s supply chain — manufacturers first, and in defined situations importers, authorised representatives, fulfilment service providers and distributors. If you place software on the EU market, or put it into service there, you are in the frame regardless of where your company is based. Whether your particular offering is a “product” in a particular dispute, and which operator is liable for what, is a legal assessment for your counsel — the directive’s allocation of liability between operators is exactly the kind of question a guide like this cannot settle.

The dates are fixed. Member states must transpose the directive into national law, and it applies to products placed on the market or put into service, by 9 December 2026 (Article 22). Products already on the market before that date remain under the 1985 directive, which is repealed with effect from the same day. That transitional split means two regimes will run in parallel for years: one for the software you shipped before December 2026, another for everything after.

Two neighbouring instruments are worth holding in view, because they reach the same development records from different directions: the Cyber Resilience Act (technical documentation duties and reporting clocks) and, for AI-assisted development, the AI Act’s transparency and oversight provisions. Each has its own guide on this site.

What it asks of your development process

The directive does not prescribe a development method. What it does is change what happens after a claim is filed — and that, in turn, changes what your process needs to leave behind.

The claimant formally carries the burden of proving defectiveness, damage and causation. But where a court orders a manufacturer to disclose relevant evidence and the manufacturer does not comply, the product’s defectiveness is presumed (Articles 9-10). The same presumption can apply where the claimant shows an obvious malfunction under normal use, or non-compliance with applicable safety requirements. The manufacturer keeps the right to rebut the presumption — but rebuttal requires exactly the kind of evidence that prompted the disclosure order in the first place.

Translate that into a software delivery process. A court, an insurer or a counterparty’s due-diligence team can ask: show us how this system was built, tested and monitored. A team that cannot produce that record does not get to argue the point — the record’s absence argues against them, by default. The directive’s assessment of defectiveness (Article 7) expressly takes into account the effect of updates and of cybersecurity requirements, which drags the whole change process — what changed, who or what authored it, what was reviewed and tested before release — into scope.

The “development risk” defence sharpens the same point. It lets a manufacturer argue that the defect could not have been discovered given the state of scientific and technical knowledge at the time the product was placed on the market. That defence is inherently time-stamped: it depends on showing what was known, and what was checked, at that moment — not what a team can reconstruct eighteen months after an incident. A retrofitted changelog, a set of recollections in a postmortem or “we’re pretty sure we reviewed that” is not the same evidentiary category as a contemporaneous, tamper-evident record of the development process.

For a codebase with meaningful AI-authored content, the stakes compound: an AI system embedded in, or constituting, a product falls inside the product definition too, and “we don’t know which parts of this were AI-generated or how they were reviewed” is the weakest possible answer to a disclosure order under a strict-liability regime.

So, concretely, the directive asks your process to be able to produce, after the fact and under time pressure:

what each release contained — which changes, authored by whom or by what (human or agent), with which tool and model where an agent was involved;
what was checked before release — the reviews that approved those changes and the tests that ran against them;
when all of that happened — in a form a third party can trust was not written after the dispute began.

What OLOBOLO evidence supports

OLOBOLO records the development process as it happens — spec references, authorship (human or agent), review decisions, test runs and release seals — in an append-only, hash-chained record anchored in time with RFC 3161 timestamps from an independent authority. The table mirrors our regulatory mapping v1, line for line; it uses only three states and nothing in it is a conformity assessment.

Requirement	What you need to show	Chain evidence	Support
Art. 9-10 — disclosure of evidence and rebuttable presumptions of defectiveness	Produce the technical evidence of how the software was developed, reviewed and tested when a court orders disclosure	Chain export (all five event types), release evidence report, review and test evidence per change, RFC 3161 anchors proving the records predate the dispute	Supports
Art. 7 — defectiveness assessment, including the effect of updates and cybersecurity	Show a controlled change process: what changed, who or what authored it, what was reviewed and tested before release	`change.authored` with actor identity (human/agent), `change.reviewed` decisions, `test.evidenced` runs, `release.sealed` segments	Supports
Liable economic operators, insurance and legal structuring (Art. 8 et al.)	Determine who is the manufacturer/importer and how liability is allocated	—	Out of scope

What “Supports” means here: the chain is contemporaneous and append-only — precisely the property that retroactive reconstruction lacks — and an independent verifier can check its integrity without trusting us. It is evidence of process, not a verdict on defectiveness; the question of whether a product was defective, and who answers for it, stays with the court and your counsel.

Evidence, not a legal opinion: this maps what the chain supports as documentation — your counsel decides what liability and compliance require.

How to start

Start recording now, not at the first claim. Evidence under this directive is valuable in proportion to how clearly it predates the dispute. Install the recorder on the repositories that ship to customers and let every change from today land in the chain.
Make review and tests leave evidence. Ensure human approvals and CI runs are recorded as change.reviewed and test.evidenced — the two event types a disclosure order will most want to see next to each change.
Seal releases. A release.sealed segment ties “what release X contained” to the reviews and tests behind it, and the evidence report turns it into something a non-engineer can read.
Keep your counsel in the loop. Share the mapping and this guide; let them decide what your liability position requires. The record is ours to keep honest; the conclusion is theirs to draw.

Evidence can't be reconstructed after the fact — it has to be recorded while you build. Start recording now, free, and every change from this moment is on the record.

Start recording

Frequently asked questions

Does the Product Liability Directive apply to SaaS and cloud-delivered software?

Yes. The recast directive brings software inside the definition of a product regardless of how it is supplied — on a device, via the cloud or as a service — and regardless of whether it is standalone or embedded. Whether a specific offering is caught in a specific case is for your counsel.

When does it start to apply?

Member states must transpose it by 9 December 2026, and it applies to products placed on the market or put into service from that date. Products already on the market before then stay under the 1985 directive.

Is OLOBOLO a way to be 'PLD ready'?

No tool can promise that, and we do not. OLOBOLO records contemporaneous evidence of how each change was authored, reviewed and tested and anchors it in time. That is the kind of documentation a disclosure order asks for; what your liability position is remains a legal question.

Does open-source software fall under the directive?

Free and open-source software supplied outside the course of a commercial activity stays outside the directive's scope. Once it is supplied commercially — for instance as part of a paid product — the usual analysis applies.

Sources

Last reviewed 2026-08-21. Dates are cross-checked against our regulatory mapping and radar.

A necessary honesty: OLOBOLO is evidence, not a legal opinion. This guide describes what our chain supports as documentation — Supports / Partially supports / Out of scope — and your counsel decides what compliance requires. No tool can promise the latter.