Software Is a Product. Now What?

A change of word that changes everything

For years I had the feeling software lived inside a bubble. Not in the romantic sense—more like a comfortable, almost protective grey zone. If a physical product hurt someone, the question of liability was immediate and concrete. If it was “just” software, the conversation slid into bugs, patches, workarounds, and that faintly indulgent shrug that said “it’s normal, it gets updated”.

Directive 85/374/EEC on liability for defective products, after all, talked about movable goods, tangible stuff. Software, intangible by definition, didn’t fit. And when a rule fits you badly, often it ends up not fitting at all.

From 9 December 2026, with Directive (EU) 2024/2853, that ambiguity closes. The new Product Liability Directive (PLD) says explicitly that software is a product. Not just software embedded inside an object, but all of it: standalone, embedded, firmware, applications, cloud, SaaS, AI systems. Regardless of where it runs and how you ship it.

This isn’t a footnote. It’s a paradigm shift, and maybe the most interesting thing is that it doesn’t only concern the people writing code. It concerns whoever decides what to build, who sells it, who releases it, who maintains it, and who decides when to stop.

Strict liability: where the perspective shifts

The PLD rests on a concept that’s easy to underestimate in software until it lands on you: strict liability.

In practice, anyone harmed by a defective product doesn’t have to prove that you were negligent. They don’t have to reconstruct your decision chain, don’t have to show “you could have done better”. They have to show three things: that the product was defective, that there was harm, and that there’s a causal link.

For people used to thinking in terms of “we did our best”, “it was an edge case”, “it was a third-party dependency”, that’s a meaningful mental shift. Diligence still matters, of course—but not as an automatic shield.

And there’s another piece that makes things even more concrete: the directive introduces presumption mechanisms.

If proving the defect or causal link is “excessively difficult” for the harmed party—which, with complex software or AI systems, is almost the norm—the court can presume defectiveness and causation. It can also order the producer to disclose technical documentation, which has to be presented “accessibly and comprehensibly”. Failure to cooperate can itself become a factor against you.

Stated plainly: in many cases you’ll find yourself having to prove the software wasn’t defective. And to do that, you need evidence. Traces. Reasoned decisions. Data.

Product side: liability starts long before the code

When liability comes up, the instinct is to look at development. But the PLD also puts product decisions under the lens—the choices that come before any code.

Defectiveness is judged against reasonable safety expectations. A product is defective if it doesn’t offer the level of safety a person is legitimately entitled to expect. That judgement depends on how you present the product, on reasonably foreseeable use, on the moment it was placed in service. But also on very contemporary elements: interconnection with other systems, conformity with cybersecurity requirements, even the capacity to learn.

Here I think about how often a roadmap is born from trade-offs that look purely “business”: ship faster, cut a security feature, postpone the hardening phase, integrate an AI component because it’s cool and competitors already have one.

Under the PLD, those aren’t just product choices. They’re choices that can become relevant in a legal challenge.

If you promise a certain reliability or security standard in your commercial specs, you’re creating an expectation. If you integrate an AI component that changes behaviour over time, you’re taking responsibility for that future behaviour too. AI’s unpredictability, the way the directive is written, isn’t a defence.

The most practical consequence, I think, is this: risk assessment enters product management. Not as a document you do once and forget, but as a habit.

And documentation of decisions enters with it. Not for bureaucracy’s sake, but because in a few years you may need to explain why a certain choice was reasonable at that moment. Architecture decision records, which many teams use today just to keep track of themselves, start to look like a piece of your defence.

Sales side: the contract is no longer a shield

There’s a conditioned reflex in software: if risk goes up, add a clause. Limitation of liability, cap, indemnity, disclaimers in the terms.

The PLD is fairly brutal here: liability under the directive cannot be excluded or limited contractually when the harm concerns a natural person. That holds in B2C, and in practice it reaches B2B every time the end users are people.

This doesn’t make contracts useless. It means they have to change function.

In B2B in particular, contracts need to clarify responsibility along the supply chain. If you develop for a customer who puts the product on the market under their own brand, who’s the “manufacturer” under the PLD? If your software is a component inside a larger system, how is recourse handled between parties? You can’t eliminate liability toward the outside world, but you can and should clarify what happens between you.

Then there’s a piece sales and marketing often underestimate: commercial promises.

Demos, brochures, claims like “highest security standards”, slides with “zero downtime”, pricing pages that imply certain guarantees. All of this contributes to defining what the user was legitimately entitled to expect. So it indirectly enters the assessment of defectiveness.

Finally, the insurance and pricing question. Classic professional liability insurance covers negligence, not necessarily strict liability. Many companies will likely have to revisit coverage and limits, including cybersecurity, data loss, and immaterial damages. That cost will end up in the price. With one interesting side effect: those who move well early can turn compliance into a credible competitive argument.

Releases: every deploy now leaves traces

If you work in releases, DevOps, QA, or you’re the person who finally says “OK, ship it”, this is maybe the most concrete part.

In modern software, release isn’t the end. It’s the beginning. Because almost always the producer keeps control through updates, remote access, feature flags, patches, security updates.

The PLD, read alongside the regulatory context, makes a “ship and see” approach very risky. Failing to provide security updates for known vulnerabilities can itself be considered a defect. And an update that introduces a problem can be seen as a substantial modification, with downstream effects on terms.

Base liability lasts 10 years, and for latent personal injuries it can reach 25. When I read those numbers I always wonder whether we really have a culture of preserving evidence over that horizon. Because doing things well isn’t enough—you have to be able to show it.

