The EU Product Liability Directive 2024/2853: What Romanian Software Businesses Need to Know

Directive (EU) 2024/2853 materially expands and modernises the European strict-liability regime for defective products, expressly bringing software within the definition of a “product.” Adopted on 23 October 2024, published in the Official Journal on 18 November 2024 and in force since 8 December 2024, the Directive repeals and replaces Council Directive 85/374/EEC for products placed on the market or put into service after 8 December 2026. Member States must transpose it by 9 December 2026.

For Romanian technology companies—from SaaS providers and embedded-software developers to AI businesses—the practical consequences justify preparation before the Romanian implementing legislation is final. That preparation should nevertheless be described accurately: the Directive harmonises civil-liability rules and is addressed to Member States; it is not, by itself, a general product-safety licensing regime or a freestanding source of administrative compliance obligations for businesses before transposition. The precise Romanian causes of action, procedural mechanisms and interaction with existing Law No. 240/2004 will depend on the national implementing measure.

The principal changes relevant to technology businesses are the express inclusion of software, the treatment of certain developers and providers as manufacturers, the recognition of post-market control and cybersecurity in the defect analysis, broader—but still delimited—categories of compensable damage, new evidence-disclosure mechanisms and rebuttable presumptions intended to address technical complexity.

What Directive (EU) 2024/2853 Means for Software

Legislative basis and objective

Directive (EU) 2024/2853 was adopted under the ordinary legislative procedure (procedure 2022/0302(COD)), on the basis of Article 114 TFEU. Its purpose is to modernise the harmonised rules governing no-fault liability for defective products, particularly in light of digital technologies, artificial intelligence, circular-economy business models and global supply chains.

The Directive preserves the essential structure of the earlier regime: an injured natural person must, in principle, establish a defective product, recoverable damage and a causal link between the defect and that damage. The reform does not create strict product liability for the first time. Rather, it extends and adapts the existing regime, including by broadening the product definition, identifying additional potentially liable economic operators and easing specified evidentiary difficulties.

Software, AI systems and digital manufacturing files

Article 4(1) defines a product as any movable, even if integrated into or interconnected with another movable or an immovable, and expressly includes electricity, digital manufacturing files, raw materials and software. Recital 13 clarifies that software may fall within the regime irrespective of how it is supplied or used, including where it is accessed through a communications network, cloud technologies or a software-as-a-service model. Operating systems, firmware, applications and AI systems may therefore qualify as software products, whether stand-alone or embedded.

This does not mean that every digital output is a product. Information as such—including the content of media files, e-books or the mere source code viewed as information—is not treated as a product. A digital manufacturing file is covered because it contains the functional information necessary to produce a tangible item through automated control of machinery or tools.

Free and open-source software is excluded under Article 2(2) only where it is developed or supplied outside the course of a commercial activity. The analysis is therefore contextual. Recital 14 indicates, among other matters, that supply in exchange for a price, or for personal data used for purposes other than exclusively improving the software’s security, compatibility or interoperability, may place the activity within the commercial sphere. It would be too broad to state that every open-source component used somewhere in a commercial product automatically exposes every contributor to liability. However, a manufacturer that integrates an open-source component into its own product may remain responsible for the resulting product, subject to the Directive’s rules on components, control, defences and recourse.

Timeline and Romanian transposition

The Directive entered into force on 8 December 2024. Article 22 requires Member States to adopt the necessary implementing provisions by 9 December 2026 and to apply them from that date. Following the corrigendum published on 7 May 2026, Article 2(1) states that the Directive applies to products placed on the market or put into service after 8 December 2026. Directive 85/374/EEC continues to govern products placed on the market or put into service before 9 December 2026.

As at 10 August 2026, the EUR-Lex national-transposition page consulted for Directive 2024/2853 did not identify a Romanian transposition measure, and the official Romanian sources reviewed did not allow us to confirm that a final implementing act had been published. This is a dated status statement, not a prediction; it should be rechecked immediately before publication and whenever concrete advice is given.

Romanian businesses should therefore prepare against the enacted EU framework while preserving room to adjust their processes and contractual drafting to the final Romanian legislation. It is not legally precise to say that businesses must comply with the Directive “regardless of national legislative progress,” since a directive requires national transposition and does not ordinarily impose horizontal obligations on private parties merely by the expiry of the transposition period.

Defectiveness in the Context of Software and AI

The applicable test

