Zero trust for OT security needs identity-aware enforcement

At a glance

What this is: This article argues that OT security needs identity-aware Zero Trust because broad remote access patterns and static perimeter controls leave legacy operational systems overexposed.

Why it matters: It matters to IAM and PAM teams because OT access has to be scoped, monitored, and enforced in ways that account for legacy protocols, human workflows, and resilience constraints.

Context

OT environments such as SCADA, PLCs, badge readers, and HVAC controllers were built for long-lived operation, not modern access governance. That makes broad remote access, implicit trust, and centrally enforced policy especially risky when availability and safety are part of the security requirement.

Zero Trust in OT is really an identity and enforcement problem as much as a network one. The article shows why access decisions must account for users, third parties, device context, and protocol constraints instead of assuming that VPN reachability equals authorised access.

Key questions

Q: What breaks when VPN-based remote access is the default for OT?

A: VPN-based access often grants broader network reach than the task requires, which expands the attack surface and makes lateral movement easier. It also tends to preserve standing access instead of limiting sessions to the maintenance window or emergency use case. The breakage is not just technical, it is governance failure through overexposure.

Q: Why do VPNs and static perimeters create risk in OT networks?

A: They create risk because they optimise for connectivity, not authorisation. Once a user or vendor is inside the tunnel, legacy OT systems often cannot apply modern, granular access checks on their own. The result is implicit trust across multiple systems, which is especially dangerous when operations depend on availability and a single compromised path can affect critical infrastructure.

Q: How do organisations know if zero trust controls are actually working?

A: They know the controls are working when they can inventory privileged identities, prove access is time-bound, and show that rotation and revocation happen on schedule. A healthy programme also has few manual exceptions and low workflow friction, because recurring bypasses are a sign that policy and operations are out of sync.

Q: When should organisations move from perimeter security to identity-aware access in OT?

A: They should move when remote access, third-party support, or mixed legacy protocols make broad trust zones too risky to defend. The tipping point is usually when static perimeters no longer match how work is actually performed, especially across plants, facilities, and vendors. At that stage, identity-aware access becomes a governance requirement, not an optional enhancement.

Technical breakdown

Why VPN-based OT access creates identity blind spots

VPNs were designed to create a reachable network path, not to express fine-grained access policy. In OT, that usually means a user or vendor lands inside a broad trust zone that is larger than the task they actually need to perform. Because many OT assets are legacy, non-federated, and protocol-specific, the access layer has to do the governance work that the perimeter never did. Identity-aware enforcement reduces exposure by binding access to the user, the workflow, and the target system rather than to a reusable tunnel.

Practical implication: replace broad remote access with scoped, identity-bound access paths for OT users and third parties.

What protocol-aware segmentation changes in OT

Protocol-aware controls matter because OT traffic is not uniform. BACnet, Modbus, and other industrial protocols carry different operational meanings than standard enterprise web traffic, so segmentation has to understand both topology and protocol intent. Micro-segmentation without protocol awareness can still leave unsafe communication paths open, while protocol-aware policy can constrain which endpoints, sessions, and commands are allowed. This shifts Zero Trust from a generic network concept to an operational control that reflects how plant and facility systems actually communicate.

Practical implication: enforce segmentation at the protocol and asset level, not just the IP or subnet level.

Why monitor-before-enforce is critical in disruption-sensitive environments

OT cannot tolerate trial-and-error policy changes in the same way a typical office network might. Monitor-before-enforce gives teams a way to simulate policy effects before blocking traffic, which is essential where latency, availability, and safety are part of the control objective. That approach also surfaces hidden dependencies, such as vendor support channels or maintenance workflows that would otherwise be broken by a hard cutover. In practice, the control is as much about change safety as it is about access restriction.

Practical implication: validate OT access policies in observe mode before turning them into blocking controls.

Threat narrative

Attacker objective: The objective is to gain broad, reusable access into operational systems so disruption or unauthorised control becomes easier to achieve.

1. Entry occurs through over-provisioned remote access paths such as VPNs or other persistent tunnels that expand trust far beyond the immediate task.
2. Escalation follows when an attacker or unauthorized user can reuse that broad access to reach multiple OT systems instead of a single approved workflow.
3. Impact is operational disruption, including ransomware effects, unauthorized access attempts, and reduced resilience across critical infrastructure.

Breaches seen in the wild

• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OT Zero Trust fails when identity is treated as an overlay instead of the control plane. In operational environments, the main problem is not simply network reachability, but who is allowed to reach which device, under what workflow, and with what operational context. The article makes clear that VPN-style access models are too coarse for that job. Practitioners should treat identity-aware enforcement as the core of OT Zero Trust, not an add-on.

Protocol-aware enforcement is the named concept that separates workable OT Zero Trust from generic segmentation. OT traffic is shaped by industrial protocols, not just IP addresses and ports, so policy has to understand operational intent as well as connectivity. That is why the combination of access policy, micro-segmentation, and protocol context matters more than perimeter replacement. Practitioners should align policy design to the actual command and session patterns of the plant or facility environment.

Resilience constraints change the governance standard for OT access control. Unlike many enterprise systems, OT cannot absorb uncontrolled latency, cloud dependency, or failed policy pushes without consequences. That means the governance test is whether access control can be enforced without disrupting operations. Practitioners should evaluate Zero Trust designs against continuity, not just against security theory.

OT Zero Trust is also a human coordination problem, not only a technology problem. The article correctly points out that operational teams resist controls that look like blockages to production. Security programmes succeed in OT when they are framed around safe workflows, auditability, and reduced overexposure. Practitioners should build shared ownership with OT stakeholders instead of imposing IT access logic onto industrial environments.

Identity-aware OT controls map directly to established access and network governance principles. The article’s model aligns with least privilege, zero standing trust for remote paths, and continuous verification of access context. The relevant governance point is that OT still needs the same control intent as enterprise Zero Trust, but with stricter operational safeguards. Practitioners should anchor OT access programmes in identity-bound authorisation and validated segmentation.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
• Read next: Zero Trust Identity Guide

What this signals

Protocol-aware OT access is becoming the practical test for Zero Trust maturity. The strategic question is no longer whether a plant or facility has a perimeter, but whether access decisions can reflect identity, protocol context, and operational workflow at the same time. Programmes that cannot do this will keep relying on compensating controls that leave too much implicit trust in place.

Zero Trust for OT creates a governance reset for remote access, not just a tooling change. Teams need to rethink vendor support, maintenance windows, and exception handling because OT workflows are often the exact places where broad access creeps back in. The reader-level signal is that access policy has to be designed around operations first and security second only in the sequencing, not in the outcome.

Zero standing privilege for OT remote paths is the right mental model. Persistent tunnels and standing remote entitlements are what expand blast radius in industrial environments. Access should exist only for the approved task, then collapse back to a non-access state before the next operational step.

For practitioners

• Define OT access around tasks, not tunnels Replace broad VPN reach with access rules tied to a specific user, device, workflow, and time-bounded maintenance window.
• Segment OT by protocol and asset criticality Build policy around industrial protocol behaviour and critical assets so BACnet, Modbus, and similar traffic only reaches approved endpoints.
• Use monitor-before-enforce for policy changes Run policy simulations before blocking traffic so you can identify hidden dependencies, remote support paths, and safety impacts.
• Align security and OT stakeholders on workflows Document who approves access, who owns the system, and what operational exceptions are allowed so security does not become an unmanaged veto point.

Key takeaways

• OT environments need Zero Trust designs that understand identity, protocol behaviour, and operational constraints rather than assuming enterprise perimeter logic will transfer cleanly.
• VPNs and static perimeters remain weak in OT because they over-provision access and can preserve broad tunnels that attackers or unauthorised users can abuse.
• The strongest control pattern is identity-aware, protocol-aware enforcement supported by staged rollout, simulation, and stakeholder alignment with OT operations.

Key terms

• Identity-Aware Enforcement: Identity-aware enforcement is policy decisioning that uses who the user is and which account or context they are using. For browser AI, it helps distinguish sanctioned corporate use from unmanaged personal sessions and applies different controls based on that distinction.
• Protocol-aware segmentation: Protocol-aware segmentation is the practice of restricting OT traffic based on the meaning and behaviour of industrial protocols, not just on network location. It helps prevent overly broad connectivity by ensuring only approved commands, endpoints, and session patterns are allowed across critical systems.
• Monitor-before-enforce: Monitor-before-enforce is a rollout approach where teams observe how a policy would behave before turning it into a blocking control. In OT environments, it reduces the risk of disruption by exposing hidden dependencies, vendor support paths, and safety-sensitive workflows before enforcement.
• Over-Provisioned Access: Over-provisioned access is entitlement granted beyond what a workload or identity genuinely needs. For NHIs, it often happens at deployment time to avoid service disruption, then remains in place because no one revisits the original assumption, creating unnecessary blast radius and audit blind spots.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.