A connected device fails. At first, it is unclear whether the cause lies in the hardware, a particular software version, a missing security update or a later modification. Engineering, quality and operations now need to establish which product variants are affected, which components were used, which data version was actually programmed and which handovers can still be reconstructed reliably.
The new EU Product Liability Directive 2024/2853 expressly includes software in the definition of a product. This may include operating systems, firmware, applications and AI systems, regardless of whether they are stored on a device, supplied through a network or provided as software as a service.
For manufacturers of connected electronics, the implication is clear: the technically relevant product state is not defined by physical components alone. Software, updates, cybersecurity properties and interaction with connected elements may also matter when assessing whether a product is defective.
What changes for software
The reformed liability framework expressly treats software as a product. This does not mean that every bug or deviation from specification automatically constitutes a defect for product liability purposes. Relevant questions include whether the product provides the safety a person is entitled to expect, whether compensable damage has occurred and whether there is a causal link between the defect and that damage.
In practice, three levels should be distinguished:
- Functional deviation: The product does not operate as specified.
- Safety-relevant defect: The product does not provide the safety that a person is entitled to expect.
- Liability case: A defective product has caused damage covered by the liability framework.
Documentation can help separate these questions from a technical perspective. It does not replace root-cause analysis or legal assessment.
Updates and cybersecurity
The Directive recognises that digital products may continue to change after they have been placed on the market. Software updates, upgrades and related digital services may remain within the manufacturer’s control when supplied by the manufacturer or integrated with its authorisation. A cybersecurity vulnerability may also render a product defective, for example where it fails to meet safety-relevant cybersecurity requirements.
This shifts attention from a single release state to the product lifecycle. Relevant questions may include which software version was approved, which version was actually installed, whether a necessary security update was supplied and which devices or batches were affected.
The Product Liability Directive does not, by itself, establish one general update period for every product. However, failure to provide a security update may affect the liability assessment where software, a related service or the absence of an update is attributable to factors within the manufacturer’s control.
What damage is covered
The new EU framework covers death and personal injury, including medically recognised damage to psychological health, certain damage to property, and destruction or corruption of data not used for professional purposes.
A software malfunction alone therefore does not necessarily create a claim under the Product Liability Directive. Whether a particular loss is covered must be assessed in light of the specific facts and applicable national law.
Who may be affected?
The primary focus remains the manufacturer of the defective product or component. Under certain conditions, other economic operators may also be involved, including importers, authorised representatives, fulfilment service providers or suppliers—particularly where no responsible manufacturer established in the EU can be identified. A party that substantially modifies a product after it has been placed on the market and then makes it available again may also be treated as a manufacturer.
This does not create blanket manufacturer liability for technical service providers. The specific role, agreed scope of service, contractual interfaces and actual influence over the product or process remain decisive. Manufacturer obligations remain with the manufacturer, while information from outsourced component and programming processes may become important for meeting those obligations and investigating a later liability case.
When does the framework apply?
EU Member States must transpose the Directive into national law by 9 December 2026. The new framework applies to products placed on the market or put into service after that date; products supplied before it generally remain subject to the previous regime.
Germany has presented a government bill for a completely revised Product Liability Act. As of 3 October 2026, the parliamentary process has not been completed; following its first reading, the bill was referred to the Committee on Legal Affairs and Consumer Protection.
Companies should therefore verify the German legislative status before publishing legal statements or making implementation decisions. Irrespective of the pending national procedure, the direction of the EU reform is clear: software, digital components, updates and complex value chains are expressly incorporated into the product liability framework.
Evidence matters more
Under certain conditions, the Directive provides for court-ordered disclosure of relevant evidence. It also establishes rebuttable presumptions concerning defectiveness or causation—for example where relevant evidence is not disclosed, mandatory safety requirements have been breached, or technical or scientific complexity makes proof excessively difficult.
This is not a blanket reversal of the burden of proof for every software defect. It does, however, increase the practical importance of reliable product, software and process information. If a company cannot establish the state of a product, it may face greater difficulty distinguishing variants, causes and responsibilities.
The operational question for quality, engineering, procurement and operations is therefore not only: Which data do we store? It is also: Can these data be linked unambiguously to the product, component, version and process step concerned?
Traceability is not enough
A programming log initially answers a retrospective question: what was programmed onto which component, and when? Process integrity addresses a different question: which measures protected firmware, keys, certificates and approved data versions against unauthorised access or modification? Outsourced programming processes should address both perspectives.
This results in two distinct tasks:
- Reconstruct the operation: Link the component, firmware version, approval, time and documented result.
- Protect the operation: Organise access rights, data transfer, processing and deletion so that sensitive data are not unnecessarily exposed or persistently stored in plaintext.
A fully logged process is not automatically secure. Conversely, a protected process should be documented well enough to allow its execution to be reviewed and linked to a specific component or order.
A manufacturing example
A manufacturer is investigating a safety-relevant malfunction in connected control units. Two firmware versions were processed in succession, and initially only one of them is suspected.
The following links would help narrow the issue down quickly:
- Component or device identity
- Batch or packaging unit
- Approved firmware version and unambiguous file reference
- Programming operation actually performed
- Time, order and documented test result
- Subsequent changes or reprogramming
- Delivery and handover history
This information can indicate which devices require further investigation. It does not automatically prove that the firmware was defective or determine the legal responsibility of a particular party.
Keep the CRA separate
The Cyber Resilience Act and the Product Liability Directive touch on similar technical information but serve different purposes. The CRA establishes cybersecurity requirements for products with digital elements, while the Product Liability Directive governs compensation for certain damage caused by defective products.
CRA conformity is therefore not a blanket defence against liability. Conversely, one missing item of information from an upstream process does not automatically establish a product defect. In practice, however, the same data may support different tasks—including technical documentation, vulnerability management, audits, recalls and root-cause analysis.
Organise evidence in advance
Companies should define not only which information is collected, but also how it is linked, protected and made available. Seven questions help when setting up a new project:
- Identification: How are the component, device, batch or packaging unit identified unambiguously?
- Software version: How are the approved file, supplied data version and version actually programmed distinguished?
- Approval: Who is authorised to release firmware or parameters for processing?
- Process integrity: How are firmware, keys and certificates protected during transfer and processing?
- Testing: Which result is recorded after programming, and how is it assigned?
- Changes: How are reprogramming, updates and version changes kept traceable?
- Interfaces: Who supplies which records, how long are they retained and how are deviations escalated?
These points should be addressed early in specifications, quality agreements and technical interfaces. The objective is not a blanket compliance promise, but a defined information chain for the process scope actually performed.
Where btv technologies contributes
btv technologies operates at the interface between component supply, storage, component services and programming. This is where information about material movements, processing steps, firmware versions and device identities is generated—information that often cannot be reconstructed reliably from the finished product alone.
btv TAK® supports the traceability of agreed supply chain information and material movements. For programmed components, btv SEEL® adds protected firmware processing and assigned programming and device-identity data. Its RAM-only approach is designed to avoid persistent plaintext copies in the programming environment, while the audit trail supports the assignment of process steps to the programmed component.
Information from upstream material processes and programming can therefore be brought together for investigations, audits or issue scoping. The data actually available and their retention period depend on the agreed scope of services and defined interfaces.
btv technologies contributes technical traceability and process integrity within its agreed scope. It does not provide immunity from liability or a conformity assessment of the finished product.
Connect your processes
Would you like to organise components, firmware versions and processing steps so that relevant information remains available and attributable when an issue occurs?
Together, we review the interfaces between component supply, storage, component services and programming—and determine which process information makes sense for your production and evidence requirements.
FAQ
Please note: This article reflects the legal and legislative status as of 3 October 2026. The EU Product Liability Directive is in force, but its transposition into German law had not been completed by the editorial deadline. Statements concerning future German product liability law therefore refer to the current draft legislation. This article provides general information and does not constitute legal advice.
