The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) and the revised Product Liability Directive (PLD, Directive (EU) 2024/2853) became law in 2024 within months of each other. Both target software-bearing products. Both impose new manufacturer obligations. But they operate through entirely different mechanisms — one regulatory, one civil-liability — and software manufacturers must satisfy both. This article maps the overlap, the gaps, and the practical compliance interaction.
CRA and PLD: Two Mechanisms, Same Products
The CRA is a regulation: directly applicable in every EU member state, enforced through market surveillance, with fines up to 2.5 % of global annual revenue or €15 million for non-compliance. The CRA tells manufacturers what cybersecurity outcome a product with digital elements must achieve before being placed on the EU market.
The revised PLD is a directive: requires transposition into national law by each member state, enforced through civil court claims, with no upper cap on damages. The PLD tells consumers and downstream users what they can sue for when a defective product causes damage — and the new PLD explicitly includes software as a product, and explicitly includes cybersecurity vulnerabilities as a kind of defect.
A single connected product — a smart thermostat, an industrial controller, a wearable medical accessory — falls under both at once. CRA compliance does not immunize against PLD claims; PLD diligence does not produce CRA conformity.
What Each Law Demands
| Dimension | CRA | PLD (revised, 2024/2853) |
|---|---|---|
| Legal form | Regulation (directly applicable) | Directive (national transposition) |
| Enforcement | Market surveillance, regulatory fines | Civil liability, court damages |
| Product scope | Products with digital elements | All products including standalone software |
| Defect concept | Non-compliance with Annex I requirements | Lack of safety a reasonable person would expect |
| Manufacturer duty | Conformity assessment, SBOM, vulnerability handling, support period | Strict liability for damage caused by a defective product |
| Penalty | Up to €15M / 2.5% global revenue | Unlimited civil damages |
| Effective date | Full compliance December 11, 2027 | Member state transposition by December 9, 2026 |
Where They Overlap: Cybersecurity Defects
The most important interaction point is the PLD's treatment of cybersecurity vulnerabilities. Under the revised PLD, a product is "defective" when it lacks the safety a reasonable person would expect — and the directive explicitly names cybersecurity vulnerabilities and missing security updates as factors in this assessment.
This creates a feedback loop with the CRA. The CRA defines what cybersecurity outcomes a product must achieve under Annex I. A product that fails to meet those outcomes is non-compliant under the CRA — and very likely "defective" under the PLD. The CRA conformity assessment becomes evidence that bears directly on PLD liability defense.
The reverse is also true. If a court finds a product PLD-defective because of a cybersecurity vulnerability, that finding strongly suggests the manufacturer failed CRA obligations: insufficient vulnerability handling, missed updates within the support period, or failure to communicate the vulnerability to affected users.
Where They Diverge: Damage vs. Compliance
The CRA is a compliance regime. Failing the CRA produces regulatory penalties, market access loss, and product recalls. CRA enforcement does not address compensation to harmed users.
The PLD is a damage regime. The PLD allows compensation claims for material damage to persons or property — and the revised PLD adds damages for data loss and damages from non-material harm where national law permits. CRA compliance does not satisfy these damage claims; CRA compliance only reduces the probability of triggering them.
This means a manufacturer must address both: CRA processes prevent the regulatory penalty, PLD processes (warranty, insurance, vulnerability disclosure, post-market surveillance) prepare for the civil damage scenario.
The 10-Year Limitation Window
The PLD extends manufacturer liability for ten years after the product is placed on the market — and for products with digital elements where the manufacturer is obligated to provide security updates, the period restarts from each substantial modification. This 10-year window aligns intentionally with the CRA's support-period obligation. Manufacturers cannot end their CRA support obligations in year 5 and assume PLD liability ends with the warranty: PLD claims can arise long after the product is sold.
The practical implication: the SBOMs, the vulnerability handling logs, and the conformity documentation generated for CRA purposes also serve as PLD defense evidence over the same ten-year horizon. Retain everything for ten years; the two regimes share the retention requirement.
What Software-as-a-Product Means Under the PLD
The revised PLD removes the historical ambiguity about whether software is a "product." It explicitly is, including:
- Embedded software in physical products
- Standalone application software
- Operating systems
- AI systems
This brings pure SaaS providers and software publishers into PLD scope — even where the CRA's exemptions for software-as-a-service may apply. A SaaS provider exempted from CRA conformity assessment is still liable under the PLD if a software defect causes harm. Open-source software remains generally excluded, but commercial use of open-source components transfers liability to the commercial distributor.
For dual-targeted products (those subject to both CRA and PLD), the CRA's SBOM obligation does double duty: it documents the software composition for CRA evidence, and it documents the supplier chain for PLD recourse claims when a defective component causes harm.
Practical Implications for Manufacturers
Three compliance behaviors satisfy both regimes:
Treat CRA conformity documentation as PLD defense evidence. The technical documentation, SBOM, risk assessment, and vulnerability handling logs that the CRA requires are precisely what a manufacturer needs to demonstrate non-defectiveness in a PLD claim. Build the documentation once; use it for both purposes.
Extend the support period beyond the marketing-driven minimum. The CRA requires a declared support period. Choosing a short support period to reduce CRA workload increases PLD exposure — products without security updates beyond the support period are more easily characterized as defective. The economically optimal support period considers both CRA cost and PLD liability.
Treat vulnerability handling as the unified compliance lever. A robust vulnerability handling process reduces CRA non-compliance risk (ENISA notification, customer communication, security update delivery) and PLD damage risk (early mitigation reduces realized harm) simultaneously. It is the single highest-leverage practice across both regimes.
How Kunnus Handles the CRA-PLD Overlap
Kunnus is built around the structured-data layer that both regimes require. The product catalog, SBOM aggregation, vulnerability monitoring, support-period tracking, and audit-ready documentation all serve double duty: CRA conformity evidence and PLD defense evidence in the same place, retained for ten years by default.
For manufacturers facing both regimes — which is most manufacturers of connected products — Kunnus consolidates the compliance and the liability-defense workflow.
Start with our CRA readiness assessment, or explore the platform to see how the dual CRA-PLD evidence model is structured.