EU Product Liability Directive 2024/2853: what software as a product means for medtech and fintech engineering teams

Picture a fictional EU fintech just after a routine app release. A sync bug quietly corrupts some customers’ saved documents. Then a letter arrives asking which build each customer ran, what was tested, and when the fix shipped. If your answer is CI logs only engineers can read, you’re on the back foot.

From the end of 2026, that letter could open a product liability claim. The new EU Product Liability Directive, Directive (EU) 2024/2853, names software as a product, and a manufacturer can be held liable without fault when defective software causes covered damage, from personal injury to corrupted non-professional data. Member States must transpose it by 9 December 2026.

If you lead software or product at a medtech or fintech company, your release record is becoming part of your defense file. This is engineering guidance, not legal advice: national laws transposing the Directive will apply, and your counsel decides how they affect your products and contracts.

What does the new Product Liability Directive change for software?

Software is now expressly a product, however it is supplied. Article 4(1) defines a product as all movables and “includes electricity, digital manufacturing files, raw materials and software”, and Recital 13 adds that this applies whether software is stored on a device, accessed through cloud technologies or supplied as software as a service.

The same recital lists “operating systems, firmware, computer programs, applications or AI systems” as examples and treats a developer or producer of software, including AI system providers under the AI Act, as a manufacturer, but excludes the content of digital files, such as media files or e-books, “or the mere source code of software”.

A digital service integrated into or inter-connected with a product, so that its absence would stop the product performing one of its functions, is a related service under Article 4(3), treated as a component; Recital 17’s example is a health monitoring service relying on a product’s sensors.

Liability is no-fault: under Article 10(1), injured people prove defectiveness, damage and the causal link, not negligence, with presumptions that can ease that burden.

Under Article 3, Member States may not keep or introduce more or less stringent rules to achieve a different level of protection, unless the Directive allows it.

When does the Directive apply, and what is the transposition deadline?

It applies to products placed on the market or put into service after 8 December 2026.

Transposition is happening country by country, and national laws may differ where the Directive allows. Check the status in each Member State where you sell, using the national transposition measures listed on EUR-Lex and your counsel.

Which damage is covered, and why does that matter for fintech?

Only natural persons can claim, for death or personal injury (including medically recognized damage to psychological health), damage to property not used exclusively for professional purposes, and destruction or corruption of data not used for professional purposes. Article 6(1) sets that list, and Article 6(2) covers the material losses that result from it.

Recital 24 says “pure economic loss, privacy infringements or discrimination” should not by themselves trigger liability under this Directive; other liability regimes are unaffected.

For medtech, personal injury is the obvious exposure; Recital 30 notes that some products, “such as life-sustaining medical devices”, entail an especially high risk of causing damage to people.

For fintech, a defect that only causes a financial loss is not by itself covered, but one that destroys or corrupts a consumer’s non-professional data can be. That’s the opening scene. Recital 20 keeps this distinct from data leaks or breaches of data protection rules, which stay under the GDPR and related law.

B2B software is largely outside: property used exclusively for professional purposes, and data used for professional purposes even if not exclusively, are excluded (Article 6(1) and Recital 22). Contractual liability and other national liability rules are not affected (Article 2(4)(b)), and sector rules such as DORA for banks are separate laws with their own requirements.

How do software updates and cybersecurity affect product liability?

A manufacturer stays responsible while software is within its control. Under Article 4(5), control includes authorizing or consenting to integrating components, “including software updates or upgrades”, and “the ability to supply software updates or upgrades, themselves or via a third party”.

Under Article 11(2), the defense that the defect did not exist at release fails where the defectiveness is due to a related service, “software, including software updates or upgrades”, “a lack of software updates or upgrades necessary to maintain safety”, or a substantial modification, within the manufacturer’s control.

Article 7(2)(f) lists “relevant product safety requirements, including safety-relevant cybersecurity requirements” among the circumstances a court considers, and Recital 32 says a product can be defective on account of its cybersecurity vulnerability.

Liability is not reduced where damage is caused both by a defect and by a third party’s act (Article 13(1)), such as someone exploiting a vulnerability (Recital 55). It can be reduced where the injured person is at fault, for example by negligently failing to install updates provided.

The Directive creates no update duty: Recital 51 states that “This Directive does not impose any obligation to provide updates or upgrades for a product.” Update duties come from other law, such as the MDR’s lifecycle requirements for devices.

