The related-service definition starts with a product function
A related service under Article 4(3) of Directive (EU) 2024/2853 is a digital service integrated into or interconnected with a product so that its absence would prevent the product from performing one or more functions. A connection to the internet alone does not satisfy this test. Identify the product, the particular function and the dependency that makes the service relevant.
This is the canonical definition for the SaaS and related-services framework. It also covers cloud support and connected-product backend services where they perform that same functional role. Those are often architectural descriptions of the same dependency, rather than independent legal categories. The product does not have to lose every function: dependence of one function can matter, subject to the remaining legal conditions.
Map the backend by what it enables
A backend might authenticate a device, calculate control instructions, store data or maintain a schedule. Describe these activities separately. A service needed for remote temperature regulation has a different connection with a refrigerator from a website displaying advertising about it. Removing either service may change the customer's experience, but only a functional dependency satisfying Article 4(3) establishes the defined related-service relationship.
Recital 17 gives examples including traffic data supporting navigation, sensor-based health monitoring, smart-fridge temperature control and voice assistance controlling products. The examples explain the functional approach without making every analytics feed or voice feature automatically liable. Establish the actual design, claimed function and incident-time operation. Marketing descriptions, technical specifications and controlled dependency tests can each provide different parts of that account.
Distinguish internet access from the product's safety response
Recital 17 excludes internet access services from related-service treatment. A household broadband provider does not become a product component supplier simply because a domestic appliance uses its connection. Record the difference between general connectivity and the product-specific digital functions delivered through that connection. Cloud infrastructure and application services require their own analysis rather than being grouped together under the word internet.
The same recital recognises that a connected product might be defective if it fails to maintain safety when connectivity is lost. These propositions are compatible. An outage in an excluded access service can expose a product design problem without turning the access service into a related service. A heater that cannot receive remote commands still needs a safe response to foreseeable loss of communication; whether its actual response was defective requires evidence.
Establish manufacturer control of integration
Article 4(5) addresses control through integration, interconnection, supply, authorisation or consent, and the ability to supply software updates or upgrades. Recital 18 helps explain the role of third parties. A manufacturer may present a service as part of its product even though another business supplies it. Relevant records include approved integrations, bundled service descriptions, commissioning documents and the release approval process.
Mere technical compatibility, recommending a brand or failing to prohibit an integration should not automatically be treated as consent under that recital. A customer-created connection may therefore raise different issues from a bundled backend selected by the device manufacturer. The integration and control assessment examines those factual distinctions without replacing the threshold related-service definition used here.
Analyse the defect in the connected system
Article 7 requires a safety assessment taking account of all circumstances, including reasonably foreseeable interactions with other products. Map the device, firmware, application, relevant backend and operating conditions as they existed at the incident. A current system diagram may omit a dependency that was retired after the event. Versions and configuration should therefore be attached to the diagram, rather than treated as optional technical detail.
Separate loss of a function from a safety defect. Failure of a decorative lighting feature is different from failure of a safety alarm, even if both depend on a cloud service. If the product's purpose is preventing damage, Article 7 specifically recognises failure to fulfil that purpose as relevant. The alleged unsafe condition must still be connected to the actual harm rather than inferred from a service-status warning alone.
Match the damage and responsible roles
Article 6 covers specified damage categories, with exclusions including the defective product itself, certain damage to an integrated product and property used exclusively professionally. Destruction or corruption of data qualifies only where the data are not used for professional purposes. An unavailable account, lost sales or ordinary subscription refund does not itself establish covered damage. Keep contractual remedies and other national claims distinct from this Directive analysis.
Article 8 addresses the finished-product manufacturer and defective component responsibility, subject to its conditions. The related-service provider is included in the economic-operator definition, but a cloud supplier's name on an invoice is not a complete liability analysis. Identify what it supplied, how that supply fitted the product and what allegedly made the product defective. Contracts can clarify actual responsibilities without conclusively deciding the injured person's statutory rights.
Preserve evidence of absence and fallback behaviour
Record what the product did when the service stopped, including local safeguards, cached instructions, warning messages and recovery. Distinguish an instruction never received from one received late or interpreted incorrectly. Device logs and provider logs may use different clocks, so timing uncertainty must be recorded. Testing should use a safe controlled environment and should preserve the original incident state wherever possible.
A sound account ends with a functional map, a control map and a causal sequence. Those records may support a related-service classification while leaving defectiveness unresolved, or identify a safety defect without proving covered damage. National implementing law, procedure and the corrected temporal scope need separate assessment. Keeping these findings distinct makes the connected-system analysis useful without assuming that every backend failure creates compensation liability.
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 4, 6, 7, 8, 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.