Under Article 7, a product is defective where it does not provide the safety that a person is entitled to expect or that is required under Union or national law. The court must assess all relevant circumstances, including the product’s presentation and characteristics, reasonably foreseeable use, the effect of any ability to continue learning or acquire new features, interaction with other products, relevant product-safety and cybersecurity requirements, recalls or other interventions by competent authorities and the specific needs of the user group for which the product is intended.

The fact that a better product is later placed on the market does not, by itself, make the earlier product defective. Similarly, an adverse outcome, software error or cyber incident does not automatically establish defectiveness. The legal analysis remains fact-specific and must connect the alleged deficiency to the level of safety that was legitimately expected or legally required.

Cybersecurity, updates and learning systems

Cybersecurity vulnerabilities and the failure to supply security updates or upgrades necessary to address vulnerabilities may be relevant to defectiveness, particularly while the software remains within the manufacturer’s control. The Directive does not, however, establish a universal patching deadline or support period for every software product. Those periods must be derived from applicable product-safety legislation, contractual commitments, the product’s presentation, foreseeable use, risk profile and other circumstances under Article 7.

The following scenarios illustrate issues that may require a defect analysis; they are not findings that defectiveness exists automatically:

• Known cybersecurity vulnerability. A connected medical device is supplied with an unremediated vulnerability that is exploited and causes an unsafe dosage. The relevant questions include the state of knowledge, applicable safety requirements, the product’s presentation, the manufacturer’s control and whether the vulnerability caused recoverable damage.

• Failure to provide a necessary security update. An IoT platform remains in reasonably foreseeable use after update support has ended and a later exploit causes qualifying damage. The court would assess whether the update was necessary to provide the safety a person was entitled to expect and whether the manufacturer retained control.

• Deficient AI training or validation. Training data, validation methods or model limitations may contribute to an unsafe output. Discrimination or an incorrect commercial decision, standing alone, is not necessarily “damage” compensable under this Directive; other regimes, including anti-discrimination, consumer-protection, data-protection or AI legislation, may be more directly relevant.

• Post-deployment learning. A learning system changes after deployment and contributes to a collision or other safety event. Article 7 expressly permits the court to consider the effect of the ability to continue learning or acquire new features.

Where the manufacturer retains control after the product is placed on the market or put into service, Article 7(2)(e) allows the assessment to take account of the later moment when the product leaves that control. This is not identical to a rule that defectiveness is always assessed at the date of damage. The practical implication is nevertheless significant: businesses should maintain proportionate, reliable records of versions, updates, support decisions, security assessments and material model changes throughout the period in which they control the product.

Who May Be Held Liable

No-fault liability and the claimant’s case

Liability under the Directive is no-fault liability: the injured person does not have to prove negligence or intent. In principle, however, Article 10(1) still requires the claimant to prove defectiveness, recoverable damage and causation, subject to the rebuttable presumptions discussed below. Reasonable care and compliance evidence may therefore remain important to contest defectiveness or causation, even though diligence is not a complete defence once all liability conditions are established.

Manufacturers, component manufacturers and other economic operators

Article 8 identifies the manufacturer of the defective product and, in appropriate circumstances, the manufacturer of a defective component integrated or interconnected within the product manufacturer’s control. For software, the definition of manufacturer includes a person that develops or produces the product, has it designed or manufactured and presents itself as manufacturer through its name or trademark, or develops it for its own use. Recital 13 confirms that software developers and producers, including AI-system providers within the meaning of the AI Act, should be treated as manufacturers.

Where the relevant product or component manufacturer is established outside the Union, Article 8 may extend liability, subject to its precise conditions, to the importer and the manufacturer’s authorised representative; a fulfilment service provider may be liable where no relevant manufacturer, importer or authorised representative established in the Union can be identified. A fulfilment service provider is defined by reference to combinations of warehousing, packaging, addressing and dispatching services, and this route should not be used as a generic description of ordinary SaaS or cloud hosting.

Distributors may become liable if the relevant EU-based economic operator or their own distributor is not identified within the one-month period following the prescribed request. Online-platform providers may also be liable where the conditions in Article 8(4), read with Article 6(3) of the Digital Services Act, are met—for example, where the presentation would lead an average consumer to believe that the product is provided by the platform itself or by a trader acting under its authority or control, and the required identification is not supplied.

