Defective software: how does Directive (EU) 2024/2853 reshape manufacturers’ product liability?
Introduction
Product liability for defective software is entering a new phase in the European Union. Directive (EU) 2024/2853 removes a major source of uncertainty by expressly treating software as a “product”, whether embedded in a connected device, supplied separately, accessed through the cloud or provided under a SaaS model. Artificial intelligence systems also fall within this framework.
Member States must transpose the Directive by 9 December 2026. Following the corrigendum published on 7 May 2026, the new regime applies to products placed on the market or put into service from 9 December 2026.
Why is software now a product for EU product liability purposes?
Under the current French Civil Code, Article 1245-2 defines a product as any movable property (« tout bien meuble »), electricity included, without expressly referring to software. Article 1245-3, meanwhile, assesses defectiveness by reference to the safety which a person is entitled to expect.
Directive (EU) 2024/2853 updates this framework. Article 4 expressly includes software in the definition of a product. Recital 13 confirms that this encompasses operating systems, firmware, applications and AI systems, irrespective of the method by which the software is supplied. Software developers or producers, including providers of AI systems where relevant, may therefore qualify as manufacturers.
A strict liability regime originally designed around tangible industrial goods now accommodates products that may continue to evolve long after the first commercial release.
Does every software bug make a product defective?
The Directive does not turn every programming error, performance issue or functional anomaly into a product defect triggering manufacturer liability. Defectiveness continues to depend on whether the product provides the safety that the public is entitled to expect.
For software, the analysis may take into account its intended function, reasonably foreseeable use, interactions with other products, its ability to continue learning and relevant cybersecurity requirements. Article 7 of the Directive lists those circumstances and expressly refers to the effect on the product of any ability to continue to learn after it is placed on the market. A cosmetic display bug is therefore fundamentally different from an erroneous calculation in medical-device software, a vulnerability that allows remote control of a connected product, or a malfunction causing an automated system to behave dangerously.
Software updates and AI: liability may continue after market release
A major feature of the new Directive is the concept of manufacturer control after a product has been placed on the market.
Digital products are rarely frozen on their release date. They receive patches, new functions and security upgrades, while certain AI systems may continue to change through learning mechanisms.
Article 11 of the Directive therefore removes the defence that the defect appeared after the product was first marketed where the defect results from an element remaining within the manufacturer’s control. This can include:
- a defective software update or upgrade;
- failure to provide an update necessary to maintain safety;
- a related digital service under the manufacturer’s control;
- a substantial modification of the product; or
- the evolution of a machine-learning algorithm where the manufacturer retains control.
The Directive does not, by itself, create a general obligation to provide every possible update. It also recognises situations that are genuinely beyond the manufacturer’s control, such as where a user fails to install a safety update that has been properly made available.
Third-party software components: outsourcing development does not mean outsourcing risk
Modern software is rarely written entirely in-house. Open-source libraries, APIs, SDKs, proprietary modules, pretrained models and outsourced development form a complex software supply chain.
The fact that a component originates from a third party does not, in itself, insulate the manufacturer of the final product.
Where a component has been integrated or interconnected under the manufacturer’s control, the manufacturer of the final product and, depending on the circumstances, the manufacturer of the defective component may both face liability. The Directive also provides that an economic operator’s liability is not reduced or excluded simply because the act or omission of a third party contributed to the damage.
It would nevertheless be inaccurate to conclude that every component genuinely outside a manufacturer’s control automatically creates liability for that manufacturer. Control will itself become a central litigation issue: who selected the component? Who authorised its integration? Who could update or disable it? Who approved its use in production?
Why is code traceability becoming legal evidence?
This may be one of the Directive’s most consequential developments for legal and engineering teams.
Article 9, headed “Disclosure of evidence”, allows relevant evidence held by the opposing party to be disclosed, subject to defined conditions. Article 10, on the burden of proof, introduces evidentiary presumptions going both to defectiveness and to causation. Defectiveness may, for example, be presumed where a defendant fails to disclose relevant evidence when required to do so. Further presumptions can apply where technical or scientific complexity makes proving defectiveness or causation excessively difficult. Recital 48 specifically discusses the difficulty a claimant may encounter in explaining the internal operation of an AI system.
Poor development records can therefore become a litigation weakness.
Conversely, a manufacturer that can reconstruct software versions, testing, security decisions, human approvals and component provenance will be better positioned to identify the source of an incident and rebut allegations or presumptions.
AI-generated code: generation, review and approval should be distinguishable
The issue becomes especially important with coding assistants such as ChatGPT, GitHub Copilot and other generative models.
The Directive does not require businesses to identify the legal “author” of each line of code for copyright purposes. Indeed, recital 13 distinguishes the mere source code, as information, from the software product itself. Nevertheless, the history of that source code can be highly relevant when determining who controlled the design, integration, testing and release of the product.
Consider a fictitious example. An engineer uses a generative AI system to propose a modification to software controlling a connected device. Six months later, that function causes dangerous behaviour. Saying that “the AI wrote the code” is not a defence. The company should instead be able to establish:
- which tool and, where relevant, which version was used;
- what generated code was actually incorporated;
- who reviewed that code;
- which functional and security tests were performed;
- who approved the merge and production release; and
- what subsequent changes were made.
The issue therefore intersects directly with the intellectual property treatment of AI-assisted development: our analysis, “AI-generated software: Is your code really protected by copyright?”.
Conclusion
Product liability for defective software can no longer be addressed only after an incident occurs. Directive (EU) 2024/2853 brings product liability into closer contact with cybersecurity, AI governance, vendor management and intellectual property.
Businesses should therefore build an evidentiary chain alongside their development chain. Code provenance, human decisions, reviews, testing, third-party components and updates should be reconstructable. Such records cannot guarantee that liability will be avoided, but they can establish the factual conditions in which the product was designed, controlled and maintained when litigation occurs.
Dreyfus & Associés assists its clients in managing complex intellectual property cases, offering personalized advice and comprehensive operational support for the complete protection of intellectual property. Dreyfus & Associés works in partnership with a global network of attorneys specializing in Intellectual Property.
Nathalie Dreyfus with the support of the entire Dreyfus team
Q&A
Does the Directive compensate a business for pure economic loss caused by software downtime?
Not generally. Article 5 of the Directive confers the right to compensation on natural persons only, and the Directive defines specific categories of compensable damage; it is not a general mechanism for recovering every form of B2B economic loss. Depending on the circumstances, business interruption and other purely financial losses may instead be addressed through contractual liability or other national causes of action.
Can a court require disclosure of a software application’s source code?
Potentially, where source code constitutes relevant evidence. Article 9 allows courts to order disclosure of relevant evidence subject to necessity and proportionality. The Directive also requires courts to consider confidential information and trade secrets, meaning that disclosure does not equate to unrestricted public access to proprietary source code.
Can a manufacturer contractually exclude its liability towards an injured person?
The liability provided for by the Directive cannot simply be excluded or limited against the injured person by contractual terms where the statutory conditions for liability are met. Contracts between manufacturers, suppliers and integrators nevertheless remain essential for allocating warranties, obligations and rights of recourse between businesses.
What happens to software placed on the market before 9 December 2026?
Products placed on the market or put into service before that date remain, in principle, subject to the rules deriving from Directive 85/374/EEC. A later substantial modification, however, may create a new product-liability analysis and may result in the person carrying out that modification being treated as a manufacturer under the conditions laid down by the new Directive.
Does the new Directive cover the destruction of professional data?
The Directive covers destruction or corruption of data that is not used for professional purposes. Loss involving business data must therefore be considered under any other applicable legal basis, including contractual remedies where appropriate.
Does using open-source software automatically protect the final manufacturer from product liability?
No. The Directive excludes certain free and open-source software developed or supplied outside the course of a commercial activity. That exclusion does not automatically shield a commercial manufacturer that integrates such software into its own defective product.
This publication is intended for general public guidance and to highlight issues. It is not intended to apply to specific circumstances or to constitute legal advice.












A legally useful prior art search is not a list of database hits. It should anticipate the comparisons that an earlier-rights owner could make when preparing an opposition or 




