When Software Becomes a Product: Why a Security Update You Never Shipped Becomes a Liability Case on 9 December 2026 — and Why Your Observability Architecture Suddenly Has a Legal Function

The Hook: The Update That Never Came

Picture a device that exists by the thousand. A connected heating controller, sold to private households, with an app, a cloud backend, and firmware that supports updates. The device was placed on the market in 2027, it worked flawlessly, it met every applicable standard, and the manufacturer did nothing wrong in production.

Two years later, a vulnerability is published in a library embedded in that firmware. The manufacturer learns about it. A patch for the library exists. But the update pipeline for this product line has not been maintained since the responsible developer left, the signing certificate has expired, and the device series is commercially end-of-life anyway. So nothing happens. Eighteen months later, someone exploits the vulnerability, takes over the controller, lets the heating fail in January, and a pipe bursts in an apartment. The water damage costs thirty thousand euros. In the same incident, the user's locally stored consumption data and automation profiles are irretrievably destroyed.

Under the product liability law that governed Europe from 1985 to 2026, the manufacturer's position would have been remarkably comfortable. Software, on the prevailing view, was not a product at all. The defect did not exist when the product was placed on the market — it arose later, when the vulnerability was published. The destroyed data was not property damage, because data is not a tangible thing. For the property damage, the injured person would have borne a 500-euro deductible. And proving that precisely the failure to update one library in one firmware image caused the water damage would have been practically impossible for a private individual facing a manufacturer with exclusive access to logs, source code, and telemetry.

From 9 December 2026, almost every one of those points reverses. Directive (EU) 2024/2853 is not a patch at the margins. It is the first complete recasting of European product liability in 41 years. It expressly brings software within the definition of a product, it makes loss of data recoverable damage, it closes the liability exemption for later-arising defects precisely where software is involved, and it shifts a substantial part of the burden of proof onto the manufacturer. In Germany this happens through an entirely new Product Liability Act, which the Federal Government introduced in the Bundestag on 25 February 2026.

This article is an attempt to read the regime not as legal exegesis but as a requirements document for a software architecture. Because that, in effect, is what it has become.

Part 1: The Core Concept — Strict Liability Without Fault

What Separates Product Liability From Contract Law

Product liability is neither contractual liability nor classic fault-based liability. It is strict liability: whoever places a product on the market is liable for damage caused by its defectiveness — regardless of whether they worked carefully. The injured person need not prove any wrongdoing. They must prove three things: that the product was defective, that they suffered damage, and that there is a causal link between the two (Art. 10(1) of the Directive).

This construction has two features that are uncomfortable for software vendors. First: there is no contract to shape. Under Art. 5(1), any natural person who suffers damage has a claim — not only the buyer, but also the visitor, the neighbor, the child. Second: under Art. 15, liability toward the injured person may be neither limited nor excluded, by contract or by national law. Any limitation of liability in terms and conditions, an EULA, or a master agreement is ineffective against the injured person. The familiar practice of capping your own exposure through clauses does not work here.

The Gap That Stood Open for 41 Years

Directive 85/374/EEC defined "product" as a movable. In 1985 that was an obvious formulation, and it grew less apt with every passing year. Whether software is a movable was contested for decades: a CD-ROM carrying a program could still be understood as a tangible item, a download hardly, a service delivered over the network not at all. The result was a legal position in which the same control program was treated differently for liability purposes depending on its distribution channel — an outcome with no defensible rationale.

Art. 4(1) of the new Directive ends that in half a sentence. "Product" means any movable, even if integrated into or interconnected with another movable; and expressly, "product" includes electricity, digital manufacturing files, raw materials, and software.

Three consequences follow immediately:

Software is a product, irrespective of the mode of supply. The recital on the definition of product makes clear that it does not matter whether software is stored on a device, downloaded over a network, or accessed through cloud technologies. Operating systems, firmware, applications, drivers, and AI systems fall within it. Under the scheme of the Directive, the provider of an AI system is a manufacturer.

Digital manufacturing files are products. An STL or STEP file from which a part is produced or printed is itself subject to liability. Whoever distributes a defective 3D-printing template for a load-bearing bracket is liable for the consequences of its failure, even if they never touched a physical part.

