Zero Trust in Context
Few terms in cybersecurity have been stretched further than "Zero Trust." At this point it has been applied to enough products, frameworks, and marketing decks that the concept can feel like it means everything and nothing simultaneously. So let's start with a definition worth working from.
For these purposes, Zero Trust Architecture refers to the design principles articulated in NIST SP 800-207: never trust, always verify; assume breach; enforce least-privilege access; continuously validate. The shift from perimeter-based security, where being on the right network segment implicitly grants trust, to identity-based, continuously verified access.
In enterprise IT, this model has proven compelling for good reason. The dissolution of the traditional network perimeter through remote work, cloud services, and mobile devices made the assumption of internal network trustworthiness untenable. Zero Trust provides a coherent architecture for environments where "inside" and "outside" have lost their meaning.
OT environments are different in ways that matter. But here is the thing: the core failure mode that Zero Trust addresses, implicit trust granted by network location rather than verified identity and authorization, exists in OT as acutely as anywhere. In most OT environments, a device on the control network can communicate with any other device on that network without authentication or authorization checks. The flat, trusted-by-location OT network is as much a Zero Trust problem as the dissolving enterprise perimeter.
The question is not whether Zero Trust principles apply to OT. They do. The question is how to apply them given OT's specific constraints, and where to stop before the cure becomes worse than the disease.
What Translates Powerfully to OT
Micro-Segmentation Beyond Perimeter Controls
The transition from perimeter-based to micro-segmented security is perhaps the most directly applicable Zero Trust principle in OT, and also the one that delivers the clearest security return. Traditional OT security concentrated controls at the IT/OT boundary while leaving the OT interior relatively flat. Once an attacker crossed the perimeter, via a compromised vendor connection, a phishing payload on an engineering workstation, or a USB-introduced infection, they could move laterally through the control network with minimal friction.
Micro-segmentation applies the Zero Trust principle that no segment of the network should implicitly trust any other. In OT terms: engineering workstations that download PLC logic should have no network path to SCADA servers or IT systems. Safety systems should have no network reachability from DCS workstations or business systems. Vendor maintenance zones should be isolated from process control zones with explicit, time-limited access grants for specific maintenance activities. PLCs should only receive control protocol traffic from authorized SCADA servers and engineering workstations, not from any device that happens to be on the same VLAN.
This is achievable with industrial firewalls, managed switches with ACL enforcement, and network architecture changes that do not require agents on PLCs or other constrained devices. It does not require a rip-and-replace of existing infrastructure.
Privileged Access Management for OT
Zero Trust's emphasis on least-privilege and continuous verification maps directly onto OT's privileged access problem. In most OT environments, a single domain account or shared credential provides broad access to engineering software, SCADA systems, and PLC programming tools. There is no concept of "this account can read process data but cannot modify PLC logic." There is no time-bounding of access. There is no record of who accessed what or when.
OT Privileged Access Management addresses this directly: individual credentials for every person who accesses OT systems; access scoped to specific systems and operations based on job function; time-limited access for vendors and contractors, revoked when the work is complete; session recording for all privileged operations; just-in-time access grants requiring explicit approval for sensitive operations like logic downloads. At Beacon Security, we consistently find that implementing individual credentials and session recording alone, before any of the more sophisticated PAM capabilities, changes the security posture of an OT environment significantly. Accountability is a powerful control.
Identity for Machines, Not Just People
Zero Trust's focus on identity-based access extends naturally to machine identities in OT. Engineering workstations, SCADA servers, and historian systems should authenticate to each other based on device identity, not just network location. An OT server that receives a Modbus command should, where the protocol supports it, be able to verify that the command originated from an authorized source.
This is more achievable in OT than it may appear. Newer PLC platforms from Siemens and Rockwell support TLS-based authentication for engineering connections. OPC UA's native security model includes certificate-based mutual authentication. Modern industrial firewalls can enforce connection policies based on device identity rather than just IP address. These capabilities are available today and applying them systematically is a meaningful step toward Zero Trust in OT.
What Does Not Translate, and Why
This is where the genuinely interesting nuance lives. Anyone selling you a Zero Trust solution for OT that does not acknowledge these constraints is either oversimplifying the problem or has not spent much time in a control room.
Continuous Verification for Safety-Critical Processes
Zero Trust's principle of continuous validation creates a serious problem when applied to safety-critical control loops. A safety function that requires a valve to close within 500 milliseconds of a high-pressure condition cannot tolerate an authentication check in that loop. A real-time control process cannot be interrupted by a token validation failure.
Continuous verification, as implemented in enterprise Zero Trust frameworks, periodic re-authentication, token expiration, session re-validation, is incompatible with the real-time, uninterruptible nature of industrial control. Security architects who apply enterprise Zero Trust patterns directly to OT control loops will either break the process or create a security architecture that operators will override the first time it gets in the way. Both outcomes are failures.
The adapted principle for OT: apply continuous verification at the access layer, connections to HMIs, engineering tools, historian access, where it is compatible with operational requirements. For real-time control communications at Levels 0 and 1 of the Purdue model, accept that session-based authentication at connection establishment is the practical limit. Verify once before continuous operation begins, rather than continuously during it.
Just-in-Time Provisioning for 24/7 Operations
Zero Trust's just-in-time access model assumes that access provisioning and revocation can happen on the timescale of business operations, hours or days for the corporate network. For an OT system where an operator needs to make a setpoint change at 3 a.m. during a process upset, a 20-minute approval workflow is not an option.
OT access management must accommodate emergency access scenarios. This means pre-authorized emergency access roles with additional monitoring and post-event review, rather than blocking access until an approval workflow completes. Zero Trust principles still apply, the access is logged, time-bounded, and reviewed after the fact, but the workflow must match operational reality. A security control that gets disabled under pressure is not a control.
Cloud-Based Identity Verification
Enterprise Zero Trust architectures often rely on cloud-based identity providers and policy engines. OT environments in many industrial sectors are intentionally designed to operate independently of internet connectivity, including during network disruptions. An OT access control system that depends on a cloud identity provider creates a single point of failure directly incompatible with the availability requirements of industrial processes.
OT Zero Trust implementations should rely on on-premises or locally deployed identity infrastructure. Cloud redundancy can be a secondary option, but it cannot be a dependency.
A Practical Zero Trust Approach for OT
Rather than attempting to implement an enterprise Zero Trust architecture wholesale, which would be both expensive and operationally disruptive, Beacon Security recommends a principle-by-principle adaptation that delivers meaningful security improvements at each phase.
Phase 1, Eliminate implicit trust at the IT/OT boundary and within OT zones. Implement segmentation that requires explicit policy decisions for every cross-zone communication. Audit all communications against documented justifications. Eliminate any "trust because you are on the network" access patterns.
Phase 2, Implement identity for human access. Individual credentials, MFA for remote access, and session recording for privileged operations. This delivers the highest return of any Zero Trust investment because it addresses the most commonly exploited attack vectors, at a cost that most organizations can absorb incrementally.
Phase 3, Apply device identity where protocol support allows. Enable certificate-based authentication on OPC UA connections, TLS on supported engineering software connections, and CIP Security on supported Rockwell controllers. Build toward a model where device identity supplements network location as an access criterion.
Phase 4, Extend least-privilege to operational functions. Define access roles that scope authorization to specific systems and specific operations rather than broad platform-level access. Implement PAM tools that enforce these scopes and record privileged sessions.
Phase 5, Continuous monitoring as the verification layer. For the control process elements where continuous re-authentication is incompatible with real-time operation, continuous monitoring of behavior serves as the verification proxy. Behavioral anomalies in control communications trigger investigation, not automatic session termination, which would be dangerous, but human review.
The Realistic Outcome
A mature OT Zero Trust program will not look like the Zero Trust architecture your cloud security vendor demonstrates on a whiteboard. It will be adapted, pragmatic, and designed around the primacy of safety and availability. It will have places where the enterprise model was modified to fit operational requirements, and places where it was set aside entirely.
But it will achieve the core Zero Trust objective: replacing implicit, location-based trust with explicit, identity-verified, continuously monitored access, at every layer where that is compatible with the requirements of the industrial process. That is a significantly more defensible architecture than the flat, perimeter-dependent model that most OT environments currently operate.
The nuance is the point, not a caveat. Getting this right means understanding both the principles and the constraints, and being willing to hold both at once.
Beacon Security provides OT security architecture design services, including Zero Trust adaptation for industrial environments, micro-segmentation implementation, and OT PAM program development. Contact us to design a Zero Trust approach suited to your operational constraints.
