In the EU product-liability and cyber-resilience context, a software update can raise different questions about product version, evidence and obligations. Whether either framework matters can depend on the product, role, market, date and current rules.
The product entered the market with a versioned file. A later software update changed its behavior, but support, security and quality retained different records. They might no longer have been discussing the same versioned object.
Fact: the PLD and CRA answer different legal questions
Directive (EU) 2024/2853 Article 1 concerns economic-operator liability and compensation for damage to natural persons caused by defective products. Article 2(1) applies it to products placed on the market or put into service after 9 December 2026, a future date on the 22 August 2026 source check. Article 21 retains the preceding directive for earlier products; Article 22 sets the Member-State transposition deadline at the same date. No national implementation was assessed.
In that liability framework, Article 4(1) includes software in “product.” Article 4(5) includes specified update or upgrade supply and ability within manufacturer control. Article 7’s defectiveness analysis includes safety-relevant cybersecurity, manufacturer-control timing and safety interventions, but Article 7(3) says a better later product or update does not alone make an earlier product defective.
Article 11(2) addresses an exemption boundary where defectiveness within manufacturer control is due to a related service, software or updates, a lack of updates necessary to maintain safety, or substantial modification. It is a PLD liability provision, not a universal update-record mandate or a product-specific defect conclusion.
Regulation (EU) 2024/2847 Articles 1–3 establish a separate products-with-digital-elements framework covering specified cybersecurity, vulnerability-handling, economic-operator and market-surveillance rules. Product definition, connection, exclusions, sectoral boundaries, role and market facts remain product-specific.
Article 13 provides bounded manufacturer-record anchors. Paragraphs 3–4 address a documented, appropriately updated cybersecurity risk assessment and technical documentation. Paragraphs 7–9 address relevant cybersecurity information, including known vulnerabilities and third-party information; effective vulnerability handling during the support period; and security-update availability for at least ten years or the remaining support period, whichever is longer. They do not determine a named product’s support period or conformity.
Article 13(21) addresses necessary corrective measures—or withdrawal or recall as appropriate—where a manufacturer knows or has reason to believe a product is non-conforming. Article 54 separately addresses authority evaluation and corrective or restrictive measures for significant cybersecurity risk. Neither provision decides a particular product’s required action or outcome here.
Under Article 71, Chapter IV applied from 11 June 2026. Article 14 applies from 11 September 2026, so its actively exploited vulnerability and severe-incident reporting provisions were not yet applicable on the 22 August 2026 check. General application begins 11 December 2027. Article 69 addresses transition for certain earlier products and substantial modifications. These dates do not establish that a named product, operator, incident or report is within a provision.
Signal: teams no longer describe the same versioned object
Investigate when teams use different version labels; deployment is inferred from release intent; PLD liability language is used as CRA conformity language; Article 14 is treated as already applicable before its staged date; or the product file stays static after a material change.
Counter-signals include stable identifiers, dated inputs, separated fact and inference fields, an explicit Not assessed state, contrary evidence, accountable owners and a review trigger. They improve traceability. They do not prove safety, conformity or freedom from liability.
Action: preserve the versioned change and decision boundary
PARAVEILUX inference. A versioned update record can connect product, software and version identifiers; the update rationale and dated evidence considered; deployment or market facts known, assumed or not assessed; contrary evidence, unresolved issues and owners; and the event requiring another cross-functional review.
Preserve what was known at each decision point. If later evidence changes the assessment, append the change instead of rewriting the earlier entry as though the later fact had always been known.
The hidden variable is whether the product file traces the versioned change and its evidence. The owner’s useful question is whether qualified product, quality, security and legal specialists can reconstruct the version, inputs, assumptions and unknowns before the decision-makers.
Owner Q&A
Does every update require the same legal or technical treatment?
No universal conclusion is supported. The answer depends on product, role, market, change, date and evidence facts selected by specialists.
Does a complete version record prove safety or conformity?
No. It can preserve decision inputs and unknowns. Safety, defect, conformity and liability require separate factual and legal analysis.
Next verification
Ask whether the exact product, software version, market, operator role, product date, support period and change are recorded consistently. Keep PLD questions separate from CRA questions, and check the current EU texts, national implementation and technical evidence before drawing a product-specific conclusion.
Limitations: a versioned record does not establish the legal outcome
This analysis does not assess product or remote-service scope, sectoral exclusions, economic-operator role, manufacturer control, support period, substantial modification, market placement, national implementation, safety, cybersecurity, defect, non-conformity, causation, compensation, liability, reportability, withdrawal, recall, penalty, deployment impact or technical adequacy. Every such outcome remains Not assessed.
This is general risk education, not professional or certified advice. The sources describe bounded EU product-liability and cyber-resilience contexts; whether either applies or a comparable issue can arise for you depends on current rules, product, role, market, date, change and evidence.