In 2024, NCSC threat intelligence identified active nation-state reconnaissance against UK energy infrastructure. In 2025, two UK utilities disclosed significant intrusions that had achieved lateral movement into OT environments — stopped before causing physical process disruption, but with dwell times measured in weeks. In mid-2026, I'm seeing the results of those incidents in the security posture changes now being rushed through. Some of those changes are good. Many are IT security teams applying IT security patterns to OT environments, which is how you create a new class of problem while thinking you've solved the old one.
This article is about what zero-trust actually means when you're protecting Modbus RTU devices, DNP3 traffic, and IEC 61850 substations — not when you're protecting an enterprise Microsoft 365 estate.
01 Why the Purdue Model is failing and why it matters
The Purdue Enterprise Reference Architecture was designed in the 1990s to describe how OT networks should be structured in layers: physical process at Level 0, field devices at Level 1, control systems at Level 2, and corporate IT at Levels 3–5. The security model implicit in Purdue was hierarchical trust: each layer trusted the layer below it, and a clear demarcation point between OT (Levels 0–2) and IT (Levels 3–5) was enforced by a firewall.
Three things have broken that model. First, cloud connectivity: every modern SCADA system now has some form of external data connection for remote access, vendor support, or operational data analytics. The firewall is permeable by design. Second, IT/OT convergence: operational data is now business-critical, which means IT and OT teams are sharing infrastructure, and the neat Purdue boundary has dissolved in practice. Third, sophisticated adversaries: modern threat actors don't try to breach the firewall — they compromise an IT asset, establish persistent access, wait patiently, then move laterally into the OT environment when the IT/OT boundary has a gap they can use.
Modern threat actors don't try to breach the firewall — they compromise an IT asset, wait patiently, then move laterally into the OT environment. The Purdue model has no answer for an attacker who's already inside.
02 What zero-trust means in an OT context
The core zero-trust principle — "never trust, always verify" — sounds straightforward. The implementation in an OT environment is considerably more complex than in a corporate network, for three reasons specific to industrial environments.
First, OT devices were not designed with identity in mind. A legacy Modbus sensor doesn't have a certificate. It doesn't authenticate. It transmits on a schedule. Zero-trust for OT requires a device identity layer that doesn't exist natively — typically achieved through network-level device profiling, traffic pattern analysis, and policy enforcement at the network boundary rather than at the device itself.
Second, OT environments have very different availability requirements. In a corporate network, blocking a suspicious lateral movement attempt is always the right call — you might briefly disrupt a workflow, but you've contained a threat. In an OT environment, blocking a legitimate control message to a turbine control system could cause a production trip. Every blocking action needs to be evaluated against the operational consequence, which means the zero-trust policy engine needs to understand the operational topology, not just the network topology.
Third, change management in OT environments is extremely slow. You can't patch a PLC on a two-week cycle. You can't replace a legacy HMI because it's running critical industrial software that hasn't been requalified for a new OS. Zero-trust implementation has to work around the estate as it exists, not the estate you wish you had.
03 Principle one: Assume breach at every boundary
The first zero-trust principle for OT is the hardest mental shift for organisations coming from a Purdue background. Stop designing for a world where the perimeter holds. Design for a world where an attacker is already inside and is looking for their next hop. That means micro-segmentation of OT zones (not just OT vs IT, but control system by control system), continuous monitoring of all east-west traffic within OT zones, and a defined detection and response playbook for lateral movement within the OT network.
Practical implementation: deploy OT-aware network sensors (Claroty, Dragos, or equivalent) that understand industrial protocols and can detect anomalous traffic patterns within OT zones. Configure alerting for traffic that violates the defined communication baseline — a PLC that has never sent traffic to another PLC suddenly doing so is a very high-confidence indicator of lateral movement.
04 Principle two: Verify every connection at the OT/IT boundary
The OT/IT boundary is where most intrusions achieve their critical transition. Instead of a traditional firewall with port-based rules, implement an application-layer proxy that deep-inspects industrial protocol traffic. This means a device that understands the difference between a legitimate Modbus read request and an anomalous write command — and can enforce the distinction at the protocol level.
In deployments where we've implemented this pattern, the key design decision is whether to block anomalous boundary traffic or alert on it. Our recommendation: start with alert-only for 60 days to establish a baseline, then graduate to block. The alert-only phase will reveal legitimate operational traffic patterns you didn't know existed — the vendor VPN that connects monthly, the OEM remote access arrangement that Engineering set up three years ago and nobody documented. Blocking before you understand the baseline is how you cause operational incidents while trying to prevent security incidents.
05 Principle three: Least-privilege access to OT systems
OT access management is typically the worst-maintained part of the security estate in energy organisations. We routinely find shared credentials for HMI access, service accounts with domain admin rights that haven't been reviewed in years, and vendor remote access accounts that are technically active long after the project they were created for has ended.
Zero-trust access for OT means: individual named accounts for all human access (no shared credentials), time-limited access tokens for vendor and third-party access, privileged access workstations for all connections to control systems, and session recording for all remote access sessions into OT environments. This is technically straightforward — PAM vendors like CyberArk and BeyondTrust have OT connectors — but requires significant change management work to implement in organisations where engineers have been using the same shared credentials for ten years.
06 Principles four through six: continuous validation, OT-specific SIEM, and supply chain hygiene
Continuous validation means your zero-trust controls are assessed continuously, not annually. For OT environments, this means automated configuration compliance scanning (are the firewall rules still correct? have any new devices appeared on the OT network?), regular tabletop exercises against OT-specific threat scenarios, and integration of threat intelligence feeds relevant to industrial control systems (ICS-CERT advisories, Dragos and Claroty threat intelligence).
OT-specific SIEM is a separate investment from your corporate SIEM. The event types, correlation rules, and response playbooks for OT environments are completely different from those for IT environments. An IT SIEM trained on Windows event logs won't tell you that your DNP3 traffic has an anomalous master station address that indicates a spoofed control message. Deploy purpose-built OT SIEM, or configure a dedicated OT data plane in your corporate SIEM with OT-specific detection content.
Supply chain hygiene is the one that keeps me up at night. The SolarWinds and Colonial Pipeline attacks both exploited trusted third-party relationships. Every OEM, integrator, and managed service provider with access to your OT environment is a potential intrusion vector. Zero-trust supply chain means: vendor access via jump hosts with session recording, contractual requirements for OT security hygiene, and an annual review of all active third-party access to OT systems.
07 NIS2 and NCSC CAF alignment
UK operators of essential services are assessed against the NCSC's Cyber Assessment Framework (CAF), which covers four objectives: managing security risk, protecting against cyber attack, detecting cyber security events, and minimising impact. The six zero-trust principles above map directly to CAF objectives B (protection) and C (detection).
For NIS2 compliance (relevant to UK entities with EU operations or supply chains), Article 21 requires implementation of "appropriate and proportionate technical, operational and organisational measures" including network segmentation, access control, and incident reporting. A properly documented zero-trust implementation is strong evidence of NIS2 compliance — not exhaustive evidence, but the NCSC CAF and NIS2 requirements are substantially overlapping for OT security.
The four-phase implementation sequence
Phase 1 (months 1–2): OT asset discovery and communication baseline. You can't protect what you don't know exists. Phase 2 (months 3–5): OT/IT boundary hardening — deploy protocol-aware inspection and implement least-privilege access controls. Phase 3 (months 6–9): OT SIEM deployment and playbook development — 60-day alert-only baseline, then graduated to active blocking. Phase 4 (ongoing): continuous validation, threat intelligence integration, and annual supply chain review. Most organisations doing this for the first time should plan 12–18 months from start to a defensible zero-trust posture. Anything faster is probably missing something.