Article 7(2)(c) also lists the effect of any ability “to continue to learn or acquire new features” after release as a factor in defectiveness. For SBOM and update questions to put to a health software partner, see CRA vs MDR for health software.

When does a software release count as a substantial modification?

A release is a substantial modification when it is substantial under the relevant product safety rules or, where those set no threshold, when it meets the test in Article 4(18): it “changes the product’s original performance, purpose or type, without that change having been foreseen in the manufacturer’s initial risk assessment” and “changes the nature of the hazard, creates a new hazard or increases the level of risk”.

Recital 40 adds that where a substantial modification comes through a software update or upgrade, “or due to the continuous learning of an AI system”, the product counts as made available or put into service when the modification is made. How that applies to products first released before December 2026 is a question for counsel.

Under Article 17, claims expire 10 years after the product was placed on the market or put into service, or after a substantially modified product was made available again, and 25 years where a personal injury is latent. Recital 58 says updates that are not substantial modifications do not affect the expiry period.

Anyone who substantially modifies a product outside the manufacturer’s control and makes it available is treated as a manufacturer (Article 8(2)).

Article 16 requires proceedings to start within three years of the injured person becoming aware, or when they should reasonably have become aware, of the damage, the defect and the liable operator.

What evidence could you be asked to disclose?

Once a claimant makes a plausible case, a court can order you to disclose relevant evidence. Under Article 9(1), a claimant with facts and evidence “sufficient to support the plausibility of the claim” can ask for disclosure of relevant evidence at the defendant’s disposal, limited to what is necessary and proportionate, with trade secrets protected (Article 9(3) to 9(5)).

Under Article 9(6), courts can require evidence “in an easily accessible and easily understandable manner”, where proportionate, and Recital 42 says this can include documents the defendant has to create by compiling or classifying available evidence.

Under Article 10(2), defectiveness is presumed where the defendant fails to disclose, where the product breaches mandatory product safety requirements meant to protect against the damage suffered, or where there is an obvious malfunction during reasonably foreseeable use or ordinary circumstances. Recital 46 counts missing logging required under Union or national law as such non-compliance.

Under Article 10(3), the causal link is presumed once the product is shown to be defective and the damage is “of a kind typically consistent with the defect in question”.

Where a claimant faces “excessive difficulties, in particular due to technical or scientific complexity”, Article 10(4) has the court presume defectiveness, causation or both if the claimant shows they are likely. All presumptions can be rebutted (Article 10(5)).

Evidence you can retrieve, explain and tie to a release is now part of your liability position, not only your audit position; medtech teams already keeping ISO 13485 and IEC 62304 records have a head start.

What should medtech engineering teams do now?

Keep the lifecycle evidence the MDR already requires, and make it readable for a court. MDR Article 10(16) requires measures for “sufficient financial coverage in respect of their potential liability under Directive 85/374/EEC”.

Article 21 of the new Directive reads references to the repealed Directive as references to the new one, so ask your insurer and counsel about your cover. Then work through this list:

• A court-readable release record: what changed, which risks it touches, which tests ran on which build, and residual anomalies.
• A substantial modification check: does the change stay inside the original risk assessment and intended purpose?
• Retention set around the expiry periods: the 10-year and 25-year periods in Article 17 are a sensible input; agree actual periods with counsel and your QMS owner.
• Update capability: Article 11(2) makes missing safety updates within your control a liability issue, so keep the ability to build, sign and ship a patch for every supported version.
• Known open source: under Recital 15, where free and open-source software supplied outside a commercial activity is integrated into a product, the product manufacturer can be liable, not the open-source developer.

What should fintech and financial services engineering teams do now?

Map which products reach natural persons and which defects could cause covered damage; in finance, the realistic case is corrupted consumer data, not injury. Consumer mobile banking, payment, insurance and wealth apps are software products under Article 4(1); internal tools used only for professional purposes fall largely outside the covered damage.

Recital 20 says data destruction does not automatically cause a material loss if the victim can retrieve the data at no cost, for example from a backup.

Cloud back ends and APIs your app needs to perform its functions can be related services within your control (Article 4(3) and Recital 17). Build-linked test results, approvals and deployment logs then serve DORA, audits and disclosure at once.

Don’t rely on disclaimers: Article 15 says liability toward the injured person cannot be limited or excluded by contract. Fintech, insurtech and digital banking teams can start with our fintech AI and software partner questions.

What should you agree with your software development partner?

You stay liable toward injured persons for defective components within your control, and contracts cannot limit that, but they can allocate recourse, evidence, update duties and cooperation between you and your partner.