Pure information stays outside. Source code as such, datasets, documentation, and scientific findings are not products according to the recitals. The boundary runs where information becomes function: an algorithm in a paper is information; the same algorithm compiled and executing in a device is a product.

Two New Foundational Concepts: Related Service and Control

The Directive introduces two concepts that hold the whole regime together.

A related service is, under Art. 4(3), a digital service integrated into or interconnected with a product in such a way that its absence would prevent the product from performing one or more of its functions. The cloud backend without which the heating controller has no schedules is a related service. Under Art. 4(4), a component is any item, whether tangible or intangible, any raw material, and any related service that is integrated into or interconnected with a product. An embedded library is therefore a component, and its manufacturer is liable under Art. 8(1)(b) directly to the injured person — not merely internally, toward the integrator.

The second concept is the lever on which everything hangs. The manufacturer's control exists, under Art. 4(5), where the manufacturer carries out, or authorizes a third party to carry out, the integration, interconnection, or supply of components including software updates — and also where the manufacturer is able to supply updates itself or through a third party. That word "able" is the most consequential passage in the entire Directive. Whoever has built in an update capability retains control. And control is what dismantles the central liability exemption.

Part 2: Scope — Who Is In and Who Stays Out

The Cut-Off Logic

Art. 2(1) defines scope not by the time of the damage but by the time of placing on the market: the Directive applies to products placed on the market or put into service after 9 December 2026. Under Art. 21, the old Directive 85/374/EEC is repealed with effect from 9 December 2026, but continues to apply to products placed on the market before that date. The German draft mirrors this with a transitional provision for products placed on the market up to 8 December 2026.

For software vendors, this logic is dangerously easy to underestimate. Software is not placed on the market once; it is placed on the market continuously. Every new version, every release, every SaaS instance first provided after the cut-off falls under the new regime. A company operating a product with a two-week release cycle in December 2026 will be entirely within the new law within a few weeks — regardless of when the first version was created. For continuously delivered software, the idea of a long transitional period is an illusion.

The Open-Source Exemption and Its Sharp Edge

Art. 2(2) excludes from scope free and open-source software developed or supplied outside the course of a commercial activity. This is a deliberate and welcome decision: nobody should face strict liability for a weekend project on a code platform.

The exemption is narrower, though, than many projects assume. It attaches not to the license but to commercial activity. According to the recitals, the exemption falls away where the software is supplied in exchange for a price — and equally where it is supplied in exchange for personal data used for purposes other than exclusively improving security, compatibility, or interoperability. That leaves typical mixed models on unclear ground: the open-core project with a commercial enterprise edition, the vendor monetizing the same codebase as a service, the project with telemetry whose data feeds product marketing. I am of the opinion that the reach of this data clause can only be settled by case law; the text of the Directive alone does not support a reliable dividing line. Anyone running a project with a commercial arm should not assume the open-source exemption will hold.

The inverse point matters too: whoever integrates a free component into a commercial product cannot hide behind the exemption. It protects the non-commercial developer, not the commercial integrator. Liability for a defective open-source library lands where it is used commercially — and after years of debate about the chronic underfunding of critical libraries, that is an economically interesting shift.

The Contested Point: SaaS

Whether software-as-a-service is covered is judged differently by different commentators. Part of the literature regards SaaS as expressly covered, because the mode of supply is irrelevant. Others point out that the Directive does not regulate services as such and makes no clear statement about SaaS. Both positions rest on the same text.

I am of the opinion that the dispute largely dissolves in practice through the definitions of component and related service: wherever a cloud service is necessary for a product's function, it is a related service and therefore captured as a component via Art. 4(4) — regardless of whether one classifies it as a product in its own right. Only a pure service that no product needs would remain outside. For architectural practice this means: the question whether your service "is a product" matters less than the question whether any product needs it in order to work.

Part 3: Defectiveness — What the Directive Means by Safety

Expected Safety, Not Agreed Safety

Art. 7(1) defines a product as defective where it does not provide the safety that a person is entitled to expect, or that is required under Union or national law. The benchmark is therefore not what was agreed, and not what is technically customary, but what may legitimately be expected. A documented shortcoming remains a defect if the documentation does not effectively shift that expectation.