The Directive does not generally require every non-EU software manufacturer to appoint an authorised representative. It provides for the representative’s potential liability where one has been appointed. Whether an appointment is required must be determined under the applicable product-safety or sector-specific legislation. Romanian businesses should therefore map the actual Article 8 chain instead of assuming that an authorised representative is always mandatory.

Supply-chain implications

Romanian companies that develop, integrate, rebrand, import or distribute software should identify which role they perform for each product. A company marketing an integrated product under its own name may qualify as its manufacturer; a component developer may have separate exposure; and a person making a substantial modification outside the original manufacturer’s control may be treated as a manufacturer where the modification causes the defect.

Contractual indemnities, information-sharing provisions and recourse rights remain important between supply-chain participants, but they do not prevent an injured person from invoking the non-excludable rights implemented under the Directive.

Recoverable Damage and Its Limits

Article 6 covers:

• death or personal injury, including medically recognised damage to psychological health;

• damage to or destruction of property other than the defective product itself, except property used exclusively for professional purposes; and

• destruction or corruption of data not used for professional purposes.

The former EUR 500 lower threshold for property damage is not retained. Compensation covers material losses resulting from the listed damage and, where national law permits, non-material losses resulting from that damage.

The expansion remains bounded. Pure economic loss, loss of profit, discrimination as such, a privacy infringement without qualifying destruction or corruption of data, and damage to property used exclusively for professional purposes do not by themselves fall within Article 6. The same factual event may, of course, engage other causes of action under national contract or tort law, the GDPR, consumer law, anti-discrimination law, sectoral product-safety rules or the AI Act.

Data-loss valuation will require careful evidence. Relevant matters may include restoration costs, the purpose and uniqueness of the data, available backups and resulting material or compensable non-material loss under Romanian law. It would be unsafe to assume that every exposed, inaccessible or inaccurately processed dataset is “destroyed or corrupted,” or that every adverse AI decision produces damage covered by the Directive.

Evidence Disclosure and Rebuttable Presumptions

Disclosure under Article 9

Article 9 requires Member States to provide a disclosure mechanism in national proceedings. A claimant who presents facts and evidence sufficient to support the plausibility of the compensation claim may request relevant evidence in the defendant’s control. A defendant may likewise seek relevant evidence from the claimant where it demonstrates the need for that evidence to contest the claim.

Disclosure is not automatic and is not unlimited. It must be necessary and proportionate under national law. Courts must consider the legitimate interests of all parties and third parties, particularly the protection of confidential information and trade secrets, and must be able to impose protective measures. The Directive does not state that source code, entire training datasets or every cybersecurity record must be disclosed in every case. Their disclosure depends on relevance, necessity, proportionality and the protections applied by the court.

Presumptions under Article 10

Defectiveness is rebuttably presumed where the defendant fails to comply with an Article 9 disclosure obligation, where the claimant demonstrates non-compliance with mandatory product-safety requirements intended to protect against the risk that materialised, or where the claimant demonstrates that the damage was caused by an obvious malfunction during reasonably foreseeable use or under ordinary circumstances.

Causation is presumed where defectiveness has been established and the damage is of a kind typically consistent with the defect. In addition, where technical or scientific complexity creates excessive difficulties of proof, a court may presume defectiveness, causation or both if the claimant demonstrates the likelihood required by Article 10(4). Technical complexity alone does not eliminate the claimant’s burden or create automatic liability, and each presumption remains rebuttable.

Records and litigation readiness

A proportionate records and legal-hold framework may include:

• release, version, update and patch records;

• vulnerability reports, security decisions and remediation timelines;

• risk assessments, testing and validation records;

• material AI model, dataset and configuration lineage, subject to data-protection, confidentiality and retention constraints;

• change-control and design-decision records;

• product presentation, instructions, support periods and customer notices; and

• records identifying relevant manufacturers, component suppliers, importers, distributors and other economic operators.

Records should not be retained indiscriminately. The retention schedule should reconcile litigation risk and applicable limitation or expiry periods with GDPR data-minimisation and storage-limitation duties, trade-secret controls, contractual obligations and sector-specific requirements. A litigation hold should suspend ordinary deletion for information relevant to an actual or reasonably anticipated dispute.

Contracts, Warranties and Insurance

What contracts cannot achieve

Article 15 requires Member States to ensure that liability toward the injured person is not limited or excluded by contractual provision or national law. An end-user waiver, disclaimer or liability cap cannot therefore be relied upon to remove the statutory rights established by the national law transposing the Directive.

