Software Product Liability Explained

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

Software can be a product and a source of unsafe behaviour

Software is expressly included in the product definition in Directive (EU) 2024/2853. It can be supplied on its own or operate as a component of a physical product. A program can therefore raise a product liability question without being delivered in a box. The decisive investigation still concerns a safety defect, covered damage and the connection between them, together with the responsible economic operator and the applicable legal framework.

This distinction matters because software complaints range from inconvenient interface errors to failures capable of causing serious injury. A broken search filter, an unsafe motor command and corruption of personal photographs present different questions. Calling all three events a bug does not answer whether the product supplied the safety a person was entitled to expect. The practical starting point is the function that failed, the product state at the time and the harm actually reported.

Check the product date and governing law

The corrected Article 2(1) applies the new Directive to products placed on the market or put into service after 8 December 2026. The national transposition deadline in Article 22 is 9 December 2026. These are connected dates with different legal purposes. An incident occurring after the deadline does not itself bring every older application or device within the new rules.

Keep the date and evidence of the relevant supply or first use. For software integrated into a larger system, identify what product is being examined and whether later changes raise a separate question. Do not assume that every patch creates a newly placed product or that an old physical device automatically determines the legal treatment of every later software supply. National implementation and the actual product history need their own examination.

Identify the software rather than relying on its label

Recital 13 explains that software can include operating systems, firmware, computer programs, applications and AI systems, irrespective of its supply or use method. Delivery through a communication network, cloud technology or a software-as-a-service model does not by itself take software outside the product analysis. That does not make every service or information file a software product.

Define the executable function, its supplier and the way it interacts with other products. A mobile app may calculate a value, display information or send commands to a device. Embedded code may regulate heat, movement or pressure. Those functions have different safety implications. The guide to standalone software liability examines software supplied separately, while embedded software liability follows code that contributes to a larger product's behaviour.

The legal threshold concerns safety

Article 7 asks whether the product provides the safety a person is entitled to expect or that Union or national law requires. Relevant circumstances include presentation, instructions, technical characteristics, reasonably foreseeable use, foreseeable interaction with other products and safety requirements. For a product intended to prevent damage, failure to perform that purpose is expressly relevant. A technical specification is evidence, but it is not the whole legal test.

An error does not need to appear in every execution to be relevant. A rare timing condition could disable a protective function, while a frequent cosmetic error might have no safety significance. Equally, a later improved release does not alone prove an earlier version defective. The distinction between software bugs and legally defective software helps frame the alleged unsafe mechanism without turning every quality complaint into a compensation claim.

Covered harm sets another boundary

Article 6 covers death and personal injury, including medically recognised psychological harm, specified property damage, and destruction or corruption of data not used for professional purposes. The defective product itself is excluded from the property category. A product damaged by a defective component integrated or interconnected by its manufacturer or within its control is also excluded from that category. Property used exclusively for professional purposes has a further exclusion.

These boundaries are particularly important for software because lost revenue, failed transactions and business data frequently dominate incident reports. Such losses cannot simply be described as covered data or property damage. Contract, consumer remedies, data protection or other liability rules may need separate consideration. Record each category of harm and who suffered it before choosing a legal route or combining costs into a single total.

Several actors can contribute to the same failure

Article 8 addresses manufacturers of defective products and, under its conditions, manufacturers of defective components. A component must have been integrated or interconnected within the product manufacturer's control and caused the product to be defective. The finished-product manufacturer can also be responsible for damage caused by such a component. Identifying an outside library therefore does not automatically remove the integrator from the analysis.

Distinguish development, commercial supply, branding, integration and later modification. A contractual allocation of responsibility between businesses may matter between them without determining the injured person's statutory position. Article 12 permits joint and several liability where several economic operators are liable for the same damage. It also contains a specific conditional rule concerning recourse against certain small software component manufacturers, which should not be mistaken for a general exemption from injured-person claims.

Commercial context and open-source code require care

Article 2(2) excludes free and open-source software developed or supplied outside commercial activity. Free access and non-commercial supply are different facts. The definition of making available on the market includes commercial supply without payment. A free application used in a commercial model cannot therefore be classified solely by the absence of a purchase price.

Commercial integration also needs separate analysis from the activity of upstream contributors. A manufacturer incorporating non-commercial open-source code into its commercial product cannot assume that the upstream exclusion immunises the finished product. Preserve the licence, actual supply arrangements and integration records. Avoid treating every contributor visible in a repository as a commercially supplying manufacturer or treating an open-source label as a universal liability defence.

Configuration and dependencies can change the result

The same executable can behave differently when connected to another device, supplied with a different dependency or run under another configuration. Feature flags, permission settings, units, regional defaults and hardware revisions can all matter. A technical account should explain how the relevant state affected a safety function, rather than naming a package and assuming responsibility follows automatically.

Records of software configuration and dependencies are consequently part of the product history. Compare the deployed system with the tested configuration and the permitted integration conditions. Identify foreseeable combinations and any warnings or restrictions. A mismatch may support a particular hypothesis, but the investigator must still examine whether it caused the alleged unsafe behaviour and the damage.

Manufacturer control can continue after release

Article 4 defines manufacturer control through specified actions, authorisation or consent, and the ability to supply software updates or upgrades directly or through a third party. Article 11(2) limits certain later-arising-defect arguments where software, related services, missing necessary safety updates or substantial modifications within that control caused the defectiveness. Passing ownership of a device to a user does not resolve those questions.

The Directive does not itself impose an obligation to provide updates or upgrades. Nor does the presence of an update button establish unlimited responsibility for all future changes. Record the actual authority, supply capability, approvals and installation outcomes. Maintenance history belongs in the assessment, while detailed update obligations and cybersecurity requirements must be researched under the relevant additional rules.

Build evidence around the incident-time state

Article 10 starts from the claimant proving defectiveness, damage and causation, subject to specified rebuttable presumptions. Article 9 provides court-controlled access to relevant evidence under conditions including plausibility, necessity, proportionality and confidentiality safeguards. Neither provision makes complete source-code publication automatic, and technical complexity does not establish liability without the required legal conditions.

Preserve identifiers, release artefacts, configuration, dependency manifests, timestamps and the records connecting them to the actual product. The software version history is useful only if it describes the state that operated during the event. A release announcement does not establish successful installation. Later diagnostics may alter that state, so record any repair, reset or forensic intervention and the limits of what could be preserved safely.

Turn the investigation into answerable questions

An initial review should identify the alleged failure, the safety expectation, each category of harm, relevant products and actors, and the missing evidence needed to test the causal account. Keep observations separate from assumptions. For example, a shutdown following installation supports a chronology but does not yet distinguish a software defect from a power failure, incompatible setting or unrelated physical damage.

The software investigation checklist turns those issues into a practical sequence. Its purpose is to support a reliable account for technical and legal review. It cannot certify liability or select national procedural rules. A mature investigation makes uncertainty visible, preserves competing explanations and connects each legal proposition to the particular release, person and event being assessed.

Records that help the review

Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.

Incident-time software identity and configuration
Relevant safety assumptions and test evidence
Supply, integration and control chronology

Not every bug is a safety defect, and not every financial loss is damage covered by this Directive.

Primary sources and legal scope

This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.