A Missing Security Update Is Now a Defect: Engineering Evidence Against PLD Liability

For four decades, a product was judged by the state it was in on the day it left the factory. The revised Product Liability Directive breaks that assumption for software, and the break runs straight through your patch cadence.

Most commentary on Directive (EU) 2024/2853 treats it as a lawyer’s problem: a strict-liability regime transposed into national law and argued over in court years later. That framing misses where the work lands. The directive changes what makes a product defective, and for software the answer now depends on what your engineering function does or fails to do after release. That makes it a technology-governance problem with a legal consequence, not the other way round. Member States must transpose by 9 December 2026, so the question is not whether this applies to you but whether you can evidence the answer.

Defectiveness is now a moving target

The old directive was built for physical goods. Software was a grey area, argued into or out of scope case by case. The revised directive removes the ambiguity: software is a product, and so is the digital service integrated into one. That much has been widely reported. What matters more is how the directive tells a court to decide whether that product is defective.

Article 7 sets out the circumstances a court weighs when assessing defectiveness. Two of them are new and pointed at software specifically. One is the effect of any ability the product has to continue to learn or acquire features after it is placed on the market. The other is compliance with relevant product safety requirements, expressly including safety-relevant cybersecurity requirements. Read together, they mean a product is not judged solely as shipped. It is judged against what it does, and what was expected of it, across its supported life. A product that was secure on release and is left unpatched against a known, exploited vulnerability can be found defective on the day the harm occurs, not the day it shipped.

The directive is careful about the other direction. Article 7 also states that a product is not defective for the sole reason that a better one, including an update or upgrade, is later placed on the market. Shipping an improvement does not retroactively condemn the previous version. The liability attaches to the absence of an update that safety required, not to the existence of a newer one.

The defence you no longer have

The instinctive engineering defence to a post-release defect claim is chronological: the product was sound when it left our control, and whatever went wrong happened afterwards. Article 11 preserves a version of that defence. A manufacturer can escape liability by proving the defect did not exist when the product was placed on the market, or came into being later.

Then it takes the defence away for exactly the situations that matter here. That later-defect exemption does not apply where the defectiveness is due to a related service, to software including updates or upgrades, to the lack of a software update or upgrade necessary to maintain safety, or to a substantial modification, where those remain within the manufacturer’s control. In plain terms: if the product is still within its support period and you retain control over the update mechanism, “it was fine when we shipped it” is not available to you. The support period is not a marketing promise. It is the window in which the directive holds you responsible for keeping the product safe, and the boundary of that window becomes a fact you will have to prove.

The presumptions move the work onto you

Even a well-founded defence loses if the procedural ground has shifted, and it has. Article 9 lets a claimant who has presented a plausible claim compel disclosure of relevant evidence. Article 10 then builds in rebuttable presumptions that tilt the burden. Defectiveness is presumed where the defendant fails to disclose the evidence it was ordered to produce, where the product does not comply with mandatory safety requirements, or where the damage resulted from an obvious malfunction in reasonably foreseeable use. There is a further presumption available where a claimant faces excessive difficulty, in particular because of technical or scientific complexity, in proving defectiveness or causation.

Each presumption is rebuttable. You keep the right to answer it. But notice what rebutting requires. To disclose relevant evidence, you must have kept it. To show the product met safety and cybersecurity requirements, you must reconstruct what it did and when. To defeat the complexity presumption, you must make the technical story legible. Every one of those is an evidence problem before it is a legal one, and it is the same discipline regulated firms are already building for supervisory regimes elsewhere. The evidence trail under the NYDFS Part 500 model, where reporting duties turn on contemporaneous records, is the same muscle a PLD defence draws on.

What a defect claim actually turns on

Strip away the legal architecture and a software-defect defence rests on a small set of records you either have or do not. In practice they are:

• A patch-cadence record. When each vulnerability was identified, triaged, fixed and released, tied to a severity assessment. This is what shows an update that safety required was in fact supplied, and supplied in reasonable time.
• Security advisories and their delivery. Not just that a fix existed, but that it was communicated to the affected users and that the update channel functioned. An unpatched estate is a weaker position when you can show the patch was available and pushed.
• Support-period documentation. Clear, dated statements of what was supported, for how long, and when support ended for a given version. This is the boundary that determines whether the Article 11 exemption is open to you at all.
• Version and deployment logging. Which build ran where, at what time. Without it you cannot answer the causation question the directive now presumes against you.
• An asset and dependency inventory. You cannot evidence that a component was maintained if you cannot say it was in the product. The same inventory discipline supervisors already demand is the foundation of a defect defence.

None of this is novel security engineering. What is novel is the purpose. These are no longer operational logs kept for convenience and rotated out when storage gets tight. They are the exhibits in a liability claim, and they need to survive as long as the liability does.

Retain it as evidence, not as exhaust

The timescales are the part most engineering functions have not internalised. A claim can be brought up to three years from when the injured party became aware of the damage, the defect and the responsible operator. Sitting behind that is a long-stop: liability generally expires ten years after the product was placed on the market, extended to twenty-five years where a personal injury was latent and not reasonably discoverable sooner. Substantially modify the product and, in effect, the clock can start again for the modified version.

Set your log-retention policy against a two-week incident window and you will have destroyed your own defence years before a claim lands. The records that prove a product was maintained to a reasonable standard have to be retained on the directive’s timescale, not the SIEM’s default. That is a deliberate architectural decision about what you keep, in what immutable form, and for how long, best taken now rather than reconstructed under disclosure. It is the same governance question raised by treating software as a product under the revised directive, seen from the evidence side.

The uncomfortable truth for anyone who ships software into the EU is that your patch history has become a legal record whether or not you manage it as one. The only choice you have is whether it reads, years from now, as a deliberate account of a product kept safe, or as gaps you cannot explain.