Art. 7(2) lists the circumstances to be taken into account. The list is remarkable for software, because several entries appear for the first time in this recast:

Point (f) deserves particular attention. It ties liability to the whole body of product-related safety law. If a product fails to meet the requirements of the Cyber Resilience Act — for instance the duty to handle vulnerabilities throughout the support period — that is not merely a market-access violation. It is an argument for defectiveness in a liability case. And under Art. 10(2)(b), defectiveness is actually presumed where mandatory product safety requirements are breached. Compliance and liability are therefore no longer separate worlds: the same breach of duty appears twice, once as a regulatory infringement and once as a presumption against you.

Art. 7(3) provides the counterweight: a product is not defective merely because a better product is subsequently on the market. That matters for software. Shipping an update does not prove the previous version was defective. Otherwise the law would punish exactly what it is trying to compel.

Part 4: Damage — Data Becomes a Protected Interest

Art. 6(1) names three categories of damage:

Point (a): death or personal injury, expressly including medically recognized damage to psychological health. This is new and relevant for digital products: a demonstrable psychological health injury, for instance following a data breach or a manipulative design, is recoverable where it is medically recognized.

Point (b): damage to or destruction of property, with three exceptions: the defective product itself, products damaged by a defective component that the manufacturer integrated itself, and property used exclusively for professional purposes.

Point (c): destruction or corruption of data that is not used for professional purposes. This is the real break with the system. For the first time, loss of data as such is recoverable damage under product liability — with no need for accompanying property damage or personal injury. Destroyed photos, deleted private documents, corrupted configurations, lost save files: these are now heads of damage. Under Art. 6(2), compensation covers material loss and, insofar as national law provides for it, non-material loss as well.

Two further points sharpen the economic dimension considerably. The old Directive included a 500-euro deductible for property damage; it is gone. And it permitted Member States to impose a liability cap for personal injury from identical products, an option Germany had used at 85 million euros; that too is gone. For a software defect, which by definition reproduces identically in every instance, that cap was the quiet insurance against mass-claim exposure. It has been removed, and at the same time the European Representative Actions Directive allows such claims to be brought collectively.

The regime's boundary remains where matters are purely professional: property used exclusively for professional purposes and professionally used data are not covered, and under Art. 5 only natural persons have a claim. The classic B2B consequential loss therefore remains a matter of contract and tort law. But anyone building a product that runs in mixed environments — smart home, vehicle, medical device, consumer endpoint software — cannot rely on that boundary.

Part 5: Who Is Liable — The Cascade of Art. 8

Art. 8 names the liable parties in a cascade designed to ensure that someone is always reachable within the Union:

1. The manufacturer of the defective product (para. 1(a)).
2. The manufacturer of a defective component, where it was integrated or interconnected within that manufacturer's control (para. 1(b)). This is direct liability for library and module vendors.
3. The importer, the authorised representative and — if neither is established in the Union — the fulfilment service provider, where the manufacturer is established outside the Union (para. 1(c)).
4. Anyone who substantially modifies a product outside the manufacturer's control and makes it available is deemed to be a manufacturer (para. 2).
5. The supplier, where no liable operator established in the Union can be identified and the supplier fails, within one month of being asked, to identify such an operator or its own supplier (para. 3).
6. Providers of online platforms that allow consumers to conclude distance contracts, under the conditions of Art. 6(3) of Regulation (EU) 2022/2065 — that is, where the platform presents the product as its own (para. 4).

Point 4 is underrated for software. Whoever substantially modifies someone else's product and redistributes it is liable as a manufacturer. A fork with substantial changes, a heavily customized container image, a device shipped with the system integrator's own patches: any of these can establish the manufacturer role. The line between configuration and substantial modification is blurred and will be one of the first disputes in practice.

Under Art. 12(1), multiple operators are jointly and severally liable, and Art. 14 governs recourse among them. Art. 12(2) contains a particular feature: a manufacturer that has integrated a defective software component has no right of recourse against that component's manufacturer where it has contractually waived that right, and the provision has micro and small enterprises as component manufacturers particularly in view. For small software vendors, this is one of the few genuinely usable levers in the regime — but it operates only internally. Toward the injured person, direct liability under Art. 8(1)(b) is untouched, and Art. 15 prohibits any limitation vis-à-vis them.

