Firmware Product Liability: Unsafe Control and Evidence

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

Investigate what the firmware controlled

Firmware can be involved in product liability when its behaviour makes a product unsafe and causes damage within the applicable framework. The important inquiry is the function performed by the deployed code: controlling heat, interpreting a sensor, managing a battery or maintaining another protective process. Describing software as firmware does not establish either a defect or a separate immunity from liability.

Directive (EU) 2024/2853 includes software in its product definition, and Recital 13 expressly mentions firmware. The software product liability framework requires the safety, damage and causation questions to be addressed. This guide concerns the investigation of firmware-controlled behaviour. Merely proving that a device contains firmware does not explain why a particular failure occurred or who was responsible for it.

Identify the executable state rather than the marketing version

A product may display a short firmware version while containing several code partitions, a bootloader, configuration memory and calibration tables. Each can affect how the device operates. Record the identifiers available from the product and supplier records, together with the hardware revision and serial number. If an examiner extracts a binary image, document its origin, method and integrity.

The same displayed version may cover different builds or regional configurations. A replacement control board may arrive with another image. Compare the actual installed state with the relevant release package and permitted hardware combinations. An advertised version on a support page is not evidence that it was installed on the product involved in an incident.

Boot and recovery behaviour can explain an event

A failure may occur before ordinary operating logs begin. Startup checks, integrity verification, fallback images and recovery modes can determine whether the product starts safely. A device that repeatedly resets may never reach the routine that records an alarm. Absence of that alarm in the log should therefore be assessed against the logging architecture rather than treated as conclusive evidence that no unsafe condition occurred.

Record whether the product entered a recovery state, lost power during a write or selected a fallback partition. These are technical possibilities to test, not assumptions that every interrupted installation creates liability. The relevant question is how the actual state affected the safety function and whether that behaviour was consistent with the safety a person was entitled to expect under Article 7.

Calibration and units may change safe operation

Firmware often relies on values stored separately from executable code. Sensor offsets, current limits, temperature thresholds and unit conversions may vary between units. A value suitable for one hardware component may be inappropriate for another. Preserve those settings before a factory reset or replacement board erases them, where safe and lawful examination permits.

An inaccurate displayed temperature could be cosmetic or could reveal a control error, depending on how the measurement is used. Follow the value from sensor to calculation to output. Establish whether an independent physical protection existed and whether it operated. The legal assessment needs the complete safety mechanism, rather than a screenshot of an unusual number divorced from product behaviour.

Connect test evidence to the affected hardware

A supplier may have tested firmware against a reference board while the sold device used a different sensor or power stage. Identify the supported combinations, assumptions and any integration changes. A component manufacturer and finished-product manufacturer can have different roles under Article 8. Their development and approval records may help explain where an unsafe interaction arose.

The guide to embedded software investigations describes how to combine physical and digital evidence. For firmware, record test equipment, simulated inputs, timing and protection settings. A passing test under steady conditions may not address a failure arising only during startup, overload or power interruption. Conversely, an artificial test outside foreseeable conditions needs a clear explanation of its relevance.

Preserve installation and servicing history

A release package existing on a vendor server does not establish a completed installation. Keep distribution records, device acknowledgements, installer reports and subsequent verification where available. Document failed attempts and rollback. If a technician later replaced a board, determine whether the repair changed the firmware or configuration before examining the product as though it remained untouched.

Manufacturer control matters under Articles 4 and 11. Authorised integration, modification and the ability to supply updates have particular significance. The Directive does not itself impose a universal update obligation, and this investigation cannot replace research into relevant safety or cybersecurity rules. Record the factual control history before drawing conclusions about responsibility for an unsafe post-supply state.

Distinguish failure from covered damage

A firmware error can disable a product without producing damage covered by Article 6. The property category excludes the defective product itself and also addresses damage caused by an integrated defective component to the containing product. Property used exclusively professionally is excluded. Personal injury or damage to other eligible property requires its own factual and causal account.

Describe who was harmed, what property or data were affected and how the firmware behaviour allegedly led to that harm. A device replacement cost, an injury and lost professional operating data should not be combined indiscriminately. Other legal remedies may be relevant to an unusable device, but their availability does not establish the conditions of this product liability framework.

Handle uncertainty and evidence access explicitly

A damaged controller may no longer reveal its complete incident-time state. Report which information is directly observed, recovered from external records or inferred from comparable units. Do not silently replace a missing original image with the latest public download. Preserve competing explanations, including hardware damage that could have changed the memory after the initial event.

Articles 9 and 10 provide conditional evidence and proof mechanisms, including proportionate court-controlled disclosure and rebuttable presumptions. They do not automatically require public release of all firmware source code. A focused request identifies the release, safety function and records needed to resolve a specific uncertainty. That connection makes technical evidence useful while preserving the distinction between a suspected firmware mechanism and an established legal conclusion.

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.