From December 2026: Product Liability for Medical Software

Medical software discussions usually focus on the MDR, risk class and the notified body. Product liability answers another central question: who carries responsibility when software causes damage? From 9 December 2026, a modernised EU framework applies to products placed on the market or put into service from that date [1].

Directive (EU) 2024/2853 makes the position explicit: software is a product. This applies whether it is installed on a device, used over a network, accessed through the cloud or supplied as Software as a Service [1]. For medical software, updates, evidence and liability preparedness become even more closely connected.

Executive Summary

1. A new directive with a fixed date

Directive (EU) 2024/2853 replaces the Product Liability Directive of 1985. It applies to products placed on the market or put into service from 9 December 2026. The previous directive remains relevant for earlier products. Member States must transpose the requirements into national law by that date [1] [3].

The core principle remains liability without fault. The injured person needs to demonstrate the defect, the damage and the causal link. They do not need to prove fault by the manufacturer. Compensable damage includes death and personal injury, including medically recognised harm to psychological health. It also includes damage to property and destruction or corruption of data that are not used exclusively for professional purposes [1].

The directive broadly harmonises the framework. Contractual exclusions of liability towards injured persons are ineffective. National liability caps are likewise not part of this framework [1].

2. Software is a product, including in the cloud

Article 4 expressly lists software as a product. Recital 13 confirms that the mode of supply does not matter. The classification spans firmware and apps through to AI systems. It also covers cloud services and SaaS models. Developers or producers of software are treated as manufacturers for this purpose [1].

The distinction matters. Mere source code and the content of digital files are not products. Free and open-source software developed or supplied outside a commercial activity is also excluded. Where such software is integrated into a product in the course of commercial activity, the manufacturer of the overall product remains responsible for its safety [1].

The supply chain also comes more clearly into view. A component can be a physical or digital item. This includes a related digital service when the product cannot perform functions without it. The manufacturer of the product and the manufacturer of a defective component can both be liable. A person who substantially modifies a product outside the original manufacturer's control and subsequently makes it available can become a manufacturer [1].

3. What matters particularly for medical software

Updates become a liability matter. The previous directive already allowed an exemption where a defect did not exist when the product was put into circulation or came into being later [3]. The new directive narrows that exemption. It does not apply where a defect is due to a related service, software including updates or upgrades, missing safety-critical updates, or a substantial modification. In each case, the relevant element must be within the manufacturer's control [1].

Control can also exist when a manufacturer has a third party provide updates, authorises them or presents them as part of the product. Where the installation of a supplied security update is outside the manufacturer's control, for example because a user does not install it, the individual case calls for a different assessment. The directive does not create a standalone update duty. It governs liability consequences where a duty material to product safety is not fulfilled [1].

The evidence position becomes more accessible. In plausibly substantiated claims, national courts can order disclosure of relevant evidence. Where ordered disclosure does not take place, defectiveness can be presumed. The same applies to non-compliance with mandatory safety requirements or an obvious malfunction [1].

Where technical or scientific complexity creates excessive difficulty, courts can presume defectiveness, causation or both. Claimants must establish that the relevant proposition is likely. All presumptions remain rebuttable. Trade secrets require appropriate protection by the court. For medical software, this increases the value of technical documentation that is clearly structured and available [1].

The MDR refers to financial preparedness. Article 10(16) MDR requires manufacturers to have measures in place for sufficient financial coverage. The level must be proportionate to the risk class, type of device and size of the enterprise [2]. The MDR also requires documented risk management, technical documentation, a quality management system, change procedures and post-market surveillance. The Product Liability Directive does not turn these records into an automatic defence. They do strengthen an organisation's ability to explain lifecycle control, decisions and responsibilities [2].

4. Example: dosage software updated in 2027

An MDR-certified medical software product calculates doses. Version 3 reaches the market in January 2027. A later update introduces a calculation error. Alternatively, a known security vulnerability remains open although a necessary security update is within the manufacturer's control. If a patient suffers damage as a result, the manufacturer cannot rely only on the argument that the defect arose after the original release [1].

An update that substantially modifies a product also matters for time limits. The ten-year expiry period starts again for the substantially modified product when that modification is made available. The assessment of a substantial modification remains case-specific and will become clearer through national implementation and case law [1].

5. What manufacturers can prepare now

Documentation maintained in line with MDR Annex I Section 17.2, covering the software lifecycle, risk management, verification and validation, provides a strong basis [2]. It does not replace legal assessment in a specific case. It does ensure that safety and development decisions remain traceable across the lifecycle.

Context

MDR conformity does not automatically prevent liability cases. A manufacturer can be exempt where the defect is due to compliance with binding legal requirements. The development-risk exemption also remains available in principle. Member States may make specific provisions on this within the directive [1].

The directive does not replace national implementing legislation. How courts assess substantial software changes or excessive difficulties of proof will emerge through application. Damage to property or data used exclusively for professional purposes is not included in the defined damage categories. Contractual claims and data-protection law continue to apply alongside the directive [1]. This article provides professional context and does not constitute legal advice.

Conclusion

From 9 December 2026, EU product liability expressly covers medical software. Manufacturers that control updates also carry responsibility for defects arising from updates or missing safety-critical corrections within that control. A robust foundation comes from aligning the update process, technical documentation, supply chain and financial preparedness now.