Part 6: The Procedural Revolution — Disclosure and Three Presumptions

Substantively, the Directive is strict. Procedurally, it is what makes the practical difference. Because the old law was largely ineffective for injured persons chiefly for one reason: proving a software defect without access to code, logs, and telemetry was effectively impossible.

Art. 9: Disclosure of Evidence

Under Art. 9(1), the defendant must disclose relevant evidence in its control where the claimant has presented facts and evidence sufficient to support the plausibility of the claim. Under para. 2, the same applies in reverse, in the defendant's favor. Paragraphs 3 to 5 limit this to what is necessary and proportionate, oblige courts to take into account the legitimate interests of all parties — in particular the protection of trade secrets — and allow confidentiality measures.

This is not US-style discovery, but for continental European civil procedure it is a considerable step. A disclosure order can cover anything relevant to assessing defectiveness: source code, build artifacts, test results, code review records, ticket systems, SBOM data, vulnerability assessments, telemetry — and, in practice probably the most sensitive, internal communications about known risks.

Art. 10: The Three Reliefs

Art. 10(1) retains the principle: the claimant proves defectiveness, damage, and causation. Three breaches of that principle then follow:

Defectiveness is presumed (para. 2) where the defendant fails to disclose relevant evidence contrary to Art. 9(1) (point (a)), where the product does not comply with mandatory product safety requirements (point (b)), or where the damage was caused by an obvious malfunction of the product during normal use (point (c)).

Causation is presumed (para. 3) where the product is defective and the damage caused is of a kind typically consistent with the defect in question.

The court shall presume defectiveness and/or causation (para. 4) where the claimant faces excessive difficulties of proof due to technical or scientific complexity, and demonstrates that both are likely.

Under para. 5, all presumptions are rebuttable. And that is the real message to engineering: only those who can document can rebut. Paragraph 4 is almost tailor-made for machine learning systems — hardly any court will expect a private claimant to prove the defectiveness of a neural network. The realistic expectation is that in software cases one of the presumptions will regularly apply, placing the manufacturer in the position of having to establish its own correctness.

That gives the observability architecture a legal function. Reproducible builds, unbroken version provenance, signed and auditable update pipelines, a current SBOM, documented vulnerability decisions with their reasoning, traceable telemetry about device state and the versions actually installed: from December 2026 this is not merely operational quality, it is evidence. A manufacturer that cannot demonstrate the distribution of a firmware version across its installed base cannot rebut the presumption under Art. 10(2)(c). And a manufacturer that produces nothing substantive in response to a disclosure order gets defectiveness presumed under point (a) — silence is the most expensive option here.

Part 7: The Exemptions and the Hole in Their Middle

Art. 11(1) lists the grounds for exemption that the economic operator must prove: that it did not place the product on the market (point (a)) or did not make it available (point (b)); that the defect did not exist at the relevant time or came into being afterwards (point (c)); that the defect is due to compliance with legal requirements (point (d)); that the objective state of scientific and technical knowledge did not allow the defect to be discovered (point (e) — the development risk defence); that, for a component manufacturer, the defect is attributable to the design of the final product or to the product manufacturer's instructions (point (f)); and that, for someone who modified a product, the defect concerns a part not affected by the modification (point (g)).

Point (c) was the most important software defence for decades. A program that matched the state of the art when shipped did not become defective merely because a new attack technique was published three years later.

Art. 11(2) ends that. By way of derogation from paragraph 1, point (c), there is no exemption where the defectiveness is due to any of the following, provided it is within the manufacturer's control: a related service; software, including software updates; the absence of software updates or upgrades necessary to maintain safety; or a substantial modification of the product.

The third item is the provision that decides the opening story. The absence of a security-relevant update is an independent ground of liability. And because "control" exists under Art. 4(5) as soon as the manufacturer is able to supply updates, a duty arises that reaches far beyond placing the product on the market. Patch management is therefore no longer a service question or a goodwill matter, but a duty backed by liability.

