Product liability for software from 9 December 2026: why the missing update creates liability and the shipping state no longer protects you

On 9 December 2026 software becomes a product. That sentence now appears in every guide, and it is correct: Article 4(1) of Directive (EU) 2024/2853 lists software expressly among the things for which liability arises without fault. What is missing from most accounts sits seven articles further on. There, the defence that has ended almost every software liability argument so far is switched off for one specific case. The case is the missing security update.

This article follows both halves of the picture: the place where the new regime reaches considerably further than it looks, and the place where it is far narrower than the tone of the coverage suggests. For a mid-market company that makes software, or has software made, the combination of the two decides whether anything happens at all on 9 December.

What actually changes on 9 December 2026

Two provisions carry the date. Article 22 obliges Member States to bring the necessary rules into force by 9 December 2026. Article 2(1) says which products they then govern: the directive applies to products placed on the market or put into service after 9 December 2026. Anything placed on the market before that stays with the previous regime under Directive 85/374/EEC. The cut-off attaches to the individual product, not to the company, and that distinction is the single most useful thing to take from the whole reform.

The fourth row is the one worth stopping at. Nothing in the previous regime gave a claimant a route from an update that was never delivered to a manufacturer’s liability. The new directive builds that route deliberately, and it does so in a place most summaries skip, because it is drafted as an exception to an exception.

The defence that was switched off

Article 11(1) lists the grounds on which an economic operator escapes liability. Point (c) is the one that has done the work in practice: the operator is not liable if it proves that it is probable that the defectiveness which caused the damage did not exist at the time the product was placed on the market or put into service, or that the defectiveness came into being after that point. For software this defence has been close to unbeatable. A vulnerability discovered three years after release was, almost by definition, not a defect at delivery.

Article 11(2) removes exactly that. By way of derogation from paragraph 1(c), an operator is not exempted from liability where the defectiveness of a product is due to a related service, to software including updates or upgrades, to a lack of software updates or upgrades necessary to maintain safety, or to a substantial modification of the product, provided that this is within the manufacturer’s control. Four cases, and the third is the one nobody plans for.

The provision only bites if the manufacturer had control, so the definition of control decides how much of it survives contact with reality. Article 4(5) answers that in two limbs. Under (a), control exists where the manufacturer performs, authorises or consents to the integration or supply of a component including updates, or to a modification of the product. Under (b), control exists where the manufacturer has the ability to supply software updates or upgrades, itself or via a third party. Not the exercise of control. The ability.

Read those two provisions together and the consequence is uncomfortable but plain. The liability window does not close when the product ships. It closes when you can no longer supply an update, and for a product with an update mechanism that point arguably never arrives while the mechanism exists. A company that leaves a known vulnerability unpatched because the customer is small, the release train is full or the version is old is no longer merely making a support decision. It is making a liability decision, and Article 11(2)(c) is the provision that will be quoted back at it.

Where the liability does not reach at all

So far this reads like a reason to worry, and much of the German coverage stops there. It should not, because the same directive draws a boundary that is far more restrictive than the alarm suggests, and it draws it in two sentences.

Article 5(1) requires Member States to ensure that any natural person who suffers damage caused by a defective product is entitled to compensation. A company is not a natural person. Under this directive a company can claim nothing: not less, nothing. And Article 6(1) lists the recoverable heads of damage exhaustively, in the words the right applies in respect of only the following types of damage: death or personal injury including medically recognised damage to psychological health; damage to or destruction of property, except the defective product itself, a product damaged by a defective component within that manufacturer’s control, and property used exclusively for professional purposes; and destruction or corruption of data that are not used for professional purposes.

For a genuine business-to-business software vendor most of that table reads as relief, and the relief is real. It is also narrower than it looks, in three ways that are worth naming individually.

The three routes that reach a B2B supplier anyway

The first is personal injury, and it swallows the professional carve-out whole. The exclusion in Article 6(1)(b)(iii) covers property. It does not touch Article 6(1)(a). If your control software can cause a machine to move when it should not, the fact that the machine, the hall and the employment relationship are all commercial changes nothing about the claim of the person who was standing next to it.

