Software as a Product: What the New Liability Directive Changed

Product liability in the EU has been strict since Council Directive 85/374/EEC. Strict means the injured person does not have to prove that anyone was careless. Prove the product was defective, prove the damage, prove the causal link, and the manufacturer pays.

That regime was written for movables: kettles, cars, pharmaceuticals. For forty years it left an argument unsettled. Is software a product, or is it a service, or information, or nothing the Directive contemplates? National courts diverged. A defect in an embedded controller might be covered because the physical device was a product, while the same logic sold as a download might not be.

Directive (EU) 2024/2853, adopted on 23 October 2024, repeals the 1985 Directive and answers the question directly. Software is a product.

Everything else in this path follows from that sentence, because the surrounding machinery, strict liability with no need to prove fault, was already built and now applies to code.

Article 4 defines a product as all movables, even if integrated into or inter-connected with another movable or an immovable, and states that this includes electricity, digital manufacturing files, raw materials and software.

The crucial design choice is that the definition is indifferent to how software reaches the user. Software stored on a device, embedded in firmware, downloaded, accessed over a network, or supplied as software as a service is a product on the same terms. A vendor cannot restructure its way out of the regime by moving from a shipped binary to a hosted offering.

A digital manufacturing file is also a product: a digital version of, or template for, a movable containing the functional information necessary to produce a tangible item by automated control of machinery or tools. A defective print file that yields a brittle part is a defective product in its own right.

AI systems are software. Their providers are treated as manufacturers, with no separate liability track.

The Directive draws one line inside the digital world, and it is the line between a thing that does something and a thing that says something. Information is not a product.

So the content of an electronic book, a media file, or a professional opinion delivered digitally falls outside the regime, and its author is not a manufacturer. Source code, considered purely as information, sits on the same side of the line.

The distinction protects the freedom to publish. Making a publisher strictly liable for the safety consequences of an idea would be a different and much larger law.

Where it gets interesting is at the boundary. A recipe in an e-book is information. The same recipe implemented in a connected oven's control software, executing a temperature profile, is part of a product. A digital manufacturing file is explicitly a product, precisely because its information is functional: it drives machinery.

The test in practice is whether the software executes and acts, or merely conveys.

Scope does not stop at the product. A component is any item, whether tangible or intangible, raw material or related service, that is integrated into or inter-connected with a product.

The intangible half of that sentence brings libraries, models and modules inside. The related-service half goes further and is the genuinely novel piece.

A related service is a digital service integrated into or inter-connected with a product in such a way that its absence would prevent the product from performing one or more of its functions. The Directive's own illustrations are the continuous supply of traffic data to a navigation system and a temperature control service for a smart appliance. Internet access itself is not a related service.

The test is functional necessity, and it produces a wide net: an API your device calls to make a safety decision is a component of that device. Its supplier can be liable as a component manufacturer where the defect was integrated within the product manufacturer's control.

Take a connected insulin pump and follow the definitions outward.

The pump itself is a movable, so it is a product. Its firmware is software, so it is a product in its own right, and a component of the pump. The dosing algorithm supplied by a third party is intangible, so it is a component. The cloud service that streams glucose readings, without which the pump cannot adjust dosing, meets the related-service test, so it too is a component.

The companion phone application is software: a product, and a component when inter-connected.

What stays outside is instructive. The hospital's internet connection is not a related service. The clinical guidance document that came with the pump is information, not a product, though its inadequacy is relevant to whether the pump is defective.

One physical device therefore carries several products and several potential defendants, which is why the chain of liable operators in Article 8 needs its own lesson.

The Directive does not apply to free and open-source software developed or supplied outside the course of a commercial activity.

This is the same hinge the Cyber Resilience Act uses, and reading them together is worthwhile because they were drafted to be consistent. A maintainer publishing a library without commercial supply is neither a CRA manufacturer nor a liable economic operator here.

What the exclusion does not do is insulate the library from the regime. Once a company integrates that library into a product it sells, the library is a component of a product placed on the market commercially. Liability attaches to the integrator as manufacturer of the finished product, and the injured person never needs to reach the maintainer.

The practical effect is to concentrate liability at the point of commercialisation. That is a deliberate allocation: the party that earns from the product carries the risk of it, and cannot push that risk upstream to unpaid contributors.

Software vendors are used to managing risk through contract: limitation of liability clauses, caps tied to fees paid, exclusions of consequential loss, disclaimers of fitness. None of that operates here.

Product liability is non-contractual. The claimant is an injured person, who need not be your customer, need not have accepted your terms, and need not have any relationship with you at all. A bystander injured by a defective device has the same claim as the purchaser.

And the Directive forbids contracting out. Liability towards the injured person cannot be limited or excluded by a contractual provision or by national law.

That closes the route most software risk management relies on. Your master services agreement governs what your customer can recover from you for breach. It has no effect on what an injured third party can recover for a defective product, and no effect on the size of that recovery.

Insurance and product safety engineering replace drafting as the controls that actually work.

Two features of the 1985 regime limited its practical reach, and both are gone.

The old Directive set a lower threshold of 500 euro for property damage, so smaller claims were simply not worth bringing. That threshold has been removed. Member States were also permitted to cap total liability for personal injury caused by identical items; that option is gone too.

The Directive is also fully harmonising in a strong sense. Member States may not maintain or introduce national provisions diverging from it, whether more stringent or less stringent, except where the Directive expressly allows. That is unusual and deliberate: it means the answer to a liability question should not change materially across the internal market.

Combined with the availability of representative actions for consumers, removing the threshold changes which claims are economically viable. A defect producing modest losses across many users was previously an unlitigable annoyance. Aggregated, it is now a claim.

Member States must transpose the Directive into national law by 9 December 2026, and it applies to products placed on the market or put into service from that date. Products placed on the market before it remain under the rules stemming from the 1985 Directive.

That produces a split estate rather than a switchover, and the split will persist for years. A device sold in November 2026 and an identical device sold in January 2027 are governed by different liability rules, with different definitions of product, different presumptions, and different heads of damage.

For software the split is less clean than it looks. A hosted service is continuously supplied, and a substantial modification places a product on the market anew. Determining which regime governs a long-lived, continuously updated product is itself a legal question.

The planning consequence is that the boundary date is not a deadline for a project. It is the date after which every new release carries a different risk profile.

These two instruments are complementary halves of one policy, and they are best read together.

The Cyber Resilience Act is public law. It tells a manufacturer what to build and what to report, and an authority enforces it with administrative fines, restrictions and recalls. The injured user is not a party.

The Product Liability Directive is private law. It gives an injured person a claim for compensation, decided by a civil court. No authority is involved.

The connection runs in both directions. Non-compliance with mandatory safety requirements, including cybersecurity requirements, feeds directly into whether a product is defective and can trigger a presumption of defectiveness. A market surveillance action under the CRA therefore hands a civil claimant evidence.

And the update duty appears in both. The CRA requires security updates through the support period. The Directive removes the manufacturer's escape route where the defect stems from the absence of updates needed to maintain safety.