How long that duty lasts, the Directive leaves open — and that is its greatest practical uncertainty. Two periods bound the risk in time: under Art. 16, claims are time-barred three years from the point at which the injured person knew, or should reasonably have known, of the damage, the defectiveness, and the identity of the liable operator. Under Art. 17, the right expires ten years after the product was placed on the market or put into service — for substantially modified products, calculated from the moment it was made available after modification — and, for latent personal injury, only after 25 years. For a software product, that amounts to a risk horizon of at least a decade. Defining a support period does not define your liability boundary; it merely defines your service promise, while the ten-year period runs regardless.

I am of the opinion that the most effective practical answer is not longer support promises but a deliberate reduction of your own surface of control: fewer remote capabilities, more clearly documented product boundaries, a defined and communicated end of update capability. That cannot be substantiated from the text — it is an assessment that the first decisions on Art. 11(2) will either confirm or refute.

In addition, Art. 18 permits Member States to derogate from the development risk defence and impose stricter liability for specific product categories, subject to notification duties toward the Commission by 9 December 2026. And Art. 19 obliges Member States to publish final judgments of their courts of appeal or highest instance; the Commission maintains a publicly accessible database. For practitioners this is among the most important provisions of all: the interpretive questions this article has to leave open will be answered, publicly and readably, from 2028 onward.

Part 8: Germany's Implementation — A New Product Liability Act

Germany is implementing the Directive not by amending the existing statute but through a new free-standing act of the same name. The draft Act to Modernise Product Liability Law was introduced on 25 February 2026 as Bundestag printed paper 21/4297; the Bundesrat had delivered its opinion on 30 January 2026. It is the first comprehensive reform of German product liability law since 1989.

The structure of the draft follows the Directive: § 1 governs liability for death, personal injury and damage to health, damage to property, and the destruction or corruption of data not used for professional purposes. Sections 4 and 5 address liability for defective components and related digital services, and the liability of a party who substantially modifies a product. Sections 7 to 9 contain the concept of defectiveness, the assessment date including software updates where the manufacturer's control continues, and the grounds for exemption. Sections 10 to 13 reproduce the liability cascade with importers, authorised representatives, fulfilment service providers, suppliers, and certain online platforms. Sections 14 to 18 govern compensation, the three-year limitation period, expiry after ten years or, in latency cases, up to 25 years, and the prohibition on contractual derogation. Sections 19 and 20 implement disclosure and the presumptions; sections 21 to 23 contain the pharmaceuticals exception, the publication of judgments, and the transitional provision for products placed on the market up to 8 December 2026.

One figure from the draft itself is striking: the expected compliance burden for business and citizens is stated as "no change"; quantified additional costs arise only for the courts and for publishing judgments, roughly 66,000 euros for the Länder and 3,000 euros for the Federation. I am of the opinion that this assessment significantly understates the actual costs inside software-producing companies, because while the Directive imposes no new documentation duties as such, Art. 10 effectively demands an evidentiary posture that costs money to build. That cannot be substantiated — it is a forecast.

Part 9: A Framework for Practice

Anyone supplying software in the EU from December 2026 can reduce the Directive to seven verifiable questions:

The uncomfortable punchline of this list: none of the seven questions is a legal question. All seven are questions about build, release, monitoring, and documentation architecture. The Directive moves compliance out of the legal department and into the engineering organization, without ever saying so.

The Central Takeaway

The new product liability regime changes less about what software is allowed to do than about what a manufacturer must be able to prove. Substantively much of it feels familiar: strict liability, a concept of defectiveness, grounds for exemption. The effect emerges from the combination of three passages that look harmless in isolation — the word "able" in the definition of control in Art. 4(5), the removal of the exemption for missing security updates in Art. 11(2), and the presumptions of Art. 10. Together they produce a duty to keep software safe across more than a decade, and the burden of proving that you did.

The practical prompt for action is therefore not legal but technical, and it fits in one sentence: assume that in ten years you will have to demonstrate, for a version you ship today, what was inside it, who decided that, and which devices actually received the update. If your current stack cannot answer those three questions from records, then from 9 December 2026 that is no longer a maturity gap — it is an open liability exposure. The concrete first step, doable in a week: take any production version and try to reconstruct, purely from existing artifacts and logs, which dependencies were present in which version, and on how many installations it still runs today. Whatever you cannot reconstruct is your gap list.

A Question to Reflect On

