Missing Security Updates and Product Liability

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

A missing patch is a safety question in context

Missing security updates can be relevant to product liability when their absence leaves a product without the safety people are entitled to expect or that the law requires. The question is not simply whether a newer software release exists. Some releases improve convenience, compatibility or performance without addressing a safety problem. An assessment needs to identify the vulnerability, the affected product function and the safety consequence of leaving that condition unchanged.

The updates and post-sale liability framework explains the surrounding Directive requirements. Directive (EU) 2024/2853, as corrected, applies to products placed on the market or put into service after 8 December 2026. Its national transposition deadline is 9 December 2026. That scope must be checked separately from the date a vulnerability was announced or a particular device stopped receiving releases.

What Article 11 says about necessary updates

Article 11(1)(c) provides an exemption concerning defectiveness that did not exist when the product was supplied or arose afterwards. Article 11(2)(c) limits that exemption where defectiveness is due to a lack of software updates or upgrades necessary to maintain safety, provided the matter is within manufacturer control. Its focus is therefore a specified defence and a necessary safety measure, rather than every improvement customers might request.

The rest of the claim remains relevant. Article 7 governs defectiveness, Article 6 identifies covered damage and Article 10 addresses proof and conditional presumptions. A missing patch does not automatically establish all of those elements. It is also important not to read the limitation on an exemption as a freestanding promise of indefinite updates: Recital 51 expressly states that the Directive does not impose an obligation to provide them.

Explain why the update was necessary for safety

The reasoning should identify the condition requiring correction and what it could do to the product. A vulnerability affecting a safety-critical warning or control function presents a different issue from a cosmetic interface flaw. Evidence can include the vulnerability description, the affected versions, the intended safety mitigation and relevant product-safety requirements. A generic claim that all unpatched software is unsafe does not provide that analysis.

Distinguish available objective knowledge from a manufacturer's particular awareness. An internal discovery date and public disclosure date can differ. Article 11's scientific and technical knowledge exemption has its own terms and must not be reduced to whether an individual employee read an advisory. Likewise, discovery of a weakness does not establish that an effective safety remedy could have been supplied instantly.

Distinguish absence from failed installation

A patch may never have been developed, may have been created but not supplied, or may have been supplied without reaching the affected device. These are different factual scenarios. Publication on a website does not alone prove delivery or installation. The review should establish the relevant channel, compatibility, timing and notices, together with the affected product's actual state.

The security patch assessment examines the remedy itself and its deployment. Recital 51 identifies an owner's failure to install a supplied safety update as an example relevant to matters beyond manufacturer control. That example requires the facts to fit. An unavailable, unusable or repeatedly failing update should not silently be equated with a straightforward decision to reject an effective offered patch.

Establish the continuing control relationship

Article 4(5) includes a manufacturer's relevant authorisation or consent and its ability to supply updates itself or through another business. Update distribution may be outsourced while remaining part of that arrangement. A review should identify who approved the remedy, what supply capability existed and whether the missing measure concerned an authorised component or service.

A support deadline is relevant evidence without automatically ending control. Conversely, a manufacturer's mere technical compatibility with independently supplied software is not consent to every later third-party change. The question concerns the particular software relationship and period. Keeping that analysis specific avoids the opposite errors of treating all post-sale events as excluded or treating the original manufacturer as responsible for every possible installation forever.

Connect the missing remedy to the alleged harm

Article 10 ordinarily requires proof of defectiveness, damage and a causal link. The proposed account should explain how the unremedied condition caused the incident and why the missing update would have addressed that condition. A vulnerability affecting another release, an unrelated intrusion or a harm that the proposed patch could not prevent may weaken that account. Chronology alone does not close those gaps.

The damage category matters as well. Data confidentiality loss, destruction of non-professional data and professional operational losses are distinct consequences under the Directive and other legal regimes. Record the actual harm and applicable exclusions rather than assuming a cybersecurity event produces a compensable product liability loss. A safety concern can be serious even when a particular reported financial consequence falls outside Article 6.

Separate product liability from support obligations

Other legislation, product-safety rules and contracts may impose update or support obligations within their own scope. Those obligations need direct checking for the product and time concerned. A general reference to cybersecurity legislation does not establish an applicable support term. Equally, absence of a contractual promise does not resolve every product safety or liability question under the Directive.

A useful conclusion identifies what is known about the vulnerability, safety necessity, control, update availability and damage mechanism. It also identifies uncertainties, such as an unavailable device log or unresolved compatibility issue. This produces an evidence-based assessment of the missing remedy while preserving the difference between a regulatory support duty, a contractual expectation and the conditions for compensation caused by a defective product.

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.

Identified weakness and safety necessity
Update-supply capability and availability chronology
Evidence linking the missing remedy to the alleged harm

Independent educational information at EU Directive level. National implementing law and procedure require separate review.

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.