Product Liability for Software From 9 December 2026: What Directive (EU) 2024/2853 Changes for IT Delivery

The Cut-Off Date: What Actually Happens on 9 December 2026

Directive (EU) 2024/2853 on liability for defective products is dated 23 October 2024 (Council decision: 10 October 2024) and was published in the Official Journal on 18 November 2024 (see https://eur-lex.europa.eu/eli/dir/2024/2853/oj). It repeals Directive 85/374/EEC with effect from 9 December 2026 (Article 21), and Member States must bring their transposition measures into force by that day (Article 22(1)).

In practice Article 2(1) as corrected on 7 May 2026 decides: the Directive applies to products placed on the market or put into service after 8 December 2026, that is from 9 December 2026 (see https://eur-lex.europa.eu/eli/dir/2024/2853/corrigendum/2026-05-07/oj). For products placed on the market before that date the old regime continues under Article 21. What counts is therefore the date of placing on the market — the first making available on the Union market (Article 4(8)) — not the date of the damage. Whoever substantially modifies a product outside the manufacturer’s control and then makes it available on the market or puts it into service is treated as the manufacturer (Article 8(2)); for the modified product the ten-year expiry period starts afresh (Article 17(1)(b)).

In Germany the Act on the Modernisation of Product Liability Law and the Amendment of Further Provisions (Gesetz zur Modernisierung des Produkthaftungsrechts und zur Änderung weiterer Vorschriften) transposes the Directive (government bill: Bundestag printed paper 21/4297, see https://dserver.bundestag.de/btd/21/042/2104297.pdf). The Bundestag debated the bill in first reading on 4 March 2026 and referred it to the Committee on Legal Affairs and Consumer Protection, which held its hearing on 13 April 2026. On 8 October 2026 the Bundestag adopted the act in the version recommended by the committee (printed paper 21/8429; see https://www.bundestag.de/dokumente/textarchiv/2026/kw10-de-produkthaftungsrecht-1150448 and https://www.bundesregierung.de/breg-de/aktuelles/produkthaftung-digitalisierung-ki-2399966). The act enters into force on 9 December 2026 (Article 17(1) of the act); only Articles 2 and 5 to 16 – including the provision that the existing Product Liability Act expires on 9 December 2026 – enter into force on the day after promulgation (Article 17(2)). For products placed on the market or put into service up to and including 8 December 2026 the existing Product Liability Act remains applicable (§ 23 ProdHaftG; see Bundesrat printed paper 584/26, https://dserver.bundestag.de/brd/2026/0584-26.pdf). At its 1069th session on 16 October 2026 the Bundesrat resolved not to file a request under Article 77(2) of the Basic Law to convene the Mediation Committee (Vermittlungsausschuss) (Bundesrat printed paper 584/26 (resolution), https://dserver.bundestag.de/brd/2026/0584-26B.pdf); the act has thereby come into being (Article 78 of the Basic Law). Promulgation in the Federal Law Gazette had not yet taken place on 17 October 2026 (see https://www.recht.bund.de/de/bundesgesetzblatt/bgbl-1/bgbl-1_node.html). For planning purposes the Directive and the German act draw the line on the same day: for products placed on the market or put into service up to and including 8 December 2026 the previous regime applies (Article 2(1) of the Directive as corrected, § 23 ProdHaftG), for later products the new one.

Software Is a Product — Also When Supplied as a Cloud Application or SaaS and as an AI System

Under Article 4(1) a “product” is any movable, and the definition expressly includes electricity, digital manufacturing files, raw materials and software. Recital 13 clarifies that software is a product irrespective of how it is supplied or used — whether stored on a device, accessed through a communication network or cloud technologies, or supplied through a software-as-a-service model. Developers or producers of software, including providers of AI systems within the meaning of Regulation (EU) 2024/1689, should be treated as manufacturers under recital 13 (binding: Article 4(10); see https://eur-lex.europa.eu/eli/dir/2024/2853/oj). Services as such are not covered by the Directive; digital services integrated into or interconnected with the product, however, count as components where they are within the manufacturer’s control (recital 17, Article 4(3) and (4)).

Two delimitations matter. Information is not a product: the content of digital files such as media files or e-books, and the mere source code of software, are outside strict liability (recital 13). And free and open-source software developed or supplied outside the course of a commercial activity is excluded under Article 2(2). Anyone who integrates open-source components into their own product in the course of a commercial activity is, by contrast, the manufacturer of that product.

For delivery organisations this raises a question of role before any question of liability. A “manufacturer” under Article 4(10) is anyone who develops, manufactures or produces a product, has it designed or manufactured, or presents itself as its manufacturer by putting its name, trademark or other distinguishing features on it, or develops, manufactures or produces it for its own use. Making available on the market covers any supply in the course of a commercial activity, whether paid or free of charge (Article 4(7)). Whether and when software developed individually for a client is “placed on the market” follows from the definitions in Article 4(7) to (9); the Directive makes no express provision on this, and interpretation ultimately rests with the courts.

Who Is Liable: Manufacturers, Component Manufacturers and the “Manufacturer’s Control”

Article 8(1) names the liable economic operators: the manufacturer of the defective product; the manufacturer of a defective component where that component was integrated into or interconnected with the product within the manufacturer’s control and caused the defect; and — where the manufacturer is established outside the Union — the importer and the authorised representative and, subsidiarily, the fulfilment service provider where neither an importer nor an authorised representative is established in the Union. The product manufacturer’s liability expressly extends to damage caused by a defective component that it integrated under its control. Whoever substantially modifies a product outside the manufacturer’s control and then makes it available on the market or puts it into service is treated as the manufacturer (Article 8(2)); distributors are liable in a subsidiary way if they fail to identify an economic operator within one month of a request (Article 8(3)).

The key concept for software is the “manufacturer’s control” (Article 4(5)). It exists where the manufacturer carries out or authorises the integration, interconnection or supply of a component, including software updates or upgrades, where it modifies the product — or where it is able to supply software updates or upgrades itself or via a third party. A component also includes an intangible item or a related service (Article 4(4)), that is a digital service without which the product could not perform one or more of its functions (Article 4(3)).

Several liable operators can be held jointly and severally liable (Article 12(1)); recourse follows national law (Article 14). Article 12(2) contains a particular rule for software components: a manufacturer that integrates software as a component into a product has no right of recourse against the manufacturer of a defective software component where that manufacturer was a micro or small enterprise within the meaning of Recommendation 2003/361/EC at the time the component was placed on the market and the two have contractually agreed to waive that right. The waiver must therefore be agreed; it is not automatic.

When Software Is Defective: Cybersecurity, Learning Ability and Interplay

A product is defective where 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)). Article 7(2) lists by way of example circumstances to be taken into account. Four are particularly relevant for software: the effect on the product of its ability to continue to learn or acquire new features after being placed on the market (point (c)), the reasonably foreseeable effect on the product of other products that can be expected to be used together with it, including by means of interconnection (point (d)), the time when the product was placed on the market or — where the manufacturer retains control — the time when it left the manufacturer’s control (point (e)), and the relevant product safety requirements, including safety-relevant cybersecurity requirements (point (f)).

Recital 32 spells out the connection: a product can be found defective because of cybersecurity vulnerabilities, for instance where it does not meet safety-relevant cybersecurity requirements. This links product liability to the Cyber Resilience Act, whose reporting duties under Article 14 have applied since 11 September 2026 and whose other obligations apply in principle from 11 December 2027 (Article 71, see https://eur-lex.europa.eu/eli/reg/2024/2847/oj and CRA reporting duty and SDLC roadmap).

Two limits apply to the standard: a product is not to be considered defective for the sole reason that a better product, including updates or upgrades, has already been or is subsequently placed on the market or put into service (Article 7(3)). And under Article 11(1)(d) an economic operator is not liable if it proves that the defect is due to compliance of the product with legal requirements.

Updates: Why the “Defect Arose Later” Objection Does Not Work for Software

The classic exoneration argument is that the defect did not exist when the product was placed on the market (Article 11(1)(c)). For software the legislator has curtailed that argument: under Article 11(2) an economic operator is not exonerated where the defectiveness is due to a related service, to software including software updates or upgrades, to the lack of software updates or upgrades necessary to maintain safety, or to a substantial modification of the product — provided the cause is within the manufacturer’s control.

This makes the update process liability-relevant: a faulty update that the manufacturer ships and a missing security update that it could have provided both fall within the manufacturer’s control (Article 4(5)). The Directive itself creates no duty to offer security updates for a given period; such duties follow from other regimes. For decisions on end of support and patch prioritisation the following applies: as long as a manufacturer can supply updates, the product remains within its control under Article 4(5)(b) (recital 19); how a declared end of support affects this is not expressly regulated.

A further ground of exoneration is the state of the art: an economic operator is not liable if it proves that the defect could not be discovered given the objective state of scientific and technical knowledge at the time of placing on the market or during the period under the manufacturer’s control (Article 11(1)(e)). Member States may deviate and retain existing rules under which liability applies nonetheless; Member States wishing to retain such measures must communicate them to the Commission no later than 9 December 2026 (Article 18(1)).

Burden of Proof and Disclosure: What Must Be Produced in a Dispute

The principle stands: the claimant must prove the defect, the damage and causation (Article 10(1)). The Directive builds two facilitations on top. First, disclosure: at the request of a claimant who has presented facts and evidence sufficient to support the plausibility of the claim, the defendant must disclose relevant evidence at its disposal (Article 9(1)), limited to what is necessary and proportionate (Article 9(3)) and taking confidentiality and trade secrets into account (Article 9(4) and (5)). The defendant, too, can request disclosure from the claimant (Article 9(2)).

Second, the presumptions in Article 10(2) to (4): defectiveness is presumed where the defendant fails to disclose relevant evidence (point (a)), where the claimant demonstrates that the product does not comply with mandatory product safety requirements intended to protect against the risk of the damage suffered (point (b)), or that the damage was caused by an obvious malfunction of the product during reasonably foreseeable use or under ordinary circumstances (point (c)). Causation is presumed where the product is defective and the damage is of a kind typically consistent with the defect (paragraph 3). Where, despite disclosure, technical or scientific complexity makes proof excessively difficult for the claimant, courts presume defect or causation if the claimant shows that it is likely (paragraph 4). All presumptions are rebuttable (paragraph 5).

The consequence for delivery organisations is practical: anyone who fails to produce evidence in a dispute although obliged to do so risks the presumption of defect under Article 10(2)(a). Evidence that arises anyway for the Cyber Resilience Act and for security processes — bills of materials (see SBOM mandatory fields under BSI TR-03183-2), test and release records, vulnerability handling — can serve as a basis for defence in a dispute and is at the same time what the claimant can request under Article 9(1).

Whose Damage Is Covered — and Whose Is Not

Under Article 5(1) any natural person who suffers damage caused by a defective product is entitled to compensation; persons to whom the claim has been transferred and persons acting on behalf of injured persons can also assert it (paragraph 2). Under Article 6(1) only three kinds of damage are compensable: death or personal injury, including medically recognised harm to psychological health; damage to or destruction of property — except the defective product itself, a product damaged by a defective component under the manufacturer’s control, and property used exclusively for professional purposes —; and destruction or corruption of data that are not used for professional purposes. For property, mixed private and professional use suffices (recital 25); for data, even partly professional use excludes the claim (recital 22). Resulting material losses are included, as are non-material losses to the extent national law provides compensation (Article 6(2)).

Liability towards the injured person cannot be limited or excluded by contract or by national law (Article 15). Claims under national contract and tort law on grounds other than the defectiveness of a product as provided for in this Directive remain unaffected (Article 2(4)(b), Article 6(3)).

This yields a classification that is often overlooked in B2B delivery: a company’s own losses, such as business interruption or professionally used data, are not the subject of this Directive. The risk for suppliers and integrators exists directly towards injured natural persons (manufacturer of a defective component, Article 8(1)(b), jointly and severally under Article 12(1)) and internally through recourse (Article 14) and the question of who agreed the waiver under Article 12(2).

Limitation and Expiry: How Long Liability Lasts

Claims become time-barred three years from the day on which the injured person became aware, or should reasonably have become aware, of the damage, the defect and the identity of the liable economic operator (Article 16). Independently of that, the right to compensation expires ten years after the product was placed on the market or put into service, for a substantially modified product ten years after it was made available again — unless proceedings have been initiated in the meantime (Article 17(1)). Where latency of a personal injury prevented proceedings within ten years, the expiry period is extended to 25 years (Article 17(2)).

For long-lived software — firmware, industrial control systems, medical and vehicle software — this means a liability horizon of ten years from the placing of the product on the market, up to 25 years for latent personal injury. Substantial modifications, including by update, start a new period (Article 17(1)(b), recitals 40 and 58); non-substantial updates do not. The Directive contains no retention duty; which artefacts — source states, build artefacts, bills of materials, release decisions — are retained for that long is a governance decision that should be taken before 9 December 2026.

Interplay With the Cyber Resilience Act and the AI Act

The Product Liability Directive replaces neither the Cyber Resilience Act nor the AI Regulation. On the Cyber Resilience Act, its recital 31 states that Directive (EU) 2024/2853 is complementary to the Regulation; a lack of security updates after placing on the market can trigger the manufacturer’s liability. Article 10(2)(b) makes non-compliance with mandatory product safety requirements the anchor of a presumption of defect, and Article 7(2)(f) expressly names safety-relevant cybersecurity requirements. Anyone who meets the requirements of the Cyber Resilience Act removes the basis for that ground of presumption; exoneration does not follow from it, because defectiveness is assessed under Article 7 as a whole. Anyone who misses them gives the claimant the anchor. For AI systems recital 13 provides that providers within the meaning of the AI Regulation should be treated as manufacturers; the ability to keep learning after being placed on the market is an express assessment factor (Article 7(2)(c)). How the deadlines and duties of the four major regimes interact is shown in Regulatory Collision 2026.

Roadmap to 9 December 2026

The order below prioritises by role and evidence risk. Each step hangs on a provision of the Directive, not on an expectation about national transposition.

1. 1First — inventory and cut-off date: capture all shipped artefacts — applications, SaaS services, firmware, libraries — and record per product when it was first placed on the market (Article 2(1), Article 4(1) and (8)); note separately versions that qualify as a substantial modification (including by update, recital 40). Products placed on the market before the cut-off date stay under the old regime (Article 21); a product substantially modified by an update is deemed made available at the time of the actual modification (recital 40), and updates that are not a substantial modification do not affect the expiry period of the original product (recital 58).
2. 2Clarify the role per artefact: manufacturer, component manufacturer, authorised representative, importer or distributor (Article 4(10), (14) and (15), Article 8). Whoever presents itself under its own name or substantially modifies outside the manufacturer’s control and makes available is treated as manufacturer (Article 4(10)(b), Article 8(2)).
3. 3Fix the update and support policy: support period, vulnerability triage, criteria for security updates, communication of end of support. These decisions are relevant to the assessment of the manufacturer’s control (Article 4(5), Article 11(2)).
4. 4Standardise evidence per release: bill of materials, test and release records, vulnerability handling, decision logs — findable and usable for disclosure requests (Articles 9 and 10). Align the retention horizon with Article 17 (the Directive contains no retention duty).
5. 5Review supplier contracts: liability chains, recourse and waiver clauses. For software components from micro and small enterprises the recourse waiver under Article 12(2) is a deliberate decision; no limitation of liability works against injured persons (Article 15). The [Vendor Assessment template](/templates/vendor-assessment) captures vendors, contracts and risks.
6. 6Connect the CRA process with product liability evidence: set up the reporting chain, PSIRT and release gates so that the same artefacts serve both purposes (see the [CRA reporting readiness check](/check/cra) and the [Delivery Audit template](/templates/delivery-audit)).
7. 7Have insurance and contract clauses legally reviewed: the Directive does not permit a contractual limitation towards injured persons (Article 15); how general and product liability cover relate to that is for the insurer to clarify — not for this article.
8. 8Watch the procedure: following the Bundesrat’s resolution of 16 October 2026 (no request under Article 77(2) of the Basic Law, Bundesrat printed paper 584/26 (resolution)) the German act has come into being; promulgation in the Federal Law Gazette is the next step. The Member States’ notifications under Article 18 determine details such as liability for development risks.