Standalone Software and Product Liability

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

Separate supply does not exclude software liability

Software supplied independently of a physical device can fall within Directive (EU) 2024/2853. Article 4 includes software in the product definition, while Recital 13 recognises standalone supply as well as later integration into another product. A download or access arrangement therefore cannot be dismissed solely because no physical item changed hands. The liability analysis still requires the legal and factual conditions of the framework.

For an initial assessment, identify the program supplied, what it does, who supplied it and how it reached the user. The software product liability overview explains the common requirements of defectiveness, covered harm and causation. Standalone supply is a way of describing the product relationship. It is not a separate presumption that the application is unsafe or that its publisher must pay every resulting loss.

Describe the boundary of the supplied product

A standalone program can rely on an operating system, local permissions, external data, a network and other software. Map those dependencies without assuming they all form one indivisible product. Distinguish the executable from information it displays and from general services supporting its distribution. Article 4's product, component and related-service definitions address different relationships and should be applied to the actual functions involved.

Record what was included in the supplied release and what the user or another supplier added. A document viewer with an external extension may behave differently from the publisher's original package. A diagnostic tool may be sold separately but designed to control particular equipment. Supply independence does not establish functional independence, and a clear boundary is needed before identifying the alleged unsafe mechanism or the relevant manufacturer.

Connect the application function to safety

Article 7 concerns safety a person is entitled to expect or that the law requires. The program's presentation, technical characteristics, instructions and reasonably foreseeable use matter. An application that calculates instructions used in a physical process may raise a different safety question from an application whose only failure is a misplaced menu. Explain the function and consequences rather than relying on the broad label application.

A user exceeding an explicit operating limit does not automatically resolve defectiveness. Consider whether that use was reasonably foreseeable and how the product was presented. Equally, a user's disappointment with an advertised result is not by itself a safety defect. The investigation must identify the alleged gap in safety and assess the circumstances supporting it, while leaving consumer conformity and contractual performance questions distinct.

Identify the particular release and settings

A publisher's website may show only the latest release. A user's system may contain an older binary, a locally packaged edition or a version delivered through another distributor. Preserve the executable identifier, installation source, supply date and relevant settings. Account permissions and external integrations can affect what the application could do at the incident time.

Technical comparisons need an explicit baseline. If a test installation behaves differently, check the operating system, locale, input files and connected hardware before attributing the difference to code. The guide to configuration evidence explains why the same program can produce different behaviour under different settings. These facts help establish causation rather than merely prove that a program was present on a computer.

Commercial activity is broader than a purchase price

Article 4 defines making available on the market by reference to commercial supply, whether for payment or free of charge. A free download offered within a commercial model is therefore not automatically outside the framework. Article 2(2) has a specific exclusion for free and open-source software developed or supplied outside commercial activity. The actual supply circumstances matter more than a price field.

Keep the publisher identity, licence, distribution route and any relevant commercial arrangements. Do not assume that every unpaid contributor in an upstream repository is the supplier of the finished application. A publisher that packages code under its own brand and supplies it commercially presents a different relationship from non-commercial upstream development. Record those actors separately and apply Article 8 to the role actually performed.

Damage categories can exclude familiar software losses

A standalone application's failure may cause financial inconvenience without producing damage covered by Article 6. The Directive addresses personal injury, specified property damage and destruction or corruption of data not used for professional purposes. It does not make every failed transaction, lost trading opportunity or reduction in productivity a covered head of damage. Other legal grounds may need separate investigation.

Data use deserves particular attention. Corrupted family photographs are not the same category as corrupted professional accounting records. A mixed incident may involve several people and different losses. Record the owner, actual use, nature of damage and restoration evidence for each item. Avoid combining all associated costs into one product liability figure before the underlying harm categories have been assessed.

Timing and proof complete the assessment

The corrected Article 2(1) concerns products placed on the market or put into service after 8 December 2026. The 9 December 2026 national transposition deadline is a different rule. An application still running on a computer after that date is not brought into the new framework merely by continued use. Supply and first-use facts need to be identified for the particular product.

Under Article 10, defectiveness, damage and causation remain the starting proof requirements, subject to its specified rebuttable presumptions. Article 9 provides conditional court-controlled evidence disclosure with proportionality and confidentiality safeguards. Preserve the actual release and the factual chain from its operation to the reported harm. A reliable assessment explains both what the records demonstrate and what remains unknown about configuration, outside inputs or competing causes.

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

Independent educational information at EU Directive level. National implementing law and procedure require separate review.

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.