Zero trust is the right answer to the wrong question in OT environments. The right question is not “how do we implement zero trust?” It is “which zero trust principles survive contact with operational technology, and which ones will break your control systems if you try?”
The framework that arrived from the wrong direction
Zero trust architecture has become the dominant security paradigm in enterprise IT. The core principle , that network location is not a basis for trust, that every access request must be explicitly authenticated and authorised regardless of where it originates , is a genuine architectural improvement over the perimeter security model it replaces. The perimeter model assumed that everything inside the network boundary was trustworthy. Zero trust assumes nothing is trustworthy until proven otherwise. For enterprise IT environments, where the network boundary has dissolved under the pressure of cloud adoption, remote work, and mobile devices, zero trust is the appropriate architectural response.
The enterprise IT security community’s enthusiasm for zero trust has predictably generated pressure to extend it into OT environments. This pressure comes from several directions simultaneously: from IT security teams given responsibility for OT security who naturally reach for the frameworks they know, from vendors whose zero trust platforms are looking for new markets, and from executives who have heard “zero trust” described as the solution to their security problems and want to know when their OT environments will have it.
The pressure is not entirely wrong. Several zero trust principles apply directly and valuably to OT environments. But several do not , and the ones that do not are not merely inappropriate, they are potentially dangerous. Implementing zero trust mechanisms that conflict with the operational and safety requirements of control system environments is not a partial security improvement. It is an operational risk that can manifest as process disruptions, control system failures, and in the most serious cases, safety events.
This post is an attempt to do what vendor zero trust documentation never does: be honest about where zero trust works in OT environments, where it does not, and what the architectural response should be in the spaces where the framework breaks down.
Part 1: The zero trust principles , a precise inventory
Before assessing what transfers to OT, it is worth being precise about what zero trust actually consists of. The term is used loosely enough in vendor marketing that the underlying principles are sometimes obscured. NIST SP 800-207, the definitive US government reference for zero trust architecture, defines the core tenets clearly enough to provide a basis for OT applicability assessment.
The seven NIST zero trust tenets are:
1. All data sources and computing services are considered resources. Every device, service, and data store is a resource that must be authenticated before access is granted, regardless of whether it sits inside or outside a defined network boundary.
2. All communication is secured regardless of network location. Traffic between resources must be encrypted and authenticated, whether it traverses a private network, a cloud environment, or the public internet.
3. Access to individual enterprise resources is granted on a per-session basis. Access grants are time-limited and specific to the resource being accessed. There is no implicit continuation of access from one session to the next.
4. Access to resources is determined by dynamic policy. Policy decisions incorporate the identity of the requestor, the health state of the requesting device, and contextual signals including time, location, and behavioural patterns.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. Continuous monitoring of all assets provides the data that feeds the dynamic policy engine.
6. All resource authentication and authorisation is dynamic and strictly enforced before access is allowed. The policy decision and enforcement points are always consulted, never bypassed.
7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture. Telemetry from all components of the architecture feeds continuous improvement of the security model.
These seven tenets are the zero trust principles. The question for OT architecture is which of them can be implemented in control system environments without violating the operational and safety constraints that govern those environments.
Part 2: What transfers , the zero trust principles that apply in OT
Tenet 1 , All resources require authentication , transfers with adaptation.
The principle that every device must authenticate before it can access network resources applies directly to OT environments and represents a genuine security improvement over the legacy model in which devices on the OT network were implicitly trusted by virtue of their network location. OT devices that communicate over Ethernet-based networks , SCADA servers, historian systems, engineering workstations, modern PLCs with Ethernet interfaces , can and should authenticate using certificates or other cryptographic credentials rather than relying on network location for trust.
The adaptation required is for the large population of legacy OT devices , older PLCs, RTUs, field instruments , that have no authentication capability whatsoever. These devices communicate using protocols , Modbus RTU, serial DNP3, older proprietary protocols , that predate the concept of device authentication and provide no mechanism for implementing it. For this population, the zero trust principle of authenticated access cannot be applied at the device level. It must be applied at the network boundary: the network infrastructure , gateways, protocol converters, firewalls , that mediates access to these devices provides the authentication boundary, with the unauthenticated devices behind it treated as protected resources rather than trusted peers.
Tenet 2 , All communication is secured , transfers with significant qualification.
Encrypting and authenticating all communications is a sound principle for OT environments. Modern OT protocols , OPC-UA, DNP3 SAv5, IEC 61850 with TLS, DLMS/COSEM with security extensions , support encryption and authentication. New OT deployments should use these protocol variants as a baseline.
The qualification is for existing deployments using protocols that do not support encryption. Modbus, legacy DNP3, PROFIBUS, and many proprietary industrial protocols have no encryption capability. Retrofitting encryption to these protocols requires either replacing the devices with modern equivalents , expensive and disruptive , or deploying encrypted tunnels at the network level that wrap unencrypted protocol traffic between endpoints. Encrypted tunnels can introduce latency that is acceptable for some OT communication patterns and unacceptable for others. The qualification must be assessed protocol by protocol and communication path by communication path.
Tenet 3 , Per-session access grants , transfers for human access, not for device communications.
For human access to OT systems , operators accessing HMI workstations, engineers connecting to control system platforms, vendors accessing through the remote access jump host , per-session access grants with explicit time limits are not only applicable but essential. The remote access architecture described in Post 6 implements this principle: access is granted for a specific session, with defined duration and scope, and terminated on completion.
For device-to-device communications in the control plane , a PLC polling sensor values, a DCS communicating with field devices, an RTU reporting to a SCADA server , per-session access grants are architecturally inappropriate. These are continuous, deterministic communication relationships that operate on millisecond timescales. Introducing a session establishment and authorisation step into each polling cycle would violate the timing requirements of the control loop. The zero trust principle of per-session authorisation applies to human and application access; it does not apply to the continuous communication relationships of the control plane.
Tenet 6 , Authentication and authorisation always enforced , transfers for defined access points.
The principle that authentication and authorisation are always enforced and never bypassed is applicable and important for the defined access points in an OT environment: the remote access jump host, the OT DMZ boundary, the interfaces between IT and OT systems. Bypass mechanisms , persistent remote access tunnels, unauthenticated management interfaces, shared credentials that allow access without individual accountability , are exactly the vulnerabilities that this principle is designed to eliminate, and eliminating them in OT environments delivers real security improvement.
Part 3: What does not transfer , the hard limits
Tenet 4 , Dynamic policy based on device health , does not transfer to embedded OT devices.
Dynamic policy that conditions access on real-time assessment of device security health is one of the most powerful zero trust mechanisms in enterprise IT. An enterprise endpoint that is not running a compliant EDR agent, that has pending critical patches, or that has exhibited anomalous behaviour is denied access to sensitive resources until its health posture is remediated. This mechanism provides a continuous enforcement loop that keeps endpoint security posture aligned with policy.
For embedded OT devices, this mechanism is not implementable. A PLC running a real-time operating system on a microcontroller cannot run a health monitoring agent. Its firmware cannot be assessed for compliance with a patch management policy on a continuous basis because patching requires a planned maintenance window that may occur infrequently. Its behaviour cannot be evaluated against a behavioural baseline in the same way that an enterprise endpoint’s process execution and network connections can be.
Implementing device health-conditional access in OT environments , either by blocking communications from devices that fail health checks, or by applying restrictive policies to unverified devices , will deny access to devices that are functioning correctly but that cannot provide the health attestation that the policy engine expects. The result is not improved security. It is control system disruption.
The OT-appropriate substitute for device health-conditional access is out-of-band monitoring: passive observation of device behaviour through network traffic analysis and process telemetry, with anomalous behaviour triggering investigation and manual response rather than automated access denial. This is a weaker control than enterprise dynamic policy, but it is the control that is compatible with the operational requirements of the environment.
Tenet 5 , Continuous integrity and posture monitoring of all assets , does not transfer to Level 1 assets.
Continuous monitoring of asset integrity and security posture requires that assets provide telemetry that can be assessed for security-relevant state: patch level, configuration drift, software inventory, network connections. Enterprise IT assets , managed laptops, servers, cloud workloads , can provide this telemetry through endpoint agents, cloud APIs, and management frameworks.
Level 1 OT assets , PLCs, RTUs, field instruments, intelligent electronic devices , typically cannot. Their operating environments do not support telemetry agents. Their firmware is not inventoried through standard software management tools. Their network connections are not visible to enterprise endpoint monitoring frameworks. Attempting to instrument Level 1 assets for continuous security monitoring typically requires either replacing them with modern equivalents designed for monitoring or deploying additional hardware , protocol gateways, network taps , that adds complexity and potential failure points to the control system architecture.
For Level 2 assets , SCADA servers, HMI workstations, historian systems , that run conventional operating systems, a subset of enterprise monitoring capability is applicable. Software inventory, configuration monitoring, and network connection logging are achievable on Windows-based OT systems with appropriate tooling that has been validated for the OT environment. The caveat from Post 3 applies: every monitoring tool deployed to an OT system must be validated for compatibility with the control system applications running on that system before deployment.
Tenet 7 , Maximum telemetry collection for continuous improvement , does not transfer without operational validation.
The zero trust principle of collecting maximum telemetry from all components of the architecture to feed continuous security improvement conflicts with the OT principle of minimising traffic and system load on control system networks. Control system networks are designed for deterministic, low-latency communication of process data. Additional telemetry , security logs, monitoring agent traffic, vulnerability scan traffic , consumes bandwidth and introduces timing variability that can affect control system performance.
The resolution is explicit traffic budgeting: determining, for each monitoring mechanism deployed in the OT environment, what traffic it generates, when it generates it, and whether that traffic is compatible with the control system’s performance requirements. Monitoring mechanisms that cannot satisfy the traffic budget must be adapted , reduced polling frequency, scheduled collection during low-load periods , or replaced with passive collection mechanisms that do not generate any traffic on the monitored network.
Part 4: Microsegmentation in OT networks , a case study in framework translation
Microsegmentation , the zero trust practice of dividing networks into small segments with granular access controls between them, so that a compromise of one segment does not provide access to others , is one of the most valuable and most difficult zero trust mechanisms to implement in OT environments. It is worth examining in detail because the implementation challenges it presents are representative of the broader challenge of translating enterprise zero trust into OT contexts.
In enterprise IT, microsegmentation is implemented through a combination of network virtualisation, software-defined networking, and security group policies that are managed centrally and applied dynamically as workloads move between network locations. The management plane for microsegmentation , the system that defines and enforces segment policies , is itself a cloud or enterprise-hosted service. Changes to segmentation policy propagate automatically to all enforcement points without manual configuration.
In OT environments, several of these assumptions break down:
OT workloads do not move. The dynamic workload placement that makes software-defined microsegmentation valuable in enterprise environments , applications moving between compute nodes as load balances , does not occur in OT environments. A PLC has a fixed IP address, a fixed set of communication relationships, and a fixed position in the network topology. Microsegmentation in OT is static, not dynamic, which means it can be implemented with traditional firewall and VLAN controls without the software-defined networking infrastructure that enterprise microsegmentation requires.
The management plane cannot reach into the OT network. Enterprise microsegmentation platforms manage enforcement points through a centralised control plane that communicates with agents or API endpoints on each segment boundary. In a correctly architected OT network, there is no management plane connectivity from IT systems into the OT supervisory zone. The enforcement points , the firewalls and switches at OT segment boundaries , must be managed through the OT change management process, not through an enterprise microsegmentation platform.
Change velocity is incompatible with dynamic policy. Enterprise microsegmentation policies change frequently as application architectures evolve and as security intelligence identifies new threats. In OT environments, network policy changes are engineering changes that go through formal change management processes with operational impact assessment and validation. Dynamic policy updates that are appropriate for an enterprise microsegmentation platform are inappropriate for an OT network where any change to traffic flows must be validated against operational requirements.
What OT microsegmentation should look like:
OT microsegmentation is more accurately described as OT zone segmentation: the explicit definition of network zones at each level of the Purdue hierarchy, with strictly controlled conduits between zones implemented through dedicated firewall infrastructure at each zone boundary. This is the zone-and-conduit model of ISA/IEC 62443 described in earlier posts in this series, which predates the zero trust framework but implements its core principle , that access between network segments is explicitly controlled rather than implicitly granted , through mechanisms appropriate to the OT environment.
Within the OT supervisory zone (Level 2), further segmentation by function , separating HMI workstations from engineering workstations from historian servers from batch management systems , provides the granular access control that microsegmentation is designed to achieve. This internal segmentation is implemented through managed switches with VLAN configurations that have been validated for compatibility with the specific traffic patterns of the OT environment.
The governance model for OT zone segmentation must be embedded in the OT change management process: changes to segmentation configuration are engineering changes, not network operations changes, and require the same assessment, approval, and validation that any other OT engineering change requires.
Part 5: Identity in OT , the specific challenge of machine identity
Zero trust is fundamentally an identity-centric architecture: the identity of every user, device, and workload is the basis for access decisions. In enterprise IT, identity management is a mature discipline with well-established tooling, standards, and processes. In OT environments, the identity challenge is qualitatively different , not merely less mature, but structurally different in ways that require different approaches.
Human identity in OT is manageable with adaptation. The identity of human users , operators, engineers, administrators, vendors , can be managed through OT-specific identity infrastructure: a separate Active Directory domain for OT systems, with its own lifecycle management processes, its own MFA requirements, and no trust relationship to the enterprise domain. This is the model described in Post 1 and Post 3, and it implements the zero trust principle of explicit identity-based access without the operational risks of enterprise identity integration.
Device identity for modern OT systems is achievable. Windows-based OT systems , SCADA servers, HMI workstations, historian servers , can be issued certificates and can participate in certificate-based authentication for network access. This provides cryptographic device identity that is independent of network location, implementing the core zero trust device identity principle for the portion of the OT estate that can support it.
Device identity for legacy embedded devices requires architectural substitution. For PLCs, RTUs, and other embedded devices that cannot hold certificates or participate in authentication protocols, device identity must be provided through architectural substitution: the network infrastructure that mediates access to these devices , the gateway, the protocol converter, the firewall , holds the device identity on the device’s behalf and asserts that identity in interactions with other systems. The unauthenticated device is protected within an authenticated perimeter rather than being itself an authenticated participant in a zero trust architecture.
This substitution is not a full implementation of zero trust device identity. It does not provide the granular, per-device identity that enterprise zero trust achieves for managed endpoints. But it provides a meaningful approximation , the segment containing the unauthenticated device is authenticated and access-controlled, even if the device itself is not , that is the maximum achievable given the constraints of legacy embedded OT hardware.
Workload identity in OT , a largely unaddressed challenge. Enterprise zero trust places significant emphasis on workload identity: the cryptographic identity of applications and services that communicate with each other, distinct from the identity of the infrastructure they run on. In OT environments, the concept of workload identity applies to the software components of control systems , the SCADA application, the historian service, the OPC server , but the tooling and standards for OT workload identity are not mature. OPC-UA’s security model provides a form of application-layer identity for OPC communications, but equivalent mechanisms do not exist for most other OT application communication patterns. This is an area where the OT security community’s work on standards and tooling is still catching up with the concept.
Part 6: The vendor conversation , what zero trust marketing does not tell you
Every major cybersecurity vendor is now selling “zero trust for OT.” The marketing narrative is that zero trust is the solution to OT security challenges, that their platform implements zero trust in OT environments, and that adopting their platform is the path to a zero trust OT security posture. This narrative deserves specific scrutiny.
What vendors typically mean by “zero trust for OT” is a subset of zero trust principles applied to the portions of the OT estate where those principles are most straightforwardly implementable: identity-based access control for remote access, certificate management for modern OT devices, network segmentation for OT zones. These are genuine security improvements and they are worth implementing. They are not, however, a full zero trust architecture for the OT environment. They address the IT-adjacent portions of the OT estate while leaving the control plane , the PLCs, the DCS, the field devices , largely outside the zero trust model.
What vendors do not tell you is where their zero trust platform breaks in OT environments. They do not tell you that their device health attestation mechanism will generate false compliance failures for PLCs that cannot run attestation agents. They do not tell you that their dynamic policy engine will introduce latency into OT communications that violates control system timing requirements. They do not tell you that their centralised management plane requires network connectivity from IT systems into the OT network that violates the architectural separation that the rest of your OT security programme is designed to maintain.
The right vendor conversation starts not with “how does your zero trust platform work?” but with “which components of your platform are compatible with OT operational requirements, and how has that compatibility been validated?” The vendor’s answer to the second question , whether they can provide specific validation evidence for specific OT platforms and protocols , is far more informative than their answer to the first.
Vendors who cannot answer the second question have not done the work to understand the OT environment. Their zero trust platform is an enterprise IT product with an OT marketing layer. It should be evaluated as such.
Part 7: A practical zero trust implementation roadmap for hybrid OT/IT
Given the preceding analysis, what does a practical zero trust implementation roadmap look like for an energy operator with a hybrid OT/IT environment? The roadmap I advocate follows a principle of starting where zero trust delivers unambiguous value without operational risk, and moving progressively toward the harder problems where the framework must be adapted rather than applied directly.
Phase 1 , Zero trust for human access (6-12 months)
Implement zero trust principles for all human access to both IT and OT systems: MFA enforced at the identity provider level, per-session access grants with time limits, session recording for privileged access, and device compliance requirements for managed endpoints. This phase does not touch the OT control plane and carries minimal operational risk. It eliminates the credential-based attack paths that are the most common entry point for adversaries targeting both IT and OT systems.
Phase 2 , Zero trust for IT/OT boundary (12-18 months)
Implement zero trust principles at the IT/OT boundary: mutual TLS authentication for all communications between OT DMZ systems and IT systems, certificate-based device identity for modern OT systems that can support it, per-session access grants for all cross-boundary application access. This phase hardens the most critical architectural boundary without touching the internal OT network.
Phase 3 , Zone segmentation within OT (18-30 months)
Implement explicit zone segmentation within the OT supervisory zone, with firewall-controlled conduits between functional zones and documented, minimal conduit rule sets. This phase implements the microsegmentation principle within OT using OT-appropriate mechanisms rather than enterprise zero trust tooling.
Phase 4 , Device identity for modern OT assets (24-36 months)
Roll out certificate-based device identity for Level 2 OT assets that can support it, integrated with the OT PKI infrastructure. Implement architectural substitution for legacy Level 1 devices. This phase extends zero trust device identity as far as the OT estate’s technical capability allows.
Phase 5 , Continuous monitoring and telemetry (ongoing)
Implement the monitoring and telemetry collection that supports zero trust’s continuous verification principle, adapted for OT constraints: passive network monitoring, OT-appropriate endpoint monitoring for Level 2 systems, and the anomaly detection capabilities described in Posts 4 and 9.
Conclusion: Zero trust as a direction, not a destination
Zero trust is a direction of travel, not a destination that can be reached and certified. In enterprise IT, the maturity of zero trust implementations varies enormously, and even the most advanced enterprise zero trust architectures are partial implementations of the full framework. In OT environments, the appropriate implementation of zero trust is more partial still , a selective application of the principles that deliver security value without operational risk, combined with OT-specific mechanisms that approximate the zero trust goals in the spaces where the enterprise framework cannot be applied directly.
The intellectual error to avoid is treating zero trust as a binary: either you have implemented zero trust or you have not. This framing, which is commercially useful for vendors who sell zero trust compliance assessments and certifications, does not produce good architecture. What produces good architecture is a clear understanding of which zero trust principles apply in your specific environment, which must be adapted, which cannot be applied, and what compensating controls address the security requirements in the spaces where the framework breaks down.
For a hybrid OT/IT energy operator, that understanding requires both zero trust expertise and OT operational expertise , and crucially, the willingness to let the OT operational requirements constrain the implementation rather than the zero trust framework constrain the operations. The architecture serves the operation. Not the other way around.
Key references and further reading
- NIST SP 800-207 , Zero Trust Architecture. The definitive US government reference for zero trust principles, the source of the seven tenets assessed for OT applicability throughout this post.
- CISA , Zero Trust Maturity Model , cisa.gov/zero-trust-maturity-model , CISA’s maturity framework for zero trust implementation, providing the enterprise IT baseline against which OT applicability is assessed.
- ISA/IEC 62443-3-3 , System Security Requirements and Security Levels. The OT security standard whose zone-and-conduit model provides the OT-appropriate implementation of microsegmentation described in Part 4.
- OPC Foundation , OPC-UA Security , The OPC-UA security model and its application-layer identity mechanisms described in Part 5.
- NCSC , Zero Trust Architecture Design Principles , ncsc.gov.uk/blog-post/zero-trust-architecture-design-principles , NCSC’s eight design principles for zero trust, with applicability considerations relevant to regulated environments.
- Forrester Research , Zero Trust eXtended Ecosystem , The Forrester framework that extends zero trust beyond network access to data, workloads, and automation , relevant to the workload identity discussion in Part 5.
- Andrew Ginter , Secure Operations Technology , The OT security architecture reference that predates the zero trust framework but implements its core principles through OT-appropriate mechanisms, providing the intellectual basis for the OT-adapted zero trust approach described throughout this post.
- SANS ICS , Applying Zero Trust to ICS/OT Networks , Practitioner guidance on zero trust implementation in industrial environments, with specific coverage of the embedded device identity challenges described in Part 5.
This post is part of an ongoing series on security architecture for critical infrastructure and energy systems. The next post examines OT asset inventory , the unglamorous foundational capability that every other security control depends on, and why building it in operational technology environments is substantially harder than it looks.
About the author: Infrastructure Architect with 14 years of experience spanning enterprise architecture, operational technology environments, and regulated digital infrastructure. Currently leading infrastructure architecture for a major energy operator. Holds CISSP certification. Previously Technical Director at a digital health startup. Views expressed are personal.