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

Why OT Crosses the Line From Perimeter Trust to Identity-Aware Access

In OT, the break point is not theoretical: once remote access, third-party support, or mixed legacy protocols are normal, a flat trust zone becomes too blunt to defend. The question is whether access decisions can still be tied to a known actor, session, and purpose, rather than to network location alone. That is the moment identity-aware access becomes the safer operating model.

Perimeter security assumes that being “inside” is a meaningful proxy for trust. In modern plants that assumption often fails because vendors, engineers, operators, and maintenance tools reach the same assets from different places and at different times. When the work pattern no longer matches the network boundary, access control has to move closer to the identity, the device, and the request itself.

Identity-aware access does not replace segmentation, monitoring, or engineering discipline. It adds an enforcement layer that can distinguish a technician’s approved session from a broad network permit, and it allows organisations to narrow access without blocking legitimate support. That shift is most important where uptime pressure tempts teams to over-share credentials or keep permanent pathways open “just in case.”

What Changes Operationally When Identity Becomes the Control Point

The practical change is that access is granted by who is connecting, under what conditions, and to what asset, rather than by where the connection originates. In OT, that usually means tighter control over vendor sessions, stronger authentication for remote maintenance, and more granular approval for privileged actions on HMIs, engineering workstations, and remote support jump points. The model is closer to OT and ICS Identity and Access Guide than to legacy perimeter thinking.

This transition is also an ownership change. Network teams can keep the pipes stable, but identity policy, approvals, and review cycles need business and OT stakeholders who understand which access is truly necessary. If identity controls are added without clear ownership, organisations often end up with two weak systems: a brittle perimeter and a noisy approval process that people work around.

Identity-aware access works best when it is paired with strong session control and lifecycle discipline. The same logic that supports Identity Security Programme Guide applies here, because the risk is not only whether access is authenticated, but whether it is consistently governed, reviewed, and removed when support ends or roles change.

When the Old Boundary Model Starts Failing in OT

The most common signal is not a breach, but repeated exceptions. If vendors need ongoing access, if plant teams share accounts to keep maintenance moving, or if a single trust zone spans assets with very different criticality, the perimeter is already being bypassed by business reality. At that point, the control objective changes from blocking the network to constraining the session.

Legacy protocol mix is another trigger. OT environments often contain systems that were never designed for modern authentication patterns, so the perimeter becomes a compensating control. That can work for a time, but it breaks down when remote diagnostics, distributed facilities, or cross-site support introduce access paths that the original network design never anticipated. A useful reference point is CISA Industrial Control Systems, which consistently treats OT segmentation and control as operational necessities rather than abstract policy goals.

The tipping point is also visible in governance evidence. If you cannot answer who accessed which asset, for what purpose, and under whose approval, then trust is still being inferred from topology. Once the environment requires that level of accountability, the organisation has already crossed into identity-aware access territory, even if the tooling has not fully caught up.

Risk and Threat Considerations

Perimeter-first OT security creates a broad blast radius when one remote channel, vendor pathway, or shared credential is misused. The main exposure is not just unauthorized entry, but the loss of session-level accountability, which makes it harder to separate legitimate maintenance from abuse or lateral movement.

Failure mechanism: A flat trust zone lets one approved pathway inherit too much reach, so a compromised vendor account, overbroad remote tool, or shared operator credential can expose multiple plants or systems.

Impact: Attackers or careless insiders can move from initial access to wider OT disruption, while defenders struggle to prove which actions were legitimate and which were not.

Practitioner Guidance

What to prioritise: Move first on the access paths that combine external connectivity and high operational privilege, especially vendor remote support, engineering access, and any session that can alter control logic or device configuration.

Decision rule: If a person or tool can still reach critical OT assets primarily because it is on the “right” network, treat that as a sign the boundary is too coarse and replace it with identity-bound access decisions.

What to verify: Confirm that every exception path has an owner, an approval rule, a revocation path, and a review cadence. If any of those are missing, the control is still perimeter-led even if identity tooling exists.

Practitioner takeaway: The move happens when access must be governed per session and per actor, not per subnet; at that point, perimeter controls become supporting infrastructure, not the decision-maker.

Related resources from NHI Mgmt Group

• What happens when organisations rely on perimeter security without identity-based access controls?
• Should organisations keep VPNs or move to identity-based OT access?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?