The second is Article 8(1)(b), and it is the provision a component supplier should read before any other. Liable is the manufacturer of a defective component, where that component was integrated into or inter-connected with a product within the manufacturer’s control and caused that product to be defective, without prejudice to the liability of the manufacturer of the finished product. A library, a control module or a firmware image that you supply into someone else’s device makes you an economic operator in your own right, alongside your customer. Your own sales channel may be strictly B2B while the product your component ends up in sits on a consumer shelf, and it is that end product that determines who can sue.

There is a defence built for exactly this position. Under Article 11(1)(f) the component manufacturer escapes liability by proving that the defectiveness of the product into which the component was integrated is attributable to the design of that product or to the instructions given by its manufacturer. That defence is won or lost on paper: on a written specification, a documented intended use, and a record of what you were told the component would do. Companies that ship a module against a phone call and a purchase order have no way to run it.

The third route is a single adverb. Article 6(1)(b)(iii) excludes property used exclusively for professional purposes, and Article 6(1)(c) protects data that are not used for professional purposes. A phone, a laptop or a vehicle that is also used privately does not satisfy exclusively, and in a mid-market company that describes a large share of the hardware in the field. The same technique appeared in the AI Act: one adverb decides who is inside a provision and who is outside it, and it is rarely the adverb people read twice.

Why the Cyber Resilience Act suddenly has a price tag

Article 10(1) leaves the burden of proof where it has always been: the claimant proves defectiveness, damage and the causal link. Article 10(2) then lists three situations in which defectiveness is presumed. Point (a) covers a defendant who fails to disclose relevant evidence under Article 9(1). Point (c) covers an obvious malfunction during reasonably foreseeable use. Point (b) is the one that connects this directive to the rest of the regulatory stack: defectiveness is presumed where the claimant demonstrates that the product does not comply with mandatory product safety requirements laid down in Union or national law that are intended to protect against the risk of the damage suffered.

The Cyber Resilience Act, Regulation (EU) 2024/2847, is precisely such a body of mandatory Union requirements for products with digital elements. The BSI summarises the practical core of it in one line: the support period has to be communicated by the manufacturer and is as a rule five years, and throughout that period security updates must be made available to end users and vulnerability handling must be operated.

Put the two instruments side by side and the division of labour is exact. One tells you that you must supply security updates. The other tells you what it costs when you do not, and it does so twice over: through Article 11(2)(c), which takes away the defence that the product was sound at delivery, and through Article 10(2)(b), which turns a breach of the security requirement into a presumption that the product was defective. That is the point at which a cybersecurity backlog stops being an engineering debt and becomes a balance sheet item. We wrote about the reporting side of the same regulation in our piece on the 24-hour duty; this is the other end of the same rope.

Point (a) deserves a separate sentence, because it is the quiet one. A defendant who cannot produce the evidence a court orders it to disclose does not merely argue from a weaker position. Defectiveness is presumed against it. In a software dispute the evidence in question is build records, vulnerability tracking and release history, which is to say exactly the material that tends to be reconstructable rather than retained.

Three years, ten years, twenty-five years

Article 16(1) sets a limitation period of three years for bringing a claim, running from the day the injured person became aware, or should reasonably have become aware, of the damage, the defectiveness and the identity of the liable operator. Because the clock starts at knowledge rather than at delivery, it is of limited comfort to a manufacturer.

Article 17(1) sits above it as a long-stop of ten years, running from the date the defective product was placed on the market or put into service, or, for a substantially modified product, from the date it was made available following that modification. Article 17(2) extends the long-stop to twenty-five years where the injured person could not bring proceedings within ten years because of the latency of a personal injury. And Article 15 closes the obvious exit: Member States must ensure that liability towards the injured person is not limited or excluded by a contractual provision or by national law.

