For products placed on the market or put into service after 8 December 2026, the new Product Liability Directive can apply to software and digitally connected products. Manufacturers should connect CRA cybersecurity risk, update and vulnerability records to product-liability governance, while keeping the legal tests separate. The CRA asks whether cybersecurity obligations are met; the PLD asks whether a defective product caused compensable damage under its rules.
The CRA and Product Liability Directive Answer Different Legal Questions
The CRA is market-access and lifecycle cybersecurity legislation. Directive (EU) 2024/2853 is a civil-liability directive governing compensation for damage caused by defective products. A company can therefore satisfy a CRA conformity process and still face a product-liability claim if the legal conditions for defectiveness, damage and causation are met.
The New Product Liability Directive Covers Software
Directive (EU) 2024/2853 clarifies that software can be a product for liability purposes, including operating systems, firmware, programs, applications and AI systems. The mode of supply does not itself remove software from the definition, including software accessed through networks, cloud technologies or a software-as-a-service model.
The New Directive Applies to Products Placed on the Market After 8 December 2026
Article 2 states that Directive (EU) 2024/2853 applies to products placed on the market or put into service after 8 December 2026. Products placed earlier remain subject to the previous liability framework. Manufacturers should preserve the market-placement date because the applicable liability regime can depend on it.
Cybersecurity Requirements Can Be Relevant to Defectiveness
When determining whether a product provides the safety that a person is entitled to expect, Article 7 includes relevant product-safety requirements, including safety-relevant cybersecurity requirements, among the circumstances to consider. A CRA requirement can therefore become relevant factual and legal evidence where a cybersecurity weakness contributes to unsafe product behaviour.
CRA Conformity Does Not Create Automatic Product-Liability Immunity
The two regimes use different legal tests. CE marking, a conformity assessment or compliance with CRA controls can be important evidence, but the PLD defectiveness analysis considers all relevant circumstances. Product teams should avoid presenting CRA conformity as a complete liability shield.
Security Updates Can Matter Under Both Regimes
The CRA contains vulnerability-handling and security-update duties. The Product Liability Directive separately provides that an economic operator is not exempted from liability on the basis that a defect arose after market placement where the defectiveness is due to software, related services, a substantial modification or the lack of software updates or upgrades necessary to maintain safety, provided that the matter remains within the manufacturer's control.
The PLD Does Not Itself Create a General Update Obligation
The PLD recitals clarify that the Directive does not itself impose a duty to provide updates or upgrades. The source of an update obligation can instead come from another legal regime, contract or product commitment. For CRA products, Annex I and Article 13 can supply the relevant cybersecurity lifecycle duties.
Manufacturer Control Matters
The PLD keeps certain software, related services and updates within the manufacturer's liability sphere where they remain within the manufacturer's control. The analysis can include software or services supplied or authorised by the manufacturer. This makes product architecture, update ownership and remote-service governance relevant to liability evidence.
Component and Finished-Product Liability Can Coexist
Article 8 can impose liability on the manufacturer of a defective product and, under the Directive's conditions, on the manufacturer of a defective component that caused the product to be defective. CRA supply-chain and SBOM records can therefore be useful when determining which component versions and suppliers were integrated into the affected product.
A Cybersecurity Recall or Regulatory Intervention Can Matter
Article 7 includes recalls and other relevant product-safety interventions by authorities or economic operators among the circumstances that can be considered when assessing defectiveness. CRA market-surveillance actions, vulnerability evidence and corrective measures should therefore be preserved consistently with the company's product-liability record.
Connect CRA Evidence to Liability Readiness Without Merging the Legal Tests
Useful shared evidence includes cybersecurity risk assessments, SBOMs, vulnerability timelines, update decisions, test reports, architecture records, support-period reasoning and corrective actions. Legal teams can reuse those facts for product-liability analysis while keeping the PLD questions of defectiveness, damage, causation and liable economic operator separate from CRA conformity.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.