This is where traceability comes in.

Knowing what a given version contained on a given date. Which dependencies. Which known vulnerabilities. Which tests ran. Who approved. What was decided and why.

The SBOM (Software Bill of Materials) becomes central. The Cyber Resilience Act makes it mandatory in many cases anyway, and the CI/CD pipeline becomes, in effect, compliance infrastructure: automatic SBOM generation (CycloneDX or SPDX), vulnerability scanning, deploy audit trails, artifact retention.

And there’s a detail that sounds banal until you live it: the decision not to ship a patch is also a decision. If today you choose to postpone a fix for sensible reasons, fine—probably. But in five years you may have to explain why it was sensible. Better to have that explanation written while memory is fresh.

Development: documentation isn’t bureaucracy, it’s defensible memory

For developers, the PLD doesn’t ask for magic. It doesn’t say “write perfect code”, which doesn’t exist. It asks, in essence, that the path be reconstructible.

Automated tests that prove expected behaviour. Tracked code reviews. Integrated security scans. Commit messages that aren’t “fix”. Tickets that explain context.

Many teams already do these things, perhaps unevenly. The difference is that they shift from “good practice” to a piece of legal protection too.

The link with the Cyber Resilience Act is direct: if you’re not compliant with requirements like secure-by-design, vulnerability management, and SBOM, that non-compliance can reinforce a defectiveness claim under the PLD. The rules no longer live in separate compartments.

The myth of B2B as a free zone

I get the temptation: “we only sell to companies, so it doesn’t apply to us”.

But take a moment to look at the actual users.

Public administration software: citizens. HR systems: employees. E-learning: students. Parking systems: drivers. Healthcare: patients. In every case the customer is an organisation, but the impact lands on natural persons.

On top of that, the PLD reasons by components. If you supply a module, an API, a microservice that ends up inside someone else’s product, you can be considered manufacturer of the component.

And then there’s the extension of recoverable damages: destruction or corruption of data not used for professional purposes, with no minimum threshold and no cap. That shift hasn’t been metabolised yet by many companies.

Open source: protected, but not a loophole

The directive excludes open source software developed or supplied outside a commercial activity. But if there’s consideration—even in the form of personal data—the picture changes.

And above all, if you integrate open source into a commercial product, liability for any defects falls on whoever integrates and places it on the market.

That shifts the centre of gravity: it’s no longer just a licence-compliance question. It becomes technical and legal risk management. Dependency choice, vetting processes, serious vulnerability management, and again SBOM.

The PLD doesn’t stand alone: an ecosystem that interlocks

Looking at the European picture, the sense is that the EU is building a precise idea of “software as a product” and is supporting it from multiple sides.

The PLD interlocks with the Cyber Resilience Act (cybersecurity by design, SBOM, vulnerability management), with the AI Act (which makes AI providers manufacturers for PLD purposes too), with the GDPR (data breaches and damages), with NIS2, with the GPSR, with the Representative Actions Directive for collective redress, and even with the European Accessibility Act.

The point isn’t to memorise all the acronyms. The point is that a gap in one area can propagate and reinforce litigation in another. Compliance becomes a system.

Italian implementation: a choice to watch

Italy has to transpose the PLD by 9 December 2026. Being a maximum-harmonisation directive, there isn’t much room for “creative interpretation”. But one important margin remains: the state-of-the-art defence.

In essence, the state can decide whether to keep the principle that a manufacturer doesn’t answer if the defect wasn’t recognisable with the knowledge available at the time of placing on the market. Or it can drop it.

This isn’t a detail, and it’s worth watching. Because it changes the risk profile, especially for complex software and AI scenarios.

Not just risks: the part that can become an advantage

If you read it all in catastrophe mode, the PLD looks like pure cost. More documentation, more processes, more insurance, more internal arguments.

But there’s another reading, and perhaps the more useful one if you have decisions to make now.

The PLD creates a playing field where quality, security, and supply-chain transparency become measurable competitive advantages. No more “trust us”—instead, “we have processes and evidence that hold up to a formal request, and if needed, to a court”.

For software houses, arriving compliant before the deadline can become a strong argument with enterprise and public-sector buyers. For consulting and system integration, it opens enormous demand for skills that today—at least in the Italian SME landscape—aren’t widespread. For product builders, it’s an incentive to invest in things that, in the long run, actually make software better.

A conclusion without triumphalism

For forty years we got to think of software as something special. More flexible, more updatable, more forgivable.

The PLD says that exceptionalism is over. Software is a product, with liability comparable to a machine, a medical device, a car.

This doesn’t only concern people who write code. It concerns roadmaps and trade-offs. It concerns contracts and commercial promises. It concerns release and support, and even end-of-life.

The most sensible thing today, it seems to me, is to shift the question from “how do we protect ourselves” to “how do we make our way of working demonstrable”. Because preparing isn’t just legal patchwork. It’s doing the job better, with more memory, more traceability, and less blind faith in the idea that “we’ll sort it later”.

The question isn’t whether to prepare. It’s how fast.

Primary sources: Directive (EU) 2024/2853; Cyber Resilience Act (EU Regulation 2024/2847); analyses by Reed Smith, IBA, Fladgate, Taylor Wessing, Clyde & Co, DLA Piper, Hogan Lovells, ICLG, Covington.

The author

Andrea MargiovanniCraft

I have been writing software long enough to consider it a craft, not a pipeline. I care about the difference between a technical choice and a default inherited without measuring its cost.

See the guide →