The Directive ties liability to control — and thereby creates an incentive to give control away: whoever enables no remote updates is not liable for their absence. At the same time, update capability is the single most effective means of keeping products safe over their lifetime, and the Cyber Resilience Act requires it.

How would you resolve that contradiction for a specific product you are responsible for today — and where exactly would you draw the line between "enough control to be able to deliver safety" and "little enough control that I am not liable indefinitely for it"? And would that line be in the same place if you had to draw it not as the manufacturer, but as a user of the product?

Cross-References in the Vault

• Security by Default: The EU Cyber Resilience Act and the End of the Insecure Product — the obverse of the same coin: the CRA prescribes the security duties whose breach triggers liability via Art. 7(2)(f) and Art. 10(2)(b).
• The Pyramid of Risk: How the EU AI Act Tames Artificial Intelligence – and Why It Concerns the Whole World — the counterpart for AI systems: the AI Act governs market access, product liability governs the consequences of failure, and Art. 7(2)(c) connects the two through learning ability.
• The Backdoor at the Heart of Linux: The XZ Attack and the Anatomy of a Supply-Chain Compromise — the real-world case for component liability under Art. 8(1)(b), and for the question of whom the open-source exemption actually protects.
• The Way Out of the Cloud: Why the Data from Your Machines Belongs to You, What a Cloud Migration May Cost From January — and Why That Legal Question Has Very Technical Consequences — the same class of devices seen from the data side, and the second European instrument to treat data as a protected interest in its own right.
• NIS2 and What It Really Means for Mid-Market IT Consulting Firms in Germany — the organizational side of vulnerability management, whose failures become liability-relevant here.
• The Algorithm as Judge: Article 22 GDPR, the SCHUFA Ruling, and the Right to a Human Decision — the same regulatory pattern: burdens of proof and explanation are shifted to wherever the technical information sits.
• The End of the Password: Passkeys, WebAuthn and the Anatomy of Phishing-Resistant Sign-In — an example of "the safety a person is entitled to expect" within the meaning of Art. 7(1).
• When the Processor Guesses Too Much: Spectre, Meltdown, and the Sin of Speculative Execution — the textbook case for the development risk defence of Art. 11(1)(e) and its limits.

Sources

1. Directive (EU) 2024/2853 of the European Parliament and of the Council of 23 October 2024 on liability for defective products and repealing Council Directive 85/374/EEC, OJ L of 18 Nov 2024; in force since 8 December 2024, applicable to products placed on the market after 9 December 2026. EUR-Lex, English version; German version
2. German Bundestag, printed paper 21/4297 of 25 Feb 2026: Entwurf eines Gesetzes zur Modernisierung des Produkthaftungsrechts (Federal Government bill, lead ministry BMJV; Bundesrat opinion of 30 Jan 2026). New free-standing act, entering into force 9 December 2026. dserver.bundestag.de
3. German Federal Ministry of Justice and Consumer Protection: Gesetz zur Modernisierung des Produkthaftungsrechts — legislative procedure with ministerial and government drafts. bmjv.de
4. Christina Kiefer / Laure Herlitz (reuschlaw): Liability for software under the new European Product Liability Directive, International Bar Association, 30 April 2025 — analysis of the product definition, the open-source exemption, update duties, and the presumptions of Arts. 9 and 10. ibanet.org
5. Dr. Oliver Wolff-Rojczyk / Dominik Rosemann (FPS): Die neue EU-Produkthaftungsrichtlinie – Risiken auch für Softwarehersteller, 21 January 2025 — treatment of SaaS, component liability, the abolition of the 500-euro threshold and of the liability cap, and the relationship to the CRA and the AI Act. fps-law.de
6. GvW Graf von Westphalen: Alles neu?! Produkthaftungsrichtlinie (EU) 2024/2853 der EU in Kraft getreten and Reform des Produkthaftungsrechts: Der Referentenentwurf zur EU-Richtlinie im Überblick — overviews of the Directive and the state of implementation. gvw.com

Note: this article is a technical account of the state of the law, not legal advice. Statements about the German implementation refer to the bill as set out in Bundestag printed paper 21/4297 of 25 February 2026; the parliamentary process may still change the text.

← All articles