Protecting essential digital systems is no longer just about stopping malware. In the UK, critical information infrastructure protection is really about keeping energy, water, health, transport, and digital services running when attackers, suppliers, or ordinary failures hit the parts of the stack nobody sees. In this article, I map out what is actually in scope, why the threat picture has sharpened in 2026, which controls do the real work, and how the UK regulatory model is changing around all of that.
The short version is that resilience matters as much as prevention
- The UK focus is on essential services, not every IT asset in an organisation.
- The biggest risks in 2026 are state-linked pressure, ransomware, identity compromise, supplier exposure, and weak recovery.
- Good protection is layered: governance, identity, segmentation, monitoring, and tested restoration.
- The current NIS regime still matters, but the direction of travel is wider scope and stronger accountability.
- Recovery planning is not optional because public services have to keep functioning even when prevention fails.
Which systems are actually in scope in the UK
When I look at this topic, I do not start with servers or product names. I start with services. In the UK model, the real question is whether a system supports an essential function that people and businesses depend on every day. That includes the obvious sectors, but it also includes the supporting digital layers that make those sectors usable.
| Sector or service | Typical systems | Why compromise matters |
|---|---|---|
| Energy | Grid control, substations, telemetry, billing, monitoring | Outages, safety risks, and loss of operational control |
| Water | Treatment sensors, pump control, quality monitoring, customer systems | Service disruption and possible safety or quality issues |
| Health | Patient records, diagnostics, device networks, scheduling | Delayed care, cancelled procedures, and patient harm |
| Transport | Signalling, traffic management, ticketing, operational control | Disruption at scale and potential safety consequences |
| Digital infrastructure | DNS, internet exchange points, cloud platforms, identity services | Cascading failure across multiple sectors at once |
The important distinction is this: the protected asset is usually a service chain, not a single device. A hospital, for example, depends on authentication, records, imaging, network access, clinical devices, backup power, and vendors that may never appear on a traditional asset list. That is why the UK framework uses an all-hazards, risk-based view rather than a narrow “patch the server and move on” model. Once the scope is clear, the harder issue is threat severity.
Why the threat is more dangerous in 2026
The pressure on critical infrastructure has not risen in a straight line; it has widened. More than 200 incidents affecting the UK’s critical infrastructure were handled in the year to May 2026, and roughly three-quarters were linked to state actors. That matters because state-linked campaigns behave differently from ordinary cybercrime: they are more patient, more strategic, and more willing to sit inside networks until the timing is useful.| Threat pattern | What it looks like | Why it matters |
|---|---|---|
| State-linked pre-positioning | Attackers quietly gain access and stay hidden | They can disrupt services later, at a chosen moment |
| Ransomware and extortion | Systems are locked, data is stolen, service is threatened | Time pressure pushes organisations into poor decisions |
| Identity compromise | Stolen credentials, token theft, session hijacking | One account can become the shortest path to critical systems |
| Supplier compromise | A vendor with deep access is breached first | The attack lands through a trusted relationship |
| OT and legacy exposure | Older operational technology is tied to modern IT | Physical processes can be affected, not just data |
I also think the role of AI is easy to misunderstand. It does not explain every breach, and it is not the root cause of weak security. What it does do is lower the cost of reconnaissance, phishing, and exploit chaining, which means mediocre controls fail faster. In practice, the same old basics still decide outcomes: weak identity, flat networks, untested recovery, and slow response. That leads directly to the controls that actually hold up under pressure.
What strong defence actually looks like
The useful part of the UK’s Cyber Assessment Framework is that it treats cyber resilience as an outcome, not a checklist. It is built around four high-level objectives and 14 principles, which is a sensible structure for essential services because it forces organisations to think about what must be achieved, not just which boxes get ticked.
| Layer | What good looks like | Common failure mode |
|---|---|---|
| Governance | Board-owned service maps, clear risk appetite, named owners for each critical function | Security is left to IT and never tied to service continuity |
| Identity | Phishing-resistant MFA for admins, least privilege, device trust, regular access reviews | Shared admin accounts and password reuse |
| Segmentation | Separate IT and OT, restrict remote administration, control jump paths | Flat networks that let one compromise spread everywhere |
| Monitoring | Central logging, OT-aware detection, alert triage, threat hunting on critical assets | Logs exist, but nobody can see or act on them fast enough |
| Recovery | Immutable backups, tested restores, manual fallback procedures, realistic downtime planning | Backups are present but restoration has never been rehearsed |
| Supplier control | Access reviews, incident notification clauses, security evidence, offboarding discipline | Vendors are trusted by default and seldom revalidated |
If I had to reduce all of that to one rule, it would be this: do not let one compromised identity, one supplier, or one network path define the fate of an essential service. That is also why passkeys or other phishing-resistant authentication methods are worth serious attention for privileged access. The next question is how the UK rulebook is pushing organisations in that direction.
How the UK rulebook is shifting
In 2026, the legal picture is still moving. The current NIS regime covers operators of essential services and some digital services, but the proposed Cyber Security and Resilience Bill is meant to widen scope, tighten accountability, and pull more of the supply chain into view. The direction is not subtle: resilience is becoming a broader operational duty, not a narrow compliance exercise.
| Area | Current baseline | Direction of travel |
|---|---|---|
| Scope | Essential services and some digital services | More coverage for data centres, managed service providers, large load controllers, and designated critical suppliers |
| Supplier risk | Often handled contractually, with uneven depth | Stronger recognition that suppliers can be the entry point to critical services |
| Incident reporting | Reporting tied to significant disruption | More harmful breaches reported earlier, with initial notification within 24 hours and a fuller report within 72 hours once the measures are in force |
| Regulatory expectation | Appropriate and proportionate security measures | More explicit pressure to show resilience, not just intent |
That shift is sensible because the modern attack path rarely stops at the main operator. A managed service provider may have deep access. A data centre may hold core workloads. A supplier of a niche clinical or industrial service may quietly sit in the middle of a national dependency chain. The point is not that every organisation becomes a critical operator overnight; the point is that some dependencies are critical even when the vendor is not. And that is where many teams still make predictable mistakes.
The mistakes that keep causing preventable outages
I keep seeing the same weak patterns, and none of them are exotic.
- They treat compliance as the finish line. A control can pass audit and still fail in a real incident if it has never been tested under pressure.
- They map systems, but not dependencies. Knowing the server list is not the same as knowing what keeps the service alive.
- They isolate IT badly and OT even worse. Operational technology is the part that runs pumps, turbines, valves, signalling, and other physical processes; it needs stricter boundaries, not looser ones.
- They trust suppliers too much. Vendor access often outlives the contract, the need, and sometimes the security review.
- They assume backups equal recovery. If restores are slow, incomplete, or never rehearsed, the backup strategy is weaker than it looks.
The organisations that recover well usually do something unglamorous: they design for failure before failure happens. They know which systems can be degraded safely, which ones cannot, and how long the public can tolerate partial disruption. The fastest way to fix the gap is a short, ruthless prioritisation plan.
What I would do in the next 90 days
If I were responsible for an essential service, I would focus on a small set of moves that reduce real risk quickly rather than spreading effort across dozens of half-finished projects.
- Map the crown jewels. Define the exact services that cannot fail, the systems they depend on, and the supplier links that matter most.
- Cut privileged access down hard. Remove shared admin accounts, enforce least privilege, and make every remote privileged session individually traceable.
- Separate IT from OT properly. Tighten remote access, harden jump hosts, and make lateral movement materially harder.
- Test recovery in anger. Restore from clean backups, rehearse manual fallback, and measure how long the real service outage would last.
- Rework supplier controls. Ask for security evidence, tighten incident clauses, and decide what happens if a key vendor disappears for a week.
- Make monitoring operational. Logging is not enough; critical systems need alerting, triage ownership, and response playbooks that someone can actually follow at 2 a.m.
- Report in service terms. The board should see recovery time, exposure reduction, and dependency risk, not just patch counts and policy completion rates.
That is usually enough to move a programme from “we have security” to “we can survive a serious attack without losing the public service.” The final test is whether the system still works when several assumptions fail at once.
The resilience test I would use before signing off a service
Before I would call any essential service properly protected, I would want it to survive at least four things without full collapse: one compromised privileged account, one unavailable supplier, one degraded monitoring capability, and one lost network path. If it cannot do that, the programme is still too fragile.
The standard the UK is moving toward is not perfect prevention. It is service continuity under pressure, fast detection, controlled blast radius, and recovery that is realistic rather than theoretical. That is the real value of this topic: it forces security to become an operating discipline, not a slogan, and that is what keeps national infrastructure usable when the next serious incident arrives.
