Server-side updates can affect product safety
A SaaS update can change how software behaves without a customer installing a package. Under Directive (EU) 2024/2853, the relevant questions concern the software supplied, the safety effect of the change and the manufacturer's control. A server deployment is neither an automatic exemption from liability nor automatic proof that the updated system is defective.
The SaaS liability framework separates those issues from the subscription model. This article focuses on server-side changes and control evidence. Local installation choices and general update obligations raise additional questions addressed in the broader updates cluster. For SaaS, the difficult practical task is often identifying which changing combination of code, settings and services processed the affected user's request at the incident time.
Establish who could make the relevant change
Article 4(5) includes the manufacturer's integration, interconnection or supply of a component, authorisation or consent to third-party actions, and ability to supply software updates or upgrades. Control is therefore not confined to owning the physical infrastructure. A software producer can deploy through a hosting contractor, and a device manufacturer can authorise a third party to update an associated cloud controller.
Map development, approval and deployment separately. The developer who writes a fix, the business that accepts it and the operator that runs it may be different people. A contractor's administrator credentials can establish technical capability without explaining legal authorisation. Conversely, a manufacturer might authorise changes while lacking access to the cloud console. Contracts, release approvals and operational records should be compared rather than treated as substitutes for one another.
Preserve the deployed state, not just release notes
A release can be enabled gradually, rolled back in one region or restricted to a customer cohort. Record the deployment identifier, affected tenants, feature flags and configuration effective for the relevant request. An application version number alone may not identify the behaviour. A feature flag can activate a new calculation without changing the package installed on the server.
Capture dependencies where they affect the alleged failure. A backend can retain old code while a model, reference table or API contract changes. Scheduled work might process a request hours after it was submitted. A useful chronology therefore distinguishes approval, deployment, activation, request processing and rollback. State which timestamps are directly logged and which are reconstructed from other records, particularly where clocks or retention periods differ.
Understand the later-arising-defect rule
Article 11(1)(c) provides a possible exemption concerning defectiveness absent at the relevant supply time or arising later. Article 11(2) restricts that exemption where specified causes of defectiveness remain within manufacturer control, including software, updates and related services. The rule matters because SaaS producers can continue changing the product after its initial supply. Initial deployment is not the only relevant event.
This does not mean every later software problem establishes liability. The claimant's defect, damage and causation requirements remain, alongside the other applicable provisions and exemptions. Nor does the Directive itself impose a general obligation to provide updates, as recital 51 explains. Duties arising under other product safety or contractual rules require separate analysis. Avoid describing an unlimited duty to operate every cloud feature forever.
Connect the update with a safety issue
Compare the previous and updated behaviour under the conditions relevant to the incident. A change from degrees Celsius to another scale may be harmless if every component handles it consistently. It may be unsafe if the receiving device interprets the number differently. The alleged defect should be described as an identifiable safety shortfall, rather than simply a change followed by a complaint.
Article 7 takes all circumstances into account, including presentation, foreseeable use, interactions and safety-relevant cybersecurity requirements. Article 7(3) also prevents treating a product as defective solely because a better version exists. A remedial release can provide useful evidence about the mechanism without proving that every earlier version was defective. Preserve the reasons for the change and the tests that informed it, including limitations and competing explanations.
Distinguish deployment errors from configuration changes
A failed rollout might leave different components using incompatible versions. Another incident might involve valid code with an unsafe tenant setting. Both can affect safety, but the records and causal theories differ. The detailed treatment of cloud configuration and product defects explains why the same software build can produce different outcomes across accounts without proving that the code changed.
Restoring service should not overwrite the only account of the incident state. Preserve lawful copies of deployment records, settings and relevant logs before they rotate, while allowing necessary safety action. A rollback may remove a suspected cause, but improvement afterwards does not establish causation by itself. Record other simultaneous changes, such as a network recovery or local reset, that could explain the result.
Assess consequences and timing separately
An update that interrupts a business dashboard may raise contractual issues even where no Article 6 damage occurred. Personal injury, certain property damage and destruction or corruption of non-professional data require their own evidence. Lost revenue alone and professional data loss do not become covered merely because a manufacturer controlled the update. Distinguish a dangerous command from a harmless failure safely blocked before reaching a device.
Corrected Article 2(1) concerns products placed on the market or put into service after 8 December 2026. Do not assume that a routine update to an older product automatically changes its first-supply date or resets expiry periods. Product identity, substantial modification and national law may need specific consideration. A documented control and version history supports that assessment while leaving genuine legal uncertainties visible.
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 software, device and deployment identifiers
- Functional dependency and authorisation records
- Original logs with timestamps and recorded limitations
Independent educational information at EU Directive level. National implementing law, product timing 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 2, 4, 6, 7, 8, 10, 11, 21, 22, 17 ↗
- 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.