Unsupported Software and Product Liability

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

Unsupported software is a status, not a legal conclusion

Unsupported software may no longer receive routine maintenance, customer assistance or security corrections. It can remain operational, depend on a continuing remote service or have been replaced by a newer branch. Those facts do not all mean the same thing. Product liability asks whether the relevant product was defective, whether covered damage occurred and whether the defect caused that damage. Unsupported status supplies context for those questions.

The post-sale updates framework explains the surrounding provisions of Directive (EU) 2024/2853. Its corrected scope concerns products placed on the market or put into service after 8 December 2026. The national transposition deadline is 9 December 2026. Whether particular old software, a later update or a connected device falls within the applicable regime needs separate analysis rather than a conclusion based solely on age.

Determine which kind of support has ended

A software branch may lack new features but still receive critical corrections. Another may have stopped receiving all releases while a supplier continues answering questions. A component may become unsupported upstream while an integrating manufacturer maintains its own version. Identify the actual product, supplier relationships and maintenance arrangements before calling the whole system unsupported.

Current support status may also differ from the position at the incident time. Preserve dated notices and the relevant version history. A later provider withdrawal does not establish that no support existed earlier, while an eventual extension does not prove that a remedy was available during the disputed period. The chronology should distinguish published policy, operational availability and the product's actual deployed release.

Lack of maintenance does not automatically prove defectiveness

Article 7 asks about expected or legally required safety in all circumstances. Unsupported software may contain an identified safety weakness, or the allegation may concern an unrelated physical or service problem. The inquiry should explain the particular unsafe condition. A general statement that old software is risky does not establish that the affected product lacked the required safety.

Article 7(3) expressly states that a better product, including an update or upgrade, does not alone make the earlier product defective. A newer supported branch may contain convenience improvements rather than a necessary safety correction. Conversely, continuing to support a version does not prove it is safe in every relevant circumstance. Maintenance status and actual defectiveness are connected but different assessments.

Examine the continued product relationship

Article 4(5) includes specified manufacturer actions, authorisation or consent and the ability to supply updates directly or through a third party. An unsupported label does not automatically establish that this capability disappeared. A manufacturer may retain the technical and organisational route to supply a correction even after routine maintenance ends. Identify the actual arrangement and period.

The end-of-support decision analysis addresses the policy and communications behind that status. It is distinct from the present inquiry into the product's condition. A user independently replacing unsupported software also raises different questions from a manufacturer-authorised change. Mere technical compatibility does not establish consent to every outside component, and a current unsupported label does not resolve earlier integration decisions.

Missing necessary safety updates have specific treatment

Article 11(2)(c) restricts the later-defect exemption where defectiveness results from missing updates necessary to maintain safety within manufacturer control. That limitation matters where an operator argues that the relevant condition arose only after supply. It does not dispense with proof of the other claim elements or establish an unlimited obligation under this Directive to provide updates forever.

Separate product-safety legislation and contracts may impose particular support obligations. Their product coverage, dates and conditions must be checked directly. An unsupported product is not automatically outside all legal protection, and a support obligation from one regime should not be imported unchanged into another. The assessment should identify the precise source relied on rather than treating support as a single universal legal category.

Connect the unsupported condition to the harm

Article 10 ordinarily requires defectiveness, covered damage and causation, with conditional rebuttable presumptions. A claim about unsupported software should identify the alleged weakness, the affected component and the mechanism linking it to the incident. If a proposed correction would not have addressed that mechanism, absence of that correction may not explain the reported harm. The causal account needs more than a support-expiry date.

Article 6 recognises personal injury and certain property and non-professional data damage, with exclusions. A product becoming incompatible, losing an online feature or requiring replacement does not automatically produce covered damage under this Directive. Contractual, conformity or other national routes can raise different issues. Describe the actual loss and use of the affected property or data before selecting the relevant legal category.

Evidence should show condition and capability over time

Useful material includes the deployed release, dependency inventory, support notices, identified weaknesses, update availability and continuing service arrangements. Preserve what was known and observed at the relevant time, distinguishing later findings. An advisory published after an incident can inform technical understanding without proving that the affected product had the described condition or that the condition caused the damage.

An evidence review should also identify unavailable material and the party thought to hold it. Article 9 permits relevant, proportionate disclosure subject to judicial safeguards. The aim is a clear account of the unsupported product's actual safety condition and control relationships. That approach avoids treating an administrative maintenance status as either automatic defectiveness or a complete answer to responsibility after supply.

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.

Affected software branch and dependency inventory
Actual supplier maintenance arrangements
Relevant weakness, remedy availability and incident state

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.