Firmware is software embedded in a device
Firmware usually means software stored in or closely associated with hardware and used to control its basic operation. It can manage sensors, communication, power or mechanical actions. The label describes a technical role rather than a separate exclusion from product law. Article 4 of Directive (EU) 2024/2853 expressly includes software within the meaning of product.
The product-classification framework therefore does not depend on firmware being sold in a separate retail package. A device can contain firmware supplied by its manufacturer or integrated from another developer. The device and the firmware can each be relevant products, while the firmware also functions as a component. Identifying that relationship helps organise the investigation without deciding whether any particular failure creates liability.
Distinguish firmware from the hardware storing it
The memory chip containing firmware is a tangible item. The instructions stored on it are software. A corruption event, an incorrect software image and a defective storage chip can lead to similar visible symptoms while raising different factual questions. Record both hardware identifiers and the firmware state rather than treating a circuit board's part number as a complete software identifier.
Some devices report a friendly version label that does not uniquely identify the executable image. Where available, preserve build identifiers, checksums, signed-package information and hardware compatibility details. The purpose is to establish what was actually running at the relevant time. A current support-page download may differ from the firmware originally installed, even if the supplier continues to market the same model name.
Embedded location does not erase separate identity
A firmware component can remain relevant after integration into a finished product. Article 4 recognises products incorporated into or interconnected with other products, and its component definition includes intangible items. Physical inseparability is not the deciding test. Software need not be removable by a consumer to matter in a product liability investigation.
Identify who developed the firmware, who adapted it for the hardware and who approved the final configuration. Those may be different participants. A chip supplier's reference implementation can be changed before production, and a device manufacturer may select particular settings. Preserve the integration trail. It can reveal whether the incident involved the originally supplied code, an authorised revision or a later intervention whose origin remains uncertain.
Firmware and operating systems can overlap
Some firmware performs a narrow control task; other embedded software provides a fuller operating environment for applications. Technical naming practices differ. A supplier might call a package firmware even where it contains an operating system, drivers and application logic. The article on operating systems as products explains that this layered structure does not create a requirement to choose only one relevant software product.
Avoid making the article's classification depend on resolving every terminology dispute. Describe functions, suppliers and integration relationships accurately. A complete firmware package may contain several separately developed components. Conversely, a small update package may alter only a particular subsystem. The legal analysis benefits from that granularity because the alleged unsafe characteristic may concern one layer rather than the entire device software.
Record the relevant supply and integration events
The Directive's definitions distinguish making available, placing on the market and putting into service. Those events relate to commercial activity and are not synonymous with the date a user downloaded a file. Record the device's market history, the firmware's supply history and any later installation. A deployment log can establish what changed without independently proving the legally relevant market-placement event.
The corrected scope covers products placed on the market or put into service after 8 December 2026. Whether a particular firmware release and device fall within the new framework requires attention to that chronology and applicable national law. Do not assume the date of a malfunction automatically brings an older device within the Directive. Later software supply raises questions that need their own analysis.
Product status is distinct from a safety defect
Firmware can be a product even when it operates safely. A fault message, stalled boot or connectivity problem does not alone establish defectiveness under Article 7. Safety expectations, legal requirements and all relevant circumstances must be considered. Article 10 separately addresses defectiveness, damage and the causal connection. Classification answers which items belong in that investigation rather than proving any of those elements.
For detailed responsibility questions, the software product liability guide considers the broader liability framework. Here the key distinction is identifying firmware as software and as a possible component. Preserve evidence that can distinguish software behaviour from physical failure: logs, sensor states, power conditions and configuration can each matter. Neither the presence of firmware nor a suspected bug supports an automatic conclusion about compensation.
Preserve state before routine changes obscure it
Service visits and factory resets can overwrite settings or install a newer firmware image. Record the pre-intervention state where safe and lawful, then document any necessary change. Do not disable safety functions or attempt hazardous downgrades to preserve a hypothesis. A clear chronology of the firmware actually present, the hardware revision and later interventions gives subsequent technical and legal assessment a reliable factual starting point.
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.
- Firmware image identifier and deployment history
- Hardware revision and bootloader information
- Documentation of authorised integration and configuration
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 2, 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.