Article 4(10) makes a manufacturer anyone who develops, manufactures or produces a product, or “has a product designed or manufactured”, or presents themselves as the manufacturer by putting their name or trademark on it.

Under Article 8(1), the manufacturer of a defective component integrated into a product within the manufacturer’s control can be liable alongside the product manufacturer. Whether your partner counts as one depends on the facts and national law; ask counsel.

Under Article 11(1)(f), a component manufacturer is not liable if the defect is attributable to the product’s design or to the product manufacturer’s instructions.

Operators liable for the same damage can be held jointly and severally liable, and the one who pays can seek recourse under national law (Articles 12 and 14).

A manufacturer integrating software from a microenterprise or small enterprise can contractually waive its recourse against that supplier (Article 12(2)), without affecting liability toward the injured person.

Cover these points in the contract:

1. Roles: who places the product on the market, who is named manufacturer, which software is a component.
2. Evidence access: preserving and handing over build, test, review and deployment records in a disclosable form, and for how long.
3. Update and patch duties: who can ship updates, security fix response times, and what happens when the engagement ends.
4. Open source and SBOM: who maintains the component list and vulnerability status.
5. Change control: who decides whether a change is a substantial modification, and how it’s recorded.
6. Recourse, indemnities and insurance, within the limits national law allows.
7. Cooperation in claims: technical explanations, expert input and court-ordered disclosure.

To shortlist partners that can work this way, use our regulated software partner scorecard.

How does Areusdev help software teams prepare?

We build and integrate software for regulated medtech, health and financial services teams and produce the release evidence they rely on, from traceable requirements and verification records to SBOMs and update pipelines. We’ve delivered software engineering since 2004, and 17 of our 72 people work in healthtech engineering. We agree evidence formats, patch responsibilities and the change control record with your teams at the start; product, regulatory and legal decisions stay yours. ISO 13485 and IEC 62304 are standards we engineer against inside our medtech clients’ quality systems.

We have supported regulated delivery for Dell Financial Services, introduced CI/CD pipelines for banking platforms at Raiffeisen, implemented automated testing across insurance platforms for Allianz, and contribute regulated R&D and exoskeleton mechatronics engineering to NerveRepack, an EU research consortium. Client data is never used to train shared models without a written agreement. Learn more about our healthcare software development, security-by-design and cybersecurity and QA and CI/CD services.

If you take one thing away: from December 2026, your release record is evidence a court may read, so write it for that reader. This week, check whether an outsider could tell what your last release changed, what was tested, and whether it was a substantial modification.

Frequently asked questions

Does the EU Product Liability Directive apply to SaaS and cloud software?

Yes. Recital 13 of Directive (EU) 2024/2853 says software is a product irrespective of how it is supplied, whether stored on a device, accessed through a communication network or cloud technologies, or supplied through a software-as-a-service model. Digital services that a product needs to perform its functions are related services and count as components within the manufacturer’s control.

When does Directive 2024/2853 start to apply to software products?

It applies to products placed on the market or put into service after 8 December 2026, following a corrigendum published on 7 May 2026. Member States must transpose it by 9 December 2026, and products placed on the market before that date stay under the old Directive 85/374/EEC. Ask counsel how later substantial modifications to older products are treated.

Is a software manufacturer liable for not shipping security updates?

It can be. Under Article 11(2), a manufacturer cannot rely on the defense that a defect arose after release when the defect is due to a lack of software updates necessary to maintain safety, within its control. The Directive itself imposes no duty to provide updates (Recital 51); those duties come from other laws, such as the MDR.

Does the Directive cover financial losses caused by a software bug?

Not by themselves. Recital 24 says pure economic loss, privacy infringements and discrimination should not on their own trigger liability under this Directive; covered damage is death or personal injury, damage to non-professional property, and destruction or corruption of data not used for professional purposes. Contract law and other national liability rules still apply.

Who is liable if open-source code in our product is defective?

The product manufacturer can be, but not the open-source developer, where free and open-source software supplied outside a commercial activity is integrated into your product in the course of a commercial activity (Recital 15). Open-source software supplied commercially is within scope, so track components and vulnerabilities in an SBOM for every release.

Can a contract with our software supplier limit liability to patients or customers?

No. Article 15 says liability toward the injured person cannot be limited or excluded by a contractual provision or by national law. Contracts can still allocate recourse, indemnities, evidence duties and update responsibilities between you and your supplier, and Article 12(2) lets you waive recourse against a micro or small software supplier by agreement.