AI Ransomware: UK Critical Infrastructure Warning
The UK warns AI could scale ransomware attacks on critical infrastructure by 2028. Learn what the forecast means and how operators can reduce risk.
AI Ransomware Is a Warning About Old Infrastructure, Not Magic
The UK's National Cyber Security Centre (NCSC) says an AI-enabled ransomware attack against critical infrastructure is "highly likely" by 2028. That framing can sound like science fiction: as if something new and unstoppable is rolling into town. The real takeaway is almost the opposite - AI could help attackers move faster and more efficiently through weaknesses that organizations have been living with for years.
In its 2026 State of the Cyber Nation report, the NCSC warns that hostile actors are likely to use AI to increase the scale and efficiency of ransomware, social engineering, and software vulnerability exploitation. NCSC chief executive Richard Horne also warned that AI could expose flaws that have been tolerated "for far too long," calling for an end to "tech on the cheap."
This isn't a prediction that an autonomous system will switch off Britain's power grid on a calendar date. It's a practical warning about speed and exposure: when finding a weakness becomes cheaper, neglected systems become easier targets. This article breaks down what the forecast does - and doesn't - say, why infrastructure operators face extra pressure, and what leaders can do now without treating AI like magic or a gimmick.
What does the UK warning actually predict?
The NCSC's forecast is about how attackers' capability and efficiency may grow - not about a totally new type of ransomware that can't be stopped. The agency says it's "highly likely" hostile actors will use AI within the next two years to scale operations that involve ransomware, social engineering, and exploiting software vulnerabilities. It then points to the risk to critical national infrastructure by 2028.
The distinction matters. Even with AI in the loop, attacks still rely on familiar building blocks: an exposed system, an unpatched flaw, stolen credentials, a believable phishing message, or the inability to contain an incident quickly. AI changes the economics of targeting and preparation. It doesn't remove the need for a path into the victim's environment.
A forecast is not a countdown
"Highly likely" is a risk assessment, not a guarantee that an AI-powered ransomware incident will hit a particular service on a set date. It also doesn't mean AI will independently pick targets, write perfect malware, and carry out an entire intrusion without human involvement.
What the guidance does usefully imply is simpler: adversaries are likely to automate more steps around attacks, and defenders may get less time between a weakness being found and it being used. A vulnerability that was once too obscure - or too expensive - for criminals to chase could become a more attractive option once tools help them scan, analyze, and adapt at scale.
Why infrastructure raises the stakes
Critical infrastructure isn't one single technical world. It includes the systems that keep energy, transport, communications, and other essentials running. Some setups rely on long-lived equipment, specialized software, and tightly controlled operating processes. Updating or replacing these systems often means safety checks, vendor constraints, and planned outages - not just a normal software update.
And the consequences go well beyond "restore from backups." Horne warned that leaders may have to explain to investors, employees, and customers why food wasn't available, power was out, or businesses failed. In other words: cyber risk can't be treated as only an IT matter or an entry in a ticketing system.
That's why the NCSC is pushing organizations to prepare for changes in scale and pace. The forecast should lead to practical questions, like: Which systems would cause the most harm if disrupted? What's reachable from the internet? How quickly could the organization contain an incident without creating a safety problem? Those answers tend to be more useful than debating whether every incident deserves the label "AI-powered."
Why does AI make old vulnerabilities more urgent?
The core change is acceleration. AI tools can support research, code analysis, and message generation - reducing time and effort for parts of an attack. If attackers can apply those capabilities across more targets, weaknesses that once stayed in the background can get attention sooner. The security problem isn't new; the volume and speed can change.
Horne's point is that many organizations have carried a kind of security debt: weaknesses that were tolerated because they seemed hard to find, difficult to exploit, or unlikely to rise to the top of a backlog. That trade-off becomes harder to defend if attackers can search more widely and cheaply. "We haven't seen it exploited yet" isn't the same thing as "it's safe."
Evidence is mixed, and that matters
There are signs that attackers are experimenting with AI, but that doesn't mean every group already has advanced capabilities. Google's Threat Intelligence Group said in May that it had seen cybercriminals use an AI model to find and weaponize a previously unknown flaw in an open-source administration tool, allowing them to bypass two-factor authentication. Google described it as the first confirmed instance of AI-assisted zero-day development seen "in the wild."
At the same time, a University of Cambridge study that looked at more than 90,000 threads on cybercrime forums - also published in May - found that most reported AI use was for spam and phishing rather than sophisticated attacks. That combination makes sense: a few higher-end cases can be real while broader use is still fairly basic.
For defenders, that's a reason to avoid both complacency and panic. You don't have to assume every attacker can produce zero-days with a chatbot. But you should assume that routine tasks - crafting convincing messages, adapting lures, sorting through information - can get faster and cheaper.
The pressure is on response time
If attackers can go from finding a weakness to using it quickly, slower patching and response processes become a bigger vulnerability. That doesn't mean every organization should blindly install every update the moment it drops. In industrial or safety-sensitive environments, an untested change can trigger its own outage or hazard.
It does mean teams need a clear method for assessing exposure, prioritizing fixes, and applying mitigations when a full patch isn't safe yet. That process should say who owns the residual risk, what compensating controls are in place, and when the decision will be revisited. A spreadsheet note that says "known issue" doesn't count as a control unless there's an actual owned decision behind it.
What should critical infrastructure operators do now?
The NCSC's recommendations point toward practical basics: spend on the right things and cut unnecessary connections. Horne urged organizations to invest properly, avoid connecting systems to the internet unless it's truly needed, and treat Cyber Essentials as a start - not the end of the story.
None of this is flashy, but it targets the conditions that make scaled attacks work. A good response is to fold security into the operating model: map the systems that matter, reduce exposure, keep recovery plans workable, and give someone authority to act when risks cut across teams.
1. Identify the systems whose failure matters most
Start with operational impact, not an asset list organized by device type. Map essential services and the dependencies behind them: identity systems, remote access, vendor connections, management consoles, backups, and the networks that link business IT to operational technology.
For each high-impact service, define:
- what must keep running, and how long it can tolerate disruption
- which systems and suppliers it depends on
- which connections are required for operation, support, or monitoring
- who can approve isolation or recovery during an incident
This effort often reveals dependencies that normal asset inventories miss. A system can be old and still critical. A vendor connection can be legitimate and still give an attacker a route in.
2. Reduce exposure before buying more tools
Review internet-facing services, remote access, administrative accounts, and vendor pathways. Remove connections that don't have a real operational purpose. Where access is needed, limit it to named users, approved devices, and defined time windows - and monitor it. Strong authentication helps, but it doesn't magically make an exposed or poorly governed system harmless.
Use Cyber Essentials as a baseline, then tailor the next steps to your organization's actual risk profile. A baseline can set minimum controls, but it can't replace assessment of legacy software, industrial equipment, or business-specific recovery needs.
3. Make vulnerability decisions explicit
Create a process that connects technical findings to operational priorities. For each serious weakness, record the affected asset, likely exposure, potential consequence, patch or mitigation plan, accountable owner, and the next review date. If a fix can't be delivered quickly, decide whether to isolate, monitor more closely, or restrict access through an upstream control.
The goal isn't to pretend every vulnerability will be fixed immediately. In real infrastructure environments, that promise can be unsafe or unrealistic. The goal is to prevent "we know about it" from turning into an ownerless, permanent state.
4. Test recovery under realistic conditions
Ransomware resilience is about whether the organization can restore essential operations - not just whether backup software exists. Make sure backups are protected from the same credentials and network paths as production systems. Then rehearse how you'll restore priority services, communicate with staff and suppliers, and operate safely if parts of the environment need to be isolated.
Recovery testing tends to uncover the stuff plans forget: unavailable credentials, undocumented configuration, vendor response delays, or restoration steps that require access to a compromised network. Fixing those issues ahead of time is usually cheaper than discovering them during an incident.
Are the UK's new investments enough to change the risk?
The UK government has announced funding aimed at improving national cyber resilience. Reported measures include £60 million for the first phase of a national Cyber Shield, £70 million for a National Exposure and Real-Time Vulnerability Centre to identify weaknesses across critical infrastructure, and a new AI Cyber Security Centre of Excellence in Manchester, run by the NCSC.
Those are signals that government is paying attention, but announcements aren't the same thing as operational outcomes. A vulnerability centre can help identify exposure; it can't patch privately operated systems. A national programme can improve visibility and coordination; it still can't replace the local expertise needed to judge whether a change is safe in a live environment.
What national programs can do well
A national capability can help build a shared picture of risk, spot patterns individual operators might miss, and coordinate responses when vulnerabilities affect multiple organizations. The value increases when the findings reach the people who can act - backed by enough context to prioritize changes rather than generate another alert for an already overloaded queue.
The same goes for an AI cyber security centre. Its practical impact will depend on whether it helps defenders understand how AI shifts attack and defense workflows, tests tools responsibly, and turns research into guidance that can actually be deployed. Just slapping "AI" on a programme doesn't automatically reduce operational risk.
What operators still own
Infrastructure organizations still own their architecture, their vendor relationships, their access decisions, their patch windows, and their incident plans. They also have to manage the trade-off between availability and security. Cutting connections can reduce remote exposure, but it can also break monitoring or support if dependencies weren't properly mapped.
For executives, that makes this as much a governance issue as a technical one. If a known weakness can't be fixed, leaders should understand why, what limits exposure in the meantime, and what business impact remains. That's what a real risk decision looks like - rather than treating security as an endless backlog the IT team is supposed to work through.
Horne's warning about "tech on the cheap" ultimately comes down to cost of delay. Underfunded maintenance and deferred replacement can leave organizations with fragile systems, limited safe options, and expensive recovery. Spending more isn't automatically the answer; spending on controls and capabilities that reduce exposure and improve recovery is.
Conclusion: treat AI as an accelerator
The UK's warning isn't that AI invented cyber risk. It's that AI could make familiar weaknesses easier to find and exploit at scale, while many critical services still depend on systems that are hard to update or replace.
Operators should focus on the parts they can control: know what matters, reduce unnecessary exposure, make vulnerability decisions explicit, and test whether essential services can recover. Government funding can improve shared visibility and coordination, but it can't make those local decisions for each organization.
Treat AI as an accelerator of existing risk. The right response isn't panic or rushing to buy another tool. It's stopping the assumption that vulnerabilities will stay obscure - and building systems that can hold up under faster, more persistent pressure.