Britain Will Ask Who Pays When Insecure Software Gets Breached. Vendors Have a Year to Answer

For years, the British approach to insecure software has been to ask nicely. Codes of practice, guidance from the National Cyber Security Centre and voluntary pledges have told vendors what good looks like without making them pay when they fall short. The government’s budget documents, published on October 28, 2026, signal that this may change. The Treasury says the government “will consult next year on how to tackle insecure technology at source and consider where liability for cyber breaches should sit.”

It is one bullet point in a 166-page document, but it is the first formal commitment by a UK government to examine who should bear liability when insecure products lead to breaches. The Record, which first reported the pledge, noted that the lead department, the start date and the form of any regime are all still open. HM Treasury did not respond to its request for comment.

Why liability is back on the table

The pressure has been building inside government. Ollie Whitehouse, the NCSC’s chief technology officer, has argued for a “strategic policy agenda” on insecure technology. In 2025 he wrote that “we know how to build secure products and services” but “the business and commercial incentives to encourage adoption and sustainment of secure solutions are not sufficient.” That is the core of the liability argument: buyers cannot easily judge security, so the market does not reward it, so vendors under-invest.

Parliament has added to it. Last November, the House of Commons Business and Trade Committee said the lack of liability for software vendors was among the most pressing risks to Britain’s economic and national security, and urged ministers to make the NCSC’s voluntary software security code of practice legally binding. The economic case was sharpened by last year’s attack on Jaguar Land Rover, estimated to have cost the UK economy £1.9 billion.

What the consultation could cover

The budget links the consultation to an existing Law Commission of England and Wales review of product liability. That consultation opened on October 8 and runs until January 14. It proposes broadening the definition of “product” under the Consumer Protection Act 1987 to include software and AI systems, which currently sit in a legal gray area because the Act was written for physical goods.

Several routes are possible, and they are not mutually exclusive:

• Strict product liability for software. If software becomes a “product,” people harmed by a defect could claim without proving negligence.
• Statutory security duties for vendors. Turning the voluntary software security code of practice into law, with penalties for non-compliance.
• Extending the PSTI Act. The Product Security and Telecommunications Infrastructure Act has imposed basic security requirements on consumer smart device makers since 2024. It could be widened.
• Supply chain duties through the Cyber Security and Resilience Bill. That bill, now before the House of Lords, focuses on critical infrastructure operators and their suppliers and stops short of obligations on software developers in general.

The EU has already moved

Officials are expected to keep any new UK rules compatible with the EU’s regime, so vendors do not face two incompatible sets of requirements. The EU has gone furthest. Its Cyber Resilience Act lets regulators fine makers of insecure products up to €15 million or 2.5% of global turnover, whichever is higher, with main obligations applying from December 2027. Separately, the revised EU Product Liability Directive, which member states must transpose by December 2026, extends strict liability to software, including defects caused by missing security updates.

For companies selling in both markets, the practical question is not whether liability is coming but which version arrives first in which market. Businesses already working through EU rules on NIS2 and DORA will recognize the pattern: obligations that began with critical sectors are spreading to the supply chain.

The opposition

Moving liability to vendors will be contested. The Business Software Alliance, whose members include Microsoft, Oracle and Amazon Web Services, has lobbied against such measures, arguing they would stifle innovation. The United States has debated software liability for years without settling on a standard of care, and the current administration has rolled back several earlier secure-software requirements for federal suppliers. A UK regime aimed at mostly US vendors could become a trade irritant.

The money in the same budget

The liability pledge sits alongside £154 million in new funding for cyber defenses. The largest share, £70 million, goes to a National Exposure and Real-Time Vulnerability Centre at the NCSC that the budget says will use AI to identify vulnerabilities across critical infrastructure and the wider economy. A further £60 million supports the first phase of an NCSC capability using agentic AI to find and fix weaknesses across government networks. Separately, £40 million will set up a National Agentic Security Unit to detect and respond to rogue AI agents, and the AI Security Institute receives £120 million over four years.

The juxtaposition is telling. Government is spending to find flaws faster, while also asking whether the companies that ship them should pay for the consequences.

Six steps for software buyers and vendors

None of this is law yet. But the direction is clear enough to act on, and most of the steps below are good practice anyway.

1. Know what you ship. Maintain a software bill of materials for each product so you can answer, quickly, whether a given vulnerability affects you.
2. Commit to an update period. Missing security updates are already a defect under the EU directive. Decide and publish how long each product will be supported.
3. Document secure development. If a duty of care arrives, the evidence will be your design reviews, testing records and patch timelines. NIST’s work on update practice, covered in our piece on NIST’s patching revisions, is a useful reference.
4. Revisit contracts. Buyers should look at security warranties, notification duties and liability caps in vendor agreements now, before a statute changes the default.
5. Cover AI components. The Law Commission proposal includes AI systems. Inventory where AI is embedded in products and what controls apply. Our guide to what AI governance software should do sets out the record-keeping involved.
6. Respond to the consultations. The Law Commission consultation closes January 14. The Treasury-led one will follow next year.

Where privacy and security meet

Breach liability is usually framed as a security problem, but much of the harm is privacy harm: exposed personal data, notification costs, regulatory fines. Captain Compliance works with privacy and legal teams on vendor assessments, incident response planning and the records that show what data a supplier receives. Those steps do not shift legal liability, but they make it much easier to show what you knew, when, and what you did about it.

Frequently asked questions

Has the UK made software companies liable for breaches?

No. The budget commits to a consultation next year on where liability should sit. No rules have been proposed yet.

Which department will lead?

That has not been announced. The Law Commission review is sponsored by the Department for Business, Innovation, Science and Trade, while national cyber policy sits with the Department for Culture, Media and Sport.

Is the Law Commission consultation the same thing?

It is related. It runs until January 14 and proposes treating software and AI systems as products under the Consumer Protection Act 1987. The budget says the new work will build on it.

How does this compare with the EU?

The EU already has the Cyber Resilience Act, with main obligations from December 2027, and a revised Product Liability Directive covering software. UK officials are expected to aim for compatibility.

Whitehouse’s argument has always been that the market knows how to build secure software and chooses not to pay for it. A liability regime would change that calculation by putting a price on the choice. The consultation will decide who pays it, and the software industry has a year to make its case that it should not be them.