Remote delivery does not remove software from the framework
Software supplied through a cloud or software-as-a-service model can be a product under Directive (EU) 2024/2853. Article 4 expressly includes software, and recital 13 explains that remote access, network delivery and SaaS do not decide against that classification. But neither a subscription nor a cloud connection makes every service feature a product or every interruption a compensable defect.
The practical task is to identify the supplied software, any connected physical product, the relevant digital services and the alleged harm. These elements can exist within one offering while requiring different legal treatment. Start with what happened to the product and the person affected, then map the legal relationships. This avoids treating a broad commercial label such as cloud platform as a complete answer about liability.
Classify the layers of the offering
A SaaS arrangement can combine executable software, stored information, human support, computing infrastructure and a service supporting a device function. Software classification concerns the executable product, not every piece of information appearing on a screen. Recital 13 distinguishes software from information in digital files and mere source code. An incorrect document and an unsafe program managing that document therefore raise different starting questions.
The explanation of whether SaaS can be a product develops this distinction. A browser application may perform calculations on a remote server even though nothing recognisable as a software package is installed locally. Its remote location does not answer whether it is defective. Conversely, a business using software to deliver an ordinary service does not turn every aspect of that service into a software product claim.
Record where the relevant operation occurred and who supplied it. A page shown in the browser may rely on several remote processes and a local device. The same screen can display information from different sources. A useful architecture map identifies the actual input, processing, output and resulting action without assuming the business operating the visible interface supplied every component.
Identify a related service by functional dependence
Article 4(3) defines a related service through digital integration or interconnection with a product whose performance of one or more functions depends on that service. The product need not become wholly unusable. A cloud service can support one defined function while other functions remain local. The connected-product and related-service analysis provides the canonical definition and covers product-specific backends and cloud dependencies together.
Recital 17 illustrates services supporting navigation, sensor-based monitoring, temperature regulation and voice control. The examples do not create a blanket category for all remote analytics or internet services. Establish which function depends on the particular service. An advertising website, optional information feed and authorised cloud controller can have very different relationships with a device even when the customer accesses all three through the same account.
Ordinary internet access is not treated as a related service in that recital. However, a product depending on connectivity can still be defective if it fails to maintain safety when the connection is lost. These points concern different objects: the classification of the access service and the safety of the product's own response. A broadband outage does not automatically establish liability, nor does its exclusion prove the product behaved safely.
Establish manufacturer control beyond the initial supply
Article 4(5) addresses integration, interconnection, supply, authorisation or consent and the ability to supply software updates or upgrades. Cloud deployment often allows a producer to alter behaviour after users begin using the product. The relevant control may operate through a contractor. Owning a physical server is therefore not a necessary substitute for examining who approved and supplied the software or integration.
Recital 18 also sets limits: mere technical compatibility, recommending a brand or not prohibiting an integration does not itself establish consent. Preserve evidence of the actual authorised relationship. Article 11(2) restricts the later-arising-defect exemption for specified matters within manufacturer control, including software and related services. It does not remove the need to establish defectiveness, harm and causation, or create an unlimited promise that every feature will remain available forever.
Separate unsafe operation from ordinary service failure
Article 7 asks whether a product provides the safety a person is entitled to expect or required by law, considering all circumstances. Relevant matters include presentation, foreseeable use, interactions with other products, retained control and safety-relevant cybersecurity requirements. A product whose purpose is preventing damage also requires attention to failure to fulfil that purpose. These are safety questions rather than a general guarantee that software will never contain errors.
An outage might disable a convenience screen without affecting local safety. A delayed command might instead create an unsafe response in connected equipment. The account of service availability failures distinguishes these possibilities. Explain the actual lost function and fallback behaviour. A status page, failed request or customer complaint can support investigation, but none independently establishes the defective condition that caused the alleged harm.
Apply the damage boundaries precisely
Article 6 covers death or personal injury, certain property damage and destruction or corruption of data not used for professional purposes. It excludes damage to the defective product itself, specified damage to an integrated or interconnected product caused by a defective component, and property used exclusively for professional purposes. The data wording is different: data used for professional purposes do not qualify simply because they also have a personal use.
Temporary unavailability of intact files should not automatically be called data corruption. Standalone lost sales, subscription fees and business interruption are not additional Article 6 categories. Material losses resulting from covered harm require a separate analysis. Other contractual, non-contractual and data-protection routes can remain relevant. Their availability does not expand the Directive's categories, and its exclusions should not be presented as eliminating every possible remedy.
Map operators and the causal pathway
Article 8 addresses the relevant manufacturers and other specified economic operators, including conditions for defective component responsibility. The company charging the subscription, the software producer, the device manufacturer and the infrastructure provider may have different roles. Outsourcing does not automatically remove the finished-product manufacturer's potential responsibility, while infrastructure involvement alone does not establish that the hosting provider supplied the defective product or related component.
Trace how the alleged failure produced the harm. A remote controller can receive wrong input, calculate incorrectly, transmit a stale result or send a correct result that the device mishandles. The account of API failures explains why an interface event must be connected to actual execution and physical consequences. Record competing explanations and distinguish observed events from technical inferences about missing steps.
Distinguish a working example from a finding
A domestic appliance may receive remote instructions through software operated by an approved supplier. If a harmful event is reported, investigators would compare the input, remote calculation, transmitted command and local response. They would then establish the damaged interest and the relevant operator roles. The same architecture could produce a harmless interrupted session or a serious safety failure, depending on what occurred. Neither outcome should be inferred solely from the existence of a cloud dependency.
Preserve the incident-time system and applicable scope
Keep build identifiers, deployment times, feature flags, configuration and the relevant service dependency map. A later test of today's application may not reproduce the state involved in the incident. The guide to evidence for cloud-dependent failures explains reconstruction and record provenance. Article 9 provides court-controlled disclosure under stated conditions, while Article 10 begins with proof of defectiveness, damage and causation and adds conditional, rebuttable presumptions.
Corrected Article 2(1) applies the Directive to products placed on the market or put into service after 8 December 2026; Member States must transpose it by 9 December 2026. A later incident or monthly invoice does not itself establish product scope. National implementing law and continuous-supply questions need separate assessment. A mature SaaS investigation therefore ends with distinct findings about the supplied product, dependencies, control, safety, damage and causation, including the questions the available records cannot yet resolve.
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, 9, 10, 11, 21, 22 ↗
- 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.