Updates, Cybersecurity and Product Liability After Sale

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

How updates can change product liability after sale

A software update can create an unsafe product condition, remove an existing vulnerability or leave an important safety problem unresolved. Selling the original device does not automatically end the manufacturer's involvement. Connected products can continue to depend on software, remote services and decisions made long after delivery. Under Directive (EU) 2024/2853, the legal analysis connects those continuing relationships to defectiveness, responsibility, damage and causation. An update history supplies evidence about those questions; it does not answer all of them by itself.

The corrected Directive applies to products placed on the market or put into service after 8 December 2026. Member States have a 9 December 2026 transposition deadline. A transaction, product or dispute therefore needs its own scope and national-law check. This guide explains the Directive's framework without assuming that every existing connected device falls within it or that a country has already enacted particular implementing rules.

Begin with the product and its actual software state

Software is expressly included in the Article 4 product definition. It can also form a component of a wider product. A connected device may depend on an operating system, a control application, embedded firmware and a remote service. Identifying only the device model can miss the part of the system that changed. A release number can also be incomplete where configuration, feature activation or the service environment affected the relevant behaviour.

Reconstruct what the affected product was running when the incident happened. Distinguish the version available for download from the version actually installed. Preserve relevant configuration and dependency information alongside release records. An investigation that compares the latest public release with an incident from an earlier deployment may be examining different products in practical terms, even if their branding is identical.

Manufacturer control can continue beyond delivery

Article 4(5) defines manufacturer control through specified integration, supply and modification relationships, including authorisation or consent to third-party actions. It also includes the manufacturer's ability to supply software updates or upgrades itself or through a third party. That definition directs attention to continuing capabilities and decisions rather than ownership of the physical unit. Outsourcing an update service does not by itself end the manufacturer's control.

The manufacturer control assessment examines those relationships in detail. A product's ability to accept outside software is not the same as the manufacturer consenting to every installation. Evidence should identify what the manufacturer approved, what it could supply and which change allegedly affected safety. Control matters to particular statutory provisions; it is not an independent substitute for proving a defective product and compensable harm.

The safety test applies to the changed product

Article 7 asks whether a product provides the safety people are entitled to expect or that Union or national law requires. Its circumstances include presentation, instructions, reasonably foreseeable use, relevant interconnections, continuing learning or new features, and safety-relevant cybersecurity requirements. The timing of the assessment can also reflect when a product left manufacturer control. These are connected factual questions rather than a pass-or-fail check of whether an update existed.

A newer release does not automatically establish that an older release was defective. Article 7(3) expressly rejects that conclusion based solely on a better product or update becoming available. A speed improvement, interface redesign or optional convenience feature is different from a correction necessary to maintain safety. Equally, an update described as a feature release can contain changes with substantial safety consequences.

Defective releases and missing remedies are different pathways

An affirmative update can change a safety threshold, disrupt a warning or introduce an unsafe interaction between components. The defective update analysis compares the change, the resulting product condition and the mechanism alleged to have caused harm. A release followed by an incident provides chronology, but further evidence is needed to establish causation. Hardware deterioration or an unrelated service change may produce a similar symptom.

A missing update raises another question. Article 11(2)(c) restricts the later-defect exemption where defectiveness results from the absence of updates or upgrades necessary to maintain safety, provided the matter is within manufacturer control. The missing security update framework distinguishes a necessary safety remedy from demand for indefinite improvements. The provision does not create an unlimited obligation to support every product forever.

Cybersecurity needs a link to product safety and damage

A vulnerability report can identify a weakness relevant to safety without showing that an injured person's product was affected or that the weakness caused the reported damage. An investigation needs the relevant versions, operating conditions and credible mechanism. The cybersecurity and defectiveness assessment explains why a severity score, compromise report and compensation claim answer different questions. A successful attack is not the only circumstance potentially relevant to safety, but an allegation still requires a supported factual account.

Article 6 recognises particular damage categories, including personal injury and specified property damage, and destruction or corruption of data not used professionally. Its exclusions also matter. Damage only to the defective product, professional property or commercial data may fall outside this Directive's categories. Loss of confidentiality and data destruction are different events, and other legal routes can have different conditions.

Update delivery and installation require separate evidence

A manufacturer may publish a patch while a particular device never receives it. Delivery can fail because of incompatible dependencies, interruption, access restrictions or an installation choice. An automatic rollout may be staged across models or regions. Record creation, publication, notification, download, installation and activation separately where those stages matter. A dashboard saying a campaign is complete should be checked against the affected product's records.

The effect of a user's failure to install an available safety update depends on the facts and applicable legal provisions. Recital 51 discusses circumstances beyond manufacturer control, including an owner not installing a supplied safety update. That example should not be converted into a blanket defence whenever a device shows an older release. Whether a usable remedy was supplied and whether installation was actually possible remain factual questions.

End of support does not resolve every liability issue

A support deadline is evidence about a product lifecycle decision. It is not automatically the legal moment when all manufacturer control ends. A business may stop routine maintenance while retaining update capability or continuing a related service. Conversely, old software can be unsupported in practice without a documented formal announcement. The actual technical and organisational arrangements need examination alongside communications to users.

The Directive is a compensation framework, while product-safety legislation can impose separate obligations. Do not import another regime's support period without checking product scope, application dates and relevant requirements. Contractual promises can also matter under separate legal routes. A clear end-of-support notice may assist an evidence review without conclusively deciding defectiveness, causation or the availability of an Article 11 exemption.

Build evidence around the alleged causal mechanism

Article 10(1) starts with proof of defectiveness, damage and their causal connection. It then provides specific, rebuttable presumptions subject to their conditions. A safety requirement must protect against the risk of the damage suffered for the Article 10(2)(b) route. An obvious malfunction and excessive technical complexity have their own legal conditions. Neither cybersecurity terminology nor a missing log automatically reverses every proof burden.

The software update evidence checklist organises product identity, release state, control, delivery and harm records around those elements. Article 9 permits relevant disclosure under court supervision and safeguards, rather than unlimited access to all source code. Preserve the difference between contemporaneous records, later reconstruction and unresolved hypotheses. That distinction allows the update history to explain what is known without overstating what the available material proves.

Keep the conclusion proportionate to the evidence

An update investigation can establish several useful facts without establishing every element of liability. It might confirm that a release was installed but leave its causal role unresolved, or establish a safety weakness while the reported loss falls outside this Directive. State those outcomes separately. A precise conclusion identifies the product state, the relevant control relationship, the alleged safety condition and the remaining proof questions, so that the reader can understand both the significance and the limits of the update record.

Records that help the review

Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.

Incident-time product and release state
Update-supply and installation chronology
Safety purpose, control arrangements and covered harm

The existence of a newer update does not itself make an older product defective.

Primary sources and legal scope

This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.