Maintenance can affect safety without creating unlimited liability
Software maintenance can matter to product liability when changes, compatibility decisions or an unresolved unsafe condition contribute to covered damage. Under Directive (EU) 2024/2853, the relevant questions concern the product's safety, the actual cause of harm, manufacturer control and the applicable exemptions. Maintenance is not a separate rule making every post-release problem the original developer's responsibility forever.
The software product liability framework provides the common conditions. This guide concerns how to investigate the maintained product and its records. Detailed obligations to provide particular safety or cybersecurity updates require their own legal research. The Directive does not itself impose an obligation to provide updates or upgrades, even though certain update and control circumstances affect its liability analysis.
Identify what maintenance actually changed
Maintenance may correct code, replace a dependency, adjust configuration or change the supported environment. A service visit may also replace hardware or calibration. Record each relevant intervention instead of treating a ticket marked maintenance complete as proof of one particular change. The affected product state may differ from both the original supply and the latest documented standard configuration.
Keep the reason for the intervention, the actor performing it, authorisation and the resulting state. If an issue was reported but no change was made, preserve that record separately. A decision to postpone work can have a different evidential meaning from an installation failure or a successful change unrelated to safety. The investigation needs the actual sequence, not a simplified distinction between maintained and unmaintained products.
Distinguish support policy from product safety
An end-of-support notice identifies a business policy or contractual position. It does not automatically decide the safety expected of a product under Article 7 or establish a legal duty to provide support indefinitely. Consider the product's presentation, intended users, foreseeable use, maintenance instructions and relevant safety rules. The effect of an unsupported configuration depends on facts and the applicable legal requirements.
Record what users were told about support duration, compatibility and safe operation after support ends. Determine whether the product depended on a continuing service to perform a protective function. A general notice that new features will stop is not necessarily equivalent to a warning that a safety function will cease. Preserve the actual wording supplied with the product and later communications.
Manufacturer control requires its own factual map
Article 4 defines manufacturer control through specified actions, authorisation or consent and the ability to supply updates or upgrades directly or through another party. A manufacturer can therefore retain relevant control after sale. Outsourcing maintenance does not automatically place an authorised change beyond that control. Equally, an unrelated third party's unauthorised modification needs a different examination.
Article 11(2) limits the later-arising-defect exemption for specified software, related-service, necessary safety-update and substantial-modification circumstances within manufacturer control. Apply its wording to the alleged cause. Do not assume that every remote access feature establishes indefinite control or that ownership passing to a customer ends all control. Preserve authority, capability and actual decisions as separate facts.
Compatibility changes can create new failure paths
A maintained application may run on a changed operating system or use a replaced library. The same release can consequently behave differently over time. Identify the combinations supported, tested and actually deployed. Check whether a component changed its interface, units, timing or default settings. A maintenance record should connect these changes to the function alleged to have failed.
The guide to dependency liability evidence explains how to reconstruct direct and indirect component relationships. Article 7 includes foreseeable interactions with other products expected to be used together. That does not make every unexpected combination a legal defect, but it means compatibility cannot be dismissed as irrelevant solely because the main application's own source code was unchanged.
A later improvement is evidence to assess
Article 7(3) prevents a product being deemed defective solely because a better product, update or upgrade has already or subsequently been supplied. Maintenance releases can therefore indicate improvement without automatically proving earlier defectiveness. Read the underlying issue, test results and affected configurations before using a change as evidence of the alleged unsafe mechanism.
A release described as routine also does not conclusively prove the change was unrelated to safety. Compare the functional difference and its relevance to the incident. If a newer configuration no longer fails, identify all changes between the two states. A repaired product may have different hardware, data and settings as well as software, limiting what a successful post-repair test establishes about the original cause.
Preserve the incident state before routine work obscures it
Where safe and lawful, collect relevant release identifiers, settings, logs and service records before a reset, reinstall or component replacement. If immediate action is needed to prevent further harm, document what was changed and why. Evidence preservation should not require operating an unsafe product or delaying necessary protection. Record the limits imposed by the circumstances.
Maintain a chronology with service dates, activation times and clock context. A technician's arrival time may not be the time new code began running. A scheduled maintenance task may have failed silently. Keep installation outcomes and verification results rather than assuming that a closed ticket proves the intended state was achieved. Identify missing records and distinguish direct observation from inference.
Complete the harm and proof analysis
Article 6 defines covered damage and relevant exclusions, including professional data and exclusively professional property. Maintenance costs, subscription charges or lost business productivity are not automatically covered simply because a software defect is alleged. Identify each harmed person and category, then explain how the particular maintenance state contributed to that outcome.
Article 10 retains proof requirements subject to specified rebuttable presumptions. Article 9 permits relevant court-controlled disclosure under its conditions and safeguards. A focused inquiry might seek an intervention record, affected build or compatibility decision rather than every support communication. The resulting account should connect the maintenance history to one testable failure mechanism and make remaining uncertainty visible, without presenting a support policy or an update date as a complete liability conclusion.
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.
- Maintenance intervention and resulting product state
- Support and safety communications actually supplied
- Authorisation and installer verification
- Compatibility and dependency-change evidence
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.
- Directive (EU) 2024/2853, consolidated text: Articles 4, 6, 7, 8, 9, 10, 11 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.