Translated into engineering terms, the retention question answers itself. Documentation of what a version did, which vulnerabilities were known when, and which updates were offered to whom has to remain retrievable for ten years from shipping, and for a product capable of causing injury the horizon is longer still. Most development organisations retain that material for as long as the repository happens to exist, which is a different thing from a decade of deliberate retention.

Where the German act currently stands

Germany is transposing through a new statute that keeps the old name. The government bill on the modernisation of product liability law, Bundestag document 21/4297 of 25 February 2026, had its first reading on 4 March 2026 and was referred to the Committee on Legal Affairs and Consumer Protection. The committee held its expert hearing on 13 April 2026, at which the intended one-to-one transposition was assessed by the experts as going too far in some respects and not far enough in others. As at the date of this article no concluding deliberation has taken place.

It is tempting to read that as breathing room, and for the legal position it partly is: a directive does not, of itself, impose obligations between private parties before it has been transposed, and the limits of directive-conform interpretation between private parties are real. But the conclusion companies draw from it is usually wrong. The transposition deadline binds the legislature, not you, and the preparation the new regime demands is preparation you owe your own operation regardless: knowing which versions are in the field, knowing how long you can still patch them, and being able to prove both years later. None of that arrives with the promulgation of a statute. All of it takes longer than the time remaining.

The question this article does not decide

Honesty requires naming the open point, and here it concerns products that already exist. Article 2(1) attaches application to the placing on the market or putting into service after 9 December 2026, and the repeal provision keeps the old directive alive for products placed on the market before that date. Article 17(1)(b), however, runs the ten-year long-stop for a substantially modified product from the date that modified product was made available, which shows that the directive treats a substantial modification as a fresh event in its own right.

Whether a substantial modification carried out after 9 December 2026 pulls a product first sold in, say, 2024 into the new regime is not answered expressly by the provisions examined here, and no court has ruled on it. The reading we would plan against is the cautious one: if you substantially rework a legacy product after the cut-off, assume the new regime applies to the reworked version. The practical cost of being wrong in that direction is documentation you did not strictly need. The cost of being wrong in the other direction is a defence under Article 11(1)(c) that is not available.

What to do now

• Answer one question first: can any of our products injure a person. If the honest answer is no, and nothing you supply ends up in a consumer product, the exposure under this directive is small, and you should write that conclusion down with its reasoning rather than carry it around as a feeling. For a good number of pure B2B software houses that is where the topic ends.
• Treat the ability to update as the liability trigger it now is. One list: every version in the field, whether you can still build and ship a patch for it, and until when you say you will. The end of a support period stops being a marketing decision the moment Article 11(2)(c) attaches liability to the gap between what you could patch and what you did.
• Set retention to match Article 17, not to match the repository. Build records, vulnerability tracking and release history for ten years from placing on the market. Article 10(2)(a) makes the alternative expensive: the party that cannot disclose has defectiveness presumed against it.
• If you supply components, put the intended use in writing. Article 11(1)(f) is the only defence written for your position, and it runs on the specification and the instructions you were given. A module shipped against a phone call cannot be defended with one.
• Separate the two levels in your contracts. Towards the injured person, Article 15 makes a liability cap ineffective, and no drafting fixes that. Between you and your suppliers or customers, recourse, indemnity and insurance remain open, and that is where the clause work actually belongs.

Conclusion

The new product liability regime is at once narrower and wider than its reputation. Narrower, because only natural persons can claim and purely professional property and data are expressly outside it, which removes most of the classic B2B damage scenario. Wider, because for the first time the absence of a security update is a ground of liability in its own right, and because control, on the directive’s own definition, requires nothing more than being able to ship one. The companies that will be caught by this are not the ones that read the directive wrongly. They are the ones that read the first half, concluded correctly that their B2B business is largely outside it, and stopped before the part where their firmware ends up in somebody else’s consumer product. If you would like that boundary drawn against your actual products rather than a checklist, that is what a first conversation is for, and the neighbouring regime is covered in our piece on the Data Act and connected products.

Frequently asked questions on product liability for software