EU's December deadline puts software under strict product liability

What changes on 9 December

If you drop a faulty phone and it catches fire, the maker is liable. The same now goes for a scheduling app that deletes your files, or an AI model that makes a decision it shouldn't. From 9 December 2026, software placed on the EU market is a product, and defective products trigger strict liability ^[1].

Think of it like this: a faulty toaster that burns your kitchen down has always been the manufacturer's problem, even if nobody was careless. Now the toaster's firmware gets the same treatment. The line between hardware and software is gone.

Sweden's government has proposed a new Product Liability Act to transpose the directive ^[1]. The rule is simple: if a product is defective and causes harm after 9 December 2026, the manufacturer is liable, and in certain cases so are importers and distributors.

What counts as harm

The directive covers death and personal injury, damage to property that isn't used exclusively for professional purposes, and destruction or corruption of data that isn't used for professional purposes ^[1]. A defect in accounting software that wipes a company's server doesn't count. A bug in a consumer app that corrupts your family photos does.

The word placed on the market matters. A product reaches the market when it's first made available in the EU, whether for payment or for free ^[2]. Updates to existing software don't restart the clock, but a new standalone product released after the deadline falls under the new rules immediately.

The shift in evidence

Product liability has always been strict, meaning you don't need to show that someone was careless. What's new is how much easier it is to prove your case ^[2].

Courts can now order defendants to disclose relevant evidence, and in certain conditions the burden of proof is eased. Say a medical device controlled by software injures someone. If the claimant shows the device was defective and the injury fits the defect, and if the technical or scientific complexity makes the causal link hard to prove, the court can presume the link exists unless the defendant shows otherwise ^[2].

That's a short conversation if you can show exactly which version was running, and what it did. It's a long one if you can't.

What this means for you

If you build, sell or import software that reaches consumers or small businesses, here are three questions worth asking now:

• Could you show which version of your software was running on a given day, in a way that holds up if challenged?
• Do your logs capture enough to reconstruct what your software did if something goes wrong?
• If a court ordered you to hand over evidence, where would you find it, and how would you show it hasn't been edited?

The directive doesn't prescribe how you keep records, but it does make it easier for claimants to ask for them and for courts to draw inferences if you don't have them.

How a digital witness fits

Here the thing to seal is each software release: the build fingerprint, the release notes and the test results. You seal it when the release is published, and again at each deployment. A deployment record might include the customer reference, the version deployed, the timestamp and the person who approved it.

Sealing takes a fingerprint of the record, not the record itself, so the data never leaves your systems. You send the fingerprint to WitniumChain through the REST API, the SDK or the MCP server, and get a witness ID back. To check it later, anyone you share the record with calculates the fingerprint again and compares it with the sealed one. If it matches, nothing has changed. The first 2,000 witnesses a month are free, and the documentation shows you how to start.

What it shows is that a release record and its deployment log existed at that time, unchanged since. What it doesn't show is that the version was free of defects, or that it caused or didn't cause the harm. But when a court or an insurer asks which version ran and when it was deployed, you have a record nobody can accuse you of rewriting after the fact.

How it would work

1. At release, seal the build fingerprint, release notes and test results.
2. At deployment, seal a record of what was deployed, where and when.
3. If questioned, share the records and let the other party check them against the sealed fingerprints.

What to watch

The transposition deadline is 9 December 2026 ^[1]. After that, every EU member state must have the new rules in national law. For products placed on the market after that date, software is a product, and the evidential rules apply.

If your software controls anything physical—vehicles, medical devices, machinery—the overlap with the Machinery Regulation, the Medical Device Regulation and the AI Act's high-risk categories means you're already keeping detailed records. The product liability rules don't replace those; they add a layer of strict liability and easier evidence rules on top.

For pure software, the practical question is the same: when something goes wrong, can you show what your software did, which version was running and when it was deployed? The law doesn't say how. It just makes it matter more when you can't.