Embedded Software and Product Liability

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

Embedded code can make the finished product unsafe

Embedded software can raise liability questions when its execution affects the safety of the product in which it operates. Directive (EU) 2024/2853 includes software as a product and recognises intangible components. Article 8 addresses both the manufacturer of a defective finished product and, under specified conditions, the manufacturer of a defective component that caused the product to be defective. A physical enclosure does not erase the software relationship.

The investigation should follow the unsafe behaviour through the system. A sensor value may be processed by code, translated into a control command and applied by a physical actuator. The software product liability framework still requires defectiveness, covered damage and causation. Identifying an embedded program is the beginning of that explanation, rather than proof that every physical failure originated in software.

Reconstruct the functional chain

Start with the event the product was supposed to control or prevent. Identify the inputs available to the software, the processing or decision performed and the output sent to another component. Record protective functions that should have interrupted an unsafe state. This makes it possible to ask whether the alleged failure lies in measurement, computation, communication, physical actuation or their interaction.

An overheating appliance, for example, could involve incorrect temperature conversion, a failed sensor, a stuck relay or a combination. A software log reporting a valid command does not establish that the relay followed it. A damaged relay does not explain whether unsafe commands contributed to its condition. Preserve physical examination and software evidence together so that one discipline's records do not prematurely exclude another explanation.

Match software to the exact hardware revision

Manufacturers may reuse a software name across products with different processors, sensors or circuit boards. The visible consumer model can also remain unchanged while internal components vary. Identify serial number, hardware revision, firmware build, calibration data and any installation-specific configuration. A working sample of the same retail model may not reproduce the affected combination.

Compare the incident product with the tested integration. An outside software supplier may have specified assumptions about input ranges or response times. The finished-product manufacturer may have changed those conditions. Such records help distinguish a component's internal fault from integration failure, but contractual specifications do not replace Article 7's assessment of the product's expected or legally required safety.

Separate component and integrator roles

Article 8(1)(b) concerns a defective component integrated or interconnected within the product manufacturer's control and causing the product to be defective. Article 8 also preserves the finished-product manufacturer's responsibility for damage caused by such a component within its control. A component invoice therefore does not automatically transfer all responsibility away from the product maker.

Identify who developed the embedded software, who selected it, who configured its integration and who presented the final product under a name or trademark. Keep supply and approval records alongside technical records. A development contractor's role may require careful analysis rather than an assumption based on its job title. The relevant manufacturer definitions and actual conduct matter more than internal project labels.

Explain why the behaviour allegedly fell below safety expectations

Article 7 requires consideration of all relevant circumstances, including design, technical features, installation and maintenance instructions, foreseeable use and foreseeable interactions with other products. Embedded software may be invisible to the user while still essential to those expectations. A safety shutdown that silently fails can matter even where the ordinary interface appears functional.

Evidence should identify what the protective function was intended to do and its operating limits. Test whether the trigger condition occurred and whether a backup protection responded. A later safer release is relevant to investigation but does not alone establish that the earlier product was defective. Distinguish improvements from evidence of a particular unsafe mechanism in the incident configuration.

Configuration and dependencies remain part of the product state

An embedded program may load calibration values, optional features or third-party libraries at startup. Those elements can alter its operation without changing the headline firmware version. Record the values actually used rather than relying only on factory defaults. A replacement component installed during servicing may introduce another relevant configuration difference.

The firmware investigation guide develops the boot, calibration and installation evidence needed for this type of incident. For embedded code, a release history should connect the compiled artefact to its hardware target and safety tests. Where source code is examined, identify whether it corresponds to that artefact. A development branch alone may not establish what the affected device executed.

Covered harm and continuing control need separate assessment

Under Article 6, damage to the defective product itself is excluded from the property category. The category also excludes a product damaged by a defective component integrated or interconnected by its manufacturer or within its control. Personal injury or damage to other eligible property can present a different question. Record each item rather than assuming that a broken appliance is itself compensable under this framework.

Later servicing and software changes can matter to control and timing. Article 4 defines manufacturer control, and Article 11(2) limits certain later-arising-defect arguments for specified matters within it. The investigation should record authorisation, rollout and installation, without assuming every later change creates a new product. The corrected new-framework date concerns placement or putting into service after 8 December 2026, with national implementation requiring its own check.

Build a combined technical account

Retain the original product where safe, document interventions and preserve relevant logs before routine repair overwrites them. Establish a common chronology for software events and physical observations, including clock accuracy. Use controlled examination rather than repeatedly energising a potentially unsafe product simply to see whether the event happens again.

Article 10's proof requirements and conditional presumptions apply to the complete account, not just the software portion. Article 9 permits relevant court-controlled evidence disclosure under safeguards. A useful report identifies the alleged unsafe path, alternative explanations, supporting records and unresolved gaps. It explains why the software mattered to the finished product instead of treating code presence as sufficient evidence of responsibility.

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 identity and configuration
Relevant safety assumptions and test evidence
Supply, integration and control chronology

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.

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