When a Digital Service Becomes Part of a Product

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

Integration is a factual relationship, not a label

A digital service can become relevant to a product's liability assessment when it is integrated into or interconnected with that product and supports a function in the way Article 4(3) describes. Establishing the relationship requires more than finding the same brand on two websites. It calls for evidence about product design, service dependence and the manufacturer's involvement in the connection.

The related-service definition supplies the threshold functional test. This article addresses the next practical question: what records demonstrate that relationship and the relevant control? The SaaS and cloud services framework explains the wider liability sequence. Integration may establish a component relationship while leaving defectiveness, harm and causation entirely open. Those are separate findings, not automatic consequences of classification.

Start with the function the customer receives

Describe the relevant function precisely. A device may run locally but require a remote service for an advertised monitoring function. Another may use a server only to display optional marketing content. Ask what the product is intended to do, what it actually does without the service and whether the absent service prevents at least one function. Avoid substituting broad descriptions such as connected or smart for the dependency evidence.

Product specifications, manuals, commissioning records and the interface shown at purchase can help explain the design. They may conflict with later documentation. Preserve the version relevant to the product and supply date. A service that became optional after a redesign might have been necessary for the earlier model, and a service described as included might require technical activation before it supports any function at all.

Identify who authorised the connection

Article 4(5) defines manufacturer's control through specified conduct and capabilities. Relevant actions include integrating, interconnecting or supplying a component, or authorising or consenting to a third party doing so. The ability to supply software updates or upgrades is also part of the definition. Record the actual actor and action rather than assuming that whoever owns the server controls every connected product.

An integration approval, supplier acceptance test or bundled account-activation process can be evidence. A contract may show that a device manufacturer selected a backend operator and approved the interface. Technical records may show something different, such as a customer adding an unsupported automation. The legal inquiry needs the underlying conduct. A supplier's internal description of itself as merely a service business does not settle the statutory classification.

Do not confuse compatibility with consent

Recital 18 explains that technical ability to connect, recommending certain brands or failing to prohibit potential services is not enough by itself to establish consent. That distinction matters for open interfaces. A manufacturer may publish an interface usable by many developers without approving every application later built around it. Identify the further evidence, if any, showing consent to the particular integration being investigated.

Conversely, outsourced delivery does not necessarily place a bundled service outside manufacturer control. The manufacturer may present it as part of the product, authorise deployment and retain update capabilities. A white-label arrangement can conceal these facts from the customer. Preserve packaging, onboarding screens and approved partner descriptions alongside technical records so the assessment reflects both the product's presentation and the actual supply relationship.

Track how the relationship changes over time

A product can move from an original provider to a replacement backend, receive a new integration or lose a previously supplied function. Record the dates, approvals and device groups involved. A supplier change without a visible hardware change may affect the control map. It does not automatically prove a substantial modification or create a new product for every purpose under the Directive.

Article 11(2) restricts the later-arising-defect exemption for specified matters, including related services and software within manufacturer control. That makes the incident-time integration relevant even where the device was supplied earlier. The provision is not a promise of indefinite functionality or a general obligation to provide every update. It needs to be read with the alleged safety defect, the control evidence and other applicable product rules.

Test the causal role of the integration

Suppose a manufacturer authorises a remote service to calculate commands for a domestic ventilation unit. An unsafe command might originate in a faulty calculation, a unit-conversion mismatch or a local interpretation error. The approved integration establishes a relationship, but it does not select among those causes. Trace the actual input, output, transfer and physical response, identifying the records supporting each step.

A correctly functioning service can also interact with an unsafe product design. An expired response might be safe to reject but dangerous to reuse indefinitely. Article 7's all-circumstances safety assessment and attention to foreseeable interactions help frame that inquiry. Do not assume that the party suffering the first technical outage supplied the legally defective element. The downstream handling may be the more significant safety issue.

Keep integration findings within their limits

A concluded assessment should state the product function, the service dependency, the evidence of authorisation and the time period covered. It should also state unresolved issues. A functional dependency does not establish compensable damage, and a service contract does not itself establish who owes compensation. Article 6 and Article 8 impose their own boundaries, while Article 10 addresses proof and conditional presumptions.

Pure financial losses from a failed integration, professional data loss and temporary loss of access should not be described as automatically covered. Corrected product-date scope and national implementing law also need separate consideration. The integration map is valuable because it identifies what must be investigated next. Its purpose is to support a transparent legal and technical account, without converting every approved digital connection into a successful liability claim.

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.

Original Official Journal Directive: recitals 17, 18 and 50 read with the Article references above ↗

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.