Architecture

Zero Trust Architecture for Industrial Control Systems: What Works and What Does Not

July 15, 20259 min readBy Beacon Security Team

Zero Trust in Context

The term "Zero Trust" has been applied to enough products and frameworks that its meaning has become diffuse. For the purposes of this discussion, 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. 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 the concept of "inside" and "outside" has become blurred.

OT environments are different in ways that matter. But 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 in any IT environment. A device on the control network can, in most OT environments, 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. It is how to apply them given OT's specific constraints.

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. 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-delivered 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, this means:

  • Engineering workstations that initiate PLC logic downloads should have no network path to SCADA servers, historians, or IT systems
  • Safety systems should have no network reachability from DCS workstations or business network systems
  • Vendor maintenance zones should be isolated from process control zones and require 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.

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 verification that access is still warranted after it has been granted.

OT Privileged Access Management applies Zero Trust principles to address this:

  • Individual credentials for every person who accesses OT systems — no shared accounts for operators, engineers, or vendors
  • Access scoped to specific systems and specific operations based on job function
  • Time-limited access for vendor and maintenance activities, revoked when the work is complete
  • Session recording for all privileged operations to provide accountability and forensic capability
  • Just-in-time access grants that require explicit approval for sensitive operations like logic downloads

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 — certificates, 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. Applying these capabilities systematically is a meaningful step toward Zero Trust in OT.

What Does Not Translate — and Why

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 a 50-millisecond delay for an authentication check. A real-time control loop 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 processes. Security architects who apply enterprise Zero Trust patterns directly to OT real-time control loops will either break the control process or create a security architecture that the process will force everyone to override.

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 — verified once before continuous operation — is the practical limit.

Just-in-Time Provisioning for 24/7 Operations

Zero Trust's just-in-time access model — provision access only when needed, revoke when done — assumes that access provisioning and revocation can happen on the timescale of business operations. For the corporate network, this means hours or days. For an OT system where an operator needs to make a setpoint change at 3 a.m. during a process upset, the approval workflow cannot take 20 minutes.

OT access management must accommodate emergency access scenarios. This requires 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 — but the workflow must match operational realities.

Cloud-Based Identity Verification

Enterprise Zero Trust architectures often rely on cloud-based identity providers and policy engines for continuous verification. 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 that is incompatible with the availability requirements of most industrial processes.

OT Zero Trust implementations should rely on on-premises or locally deployed identity infrastructure, with cloud redundancy as a secondary option rather than a dependency.

A Practical Zero Trust Approach for OT

Rather than attempting to implement an enterprise Zero Trust architecture wholesale, OT organizations benefit from a principle-by-principle adaptation:

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 is the highest-return Zero Trust investment because it addresses the most commonly exploited attack vectors.

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 rather than automatic session termination.

The Realistic Outcome

A mature OT Zero Trust program will not look like the Zero Trust architecture your cloud security vendor demonstrates. It will be adapted, pragmatic, and designed around the primacy of safety and availability. 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 fundamentally more defensible architecture than the flat, perimeter-dependent model that most OT environments currently operate.


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.

Industrial infrastructure
OT Cybersecurity Experts

Your OT Environment Deserves
Expert Protection

IT security tools were not built for Modbus, OPC, or safety-rated controllers. Get a dedicated OT cybersecurity team that understands industrial protocols, control system architecture, and the operational constraints of your environment.

IEC/ISA 62443 Aligned
NIST 800-82 Compliant
OTCC Ready
ECC Aligned
Zero Operational Disruption