Safety can depend on the combination
Product interoperability matters because items that appear safe when examined separately can behave differently together. Article 7(2)(d) of Directive (EU) 2024/2853 requires consideration of reasonably foreseeable effects from other products expected to be used with the product, including through interconnection. The assessment therefore extends beyond the isolated device where the alleged risk depends on a combination.
The expected-safety test still governs. An incompatibility producing inconvenience is not automatically a safety defect. Identify the hazard created by the interaction, such as loss of a protective function or unsafe energy transfer. Then examine whether the combination was reasonably expected and whether the product provided the safety required in that setting. Physical connectivity alone does not resolve those questions.
Identify every relevant part of the system
Record the principal product, connected devices, accessories, cables, components and software versions. Note configuration and operating conditions. Two arrangements with the same commercial product names may differ in a component revision or communication protocol relevant to safety. A current working setup is not necessarily an accurate reproduction of the one involved in the incident.
Distinguish direct interconnection from looser dependence. A component may be integrated into a product; another product may communicate with it; a service may supply data or commands. Their legal treatment can differ. Establishing the technical architecture first helps avoid premature assumptions about what counts as a component, a related service or an independent product under the applicable provisions.
Was use together reasonably expected?
Relevant evidence can include compatibility lists, manufacturer approvals, supplied accessories, common replacement practices and product presentation. An instruction recommending a particular combination may be important. So may an interface designed for routine connection to a class of products. Neither establishes that every accessory or every future version falls within the same expected configuration.
The foreseeable-use analysis helps distinguish realistic combinations from merely possible ones. A combination can be predictable even if not the manufacturer's preferred option, while a technically achievable connection might remain highly unusual. Describe the basis for the expectation. Avoid treating a compatibility logo as a universal safety guarantee or assuming that an unlisted item must have caused the incident.
Identify the interaction mechanism
A useful account explains what each product contributed. For a charging system, this might include negotiated power, protective cut-offs, cable characteristics and battery-management behaviour. For connected controls, it might involve command timing, error handling and loss of communication. The relevant mechanism should be described at a level supported by evidence rather than with an unexplained claim that the products did not work together.
Tests should preserve the incident-time combination as far as reasonably possible and identify deviations. Replacing a cable, updating firmware or changing a network setting may remove the condition under investigation. Record those changes and their potential effect. A test showing that a newer configuration works safely does not necessarily answer what occurred with the earlier combination.
Responsibility follows additional conditions
Article 8 contains specific rules concerning manufacturers of defective products and components integrated or interconnected within manufacturer control. Identifying an interaction does not itself determine which operator is liable. Evidence of who authorised the integration, supplied the component or controlled later changes can be relevant. The technical question of where the fault appeared and the legal question of responsibility should remain distinct.
A product may also be safe in one combination and unsafe in another without every supplier having identical obligations. Do not allocate liability solely by choosing whichever device visibly failed. A damaged component could be the victim of an unsafe command, or a protective system could have failed to respond to another component's fault. The chain of events requires investigation before actors are mapped to the relevant provisions.
Compliance evidence has a defined scope
A test certificate for one product may address performance in a specified environment or with specified accessories. Read its scope, standard and configuration. It is not automatically evidence that every possible integration is safe. Equally, a missing certificate for the combined system does not by itself prove a defect. Identify the applicable mandatory requirement and the safety issue it addresses.
Article 10(2)(b) concerns demonstrated non-compliance with mandatory product-safety requirements intended to protect against the risk of the damage suffered. That condition should not be reduced to a generic documentation complaint. Article 10 otherwise separates defectiveness, damage and causation, with specific presumptions and rebuttal rights. A compatibility problem must be linked to the claimed harm rather than treated as the complete liability analysis.
Keep a configuration history
Preserve installation records, approvals, update dates, accessory replacements and incident-time logs. A timeline can show whether the relevant interaction existed at supply or arose later. It can also identify whether a business retained control over a safety-relevant change. Keep the source for each date and distinguish an installed release from a release merely made available.
The resulting explanation should state the combination, why it was reasonably expected, the alleged unsafe interaction and the evidence connecting it to the damage. Note unresolved configuration gaps and competing causes. This makes interoperability evidence useful without claiming that every failure in a connected system establishes a defective product or a compensation entitlement under the applicable national law.
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 product identity and configuration
- Source documents and dated safety analysis
- Separate defect, damage and causation records
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 7, 10 ↗
- 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.