This does not make commercial drafting irrelevant. Contracts may allocate responsibilities, establish information and cooperation duties, define update and support commitments and regulate recourse between economic operators, subject to Article 14, Article 12(2), national law and any other mandatory rules.

Illustrative drafting points

The following are negotiation starting points, not statutory clauses or safe harbours:

• Defect and claims cooperation: require prompt notice of suspected safety defects, preservation of relevant evidence, technical cooperation and coordinated responses to claims or authority requests.

• Updates and vulnerability handling: define severity criteria, triage and remediation periods, support duration, customer dependencies and the process for emergency updates. The chosen periods should be justified by applicable law and product risk rather than presented as periods prescribed by the Directive.

• Supply-chain information: require the supplier to maintain and provide accurate information identifying relevant component manufacturers and other economic operators, and to notify material changes.

• Indemnity and recourse: allocate losses attributable to a party’s defective component or breach, with carefully drafted causation, control-of-defence, mitigation, exclusions and insurance provisions. Enforceability and the restrictions applicable to recourse agreements must be checked under the transposing law.

• Authorised-representative information: where an authorised representative is required by another applicable EU product regime or has in fact been appointed, require its identity and mandate details. Do not use the Directive as the sole basis for a universal appointment obligation.

• Insurance: require evidence of appropriate product-liability, technology-errors-and-omissions, cyber or other coverage where justified. Coverage for software, data loss, psychological harm, cyber events, defence costs and cross-border claims should be confirmed from the actual policy wording; it should not be assumed.

Practical Preparation Checklist for Romanian Businesses

The following measures are risk-management recommendations rather than direct administrative duties created by the Directive itself:

1. Map the product portfolio. Identify stand-alone and embedded software, AI systems, digital manufacturing files and relevant components, and record how and when each is placed on the market or put into service.

2. Classify each economic-operator role. Determine who is the product manufacturer, component manufacturer, importer, authorised representative (if any), fulfilment service provider, distributor or relevant online platform.

3. Review safety and lifecycle controls. Align development, testing, cybersecurity, update, end-of-support and post-market monitoring processes with applicable product-safety legislation and the Article 7 factors.

4. Build proportionate evidence governance. Preserve the records needed to explain product versions, risk decisions, updates, model changes and supply-chain relationships, without disregarding GDPR and confidentiality constraints.

5. Review contracts. Address component quality, product-safety responsibilities, update support, incident and claim cooperation, evidence preservation, information duties, indemnities and recourse.

6. Review insurance. Obtain a written coverage analysis for software and AI risks, covered damage categories, cyber exclusions, territorial scope, aggregation, defence costs and notification requirements.

7. Prepare a claims protocol. Establish responsibility for technical investigation, evidence preservation, claimant or authority communications, insurer notification and coordinated supply-chain response.

8. Monitor Romanian transposition. Compare the final national law with existing Law No. 240/2004, particularly as regards procedure, disclosure, limitation, recoverable non-material loss and transitional treatment.

Legislative Timeline

Conclusion

Directive (EU) 2024/2853 materially changes the product-liability exposure of software and AI businesses, but its effect should not be overstated. It preserves no-fault product liability rather than inventing it, expressly includes software irrespective of its supply model, broadens the potential defendant pool, recognises defined new categories of damage and introduces disclosure and rebuttable presumptions calibrated to evidentiary difficulty.

For Romanian technology companies, the appropriate immediate response is not a claim of present “compliance” with an untransposed directive, but a documented readiness programme capable of being adjusted to the final national law. Product mapping, role classification, lifecycle safety, evidence governance, contractual recourse and insurance analysis are the core workstreams.

Last reviewed: 10 August 2026. Romanian transposition status should be verified again before publication or reliance.

Need Legal Advice?

For specialist advice on this topic, contact Razvan Alexandru Olaru at Olawru.

Sources

1. Directive (EU) 2024/2853 — EUR-Lex, consolidated text

2. Corrigendum published on 7 May 2026

3. EUR-Lex — national transposition measures for Directive (EU) 2024/2853

4. European Commission — product-liability rules for the digital age and circular economy

5. European Parliament — revised Product Liability Directive

6. Council of the EU — adoption of the revised Product Liability Directive

7. International Bar Association — liability for software under the new Directive

8. Gibson Dunn — software, AI and complex supply chains under the Directive

9. Taylor Wessing — new product-liability risks for products in the EU

10. Babeș-Bolyai University — Romanian doctrinal analysis of Directive (EU) 2024/2853