Software becomes a product with strict liability from 9 December 2026

What changes

For as long as product liability rules have existed, a physical product that injures someone or damages their property has been a matter for strict liability. The manufacturer is liable without the injured party having to show fault. What changes on 9 December 2026 is that software on its own counts as a product.

Sweden's government proposed a new product liability act in August 2026, adapting Directive (EU) 2024/2853. ^[1] The directive explicitly lists software as one kind of product, AI systems included. ^[2] That means if a piece of software causes death, personal injury, damage to property not used exclusively for professional purposes or destruction or corruption of data not used for professional purposes, the manufacturer is strictly liable. ^[1]

Strict liability means the injured party does not have to show negligence, only that the product was defective and caused the harm. What makes this directive different from the old rules is not just that software is in, but that courts get new tools to help the injured party prove their case.

Evidence and burden of proof

One of those tools is an order to hand over relevant evidence. Under certain conditions, a court can tell the defendant to disclose evidence that could support the claim. ^[1] If the defendant refuses without good reason, or destroys or withholds relevant evidence, the court can presume the missing evidence would have gone against them. ^[1]

Another tool is a shift in the burden of proof. If the injured party faces unreasonable difficulty proving that the product was defective or that it caused the harm, the court can presume the defect or the causal link if the party shows a sufficient likelihood. ^[1] That is a lower bar than proving the case in full.

Think of it like a lost bank card. If you report it stolen and the bank claims you authorised a purchase, you don't have to prove you were nowhere near the shop. If the pattern looks wrong, the burden swings the other way. Here, if the injured party can show it's sufficiently likely that a software defect caused the harm, and proving that in detail is unreasonably hard, the court can assume the defect unless the manufacturer shows otherwise.

What counts as a product

The directive covers products placed on the market in the EU after 9 December 2026. ^[2] Software placed on the market means software made available for distribution, consumption or use. ^[2] An AI system is software, so it is a product. ^[2] A large language model running as a service is software, and therefore a product. A connected device with software on board is a product. Even a software update can be seen as placing a new product on the market. ^[2]

What doesn't count is damage to property used exclusively for professional purposes, or loss or corruption of data used exclusively for professional purposes. ^[1] A company that loses files because of a bug in business software cannot claim under this act. An individual whose family photos are corrupted can.

Who is liable

The manufacturer is liable first. If the manufacturer is outside the EU and has no authorised representative here, the importer is liable. If neither can be identified, the distributor is liable. ^[1] For software distributed as a service, the organisation making it available is the one on the line.

Once the act is in force, businesses that write, sell or operate software will need to be able to show what a given version did, when it ran and what was in it. It is one thing to keep version control for collaboration. It is another to show a court, two years later, that version 3.2.1 was the one running on the day someone claims it gave the wrong answer.

What this means for you

If you manufacture, import or distribute software, ask yourself these questions now:

• Could we show which version of our software was running on a particular device or account on a given day?
• Could we show what that version contained, unchanged since release?
• If a court asked for logs, deployment records or test results, could we hand them over in a form that holds up?
• Do we have documented processes for handling evidence requests, and do the people who run our systems know not to delete or alter records once a claim is made?

The directive gives injured parties better tools to get at the evidence. The side that cannot show what happened starts several steps behind.

How a digital witness fits

Here, the thing to seal is each software release and each deployment event. A release includes the build fingerprint, the release notes and the test results. A deployment event records which version was installed where and when.

Sealing happens at two points: when a release is finalised, and when it is deployed. The fingerprint, not the software itself, is sent to WitniumChain through the REST API, the SDK or the MCP server, and a witness ID comes back. The software and its logs stay on your systems.

Anyone you share the release record or deployment log with can check it by calculating the fingerprint again and comparing it with the sealed one. If it matches, nothing has changed since the day it was sealed. Change a single line in a config file or a test log and the fingerprint won't match.

What it shows is that a release record or a deployment log existed at a particular time, unchanged. What it doesn't show is that the version was free of defects, that the deployment went smoothly or that the software behaved as expected. It is not a guarantee of quality. It is a way to show which version ran when, in a form that is hard to argue with later.

How it would work

1. At release, seal the build fingerprint, release notes and test results.
2. At deployment, seal a record of which version went where and when.
3. If questioned, share the record and let the other side check the fingerprint.

The first 2,000 witnesses a month are free. After that, it is a few öre per witness.

What to watch

The proposed act is expected to enter into force on 9 December 2026, in line with the directive's deadline. ^[1] Once it does, every product placed on the market after that date falls under the new rules. For software, that means every release, every update and every new service.

The EU's Cyber Resilience Act, which also treats software as a product, sets its own reporting and documentation requirements from late 2027. ^[3] The two acts overlap but are not identical. One is about liability when something goes wrong. The other is about preventing things from going wrong in the first place. Both ask manufacturers to know what their software did, and when.