Segmentation without identity still leaves the organisation guessing which device is allowed to connect. Attackers can exploit weak credentials or unmanaged endpoints inside a segment, and operators may compensate with overly broad exceptions. The result is containment that looks strong on paper but fails during an intrusion.
Why This Matters for Security Teams
In OT environments, segmentation is often treated as a substitute for trust, but network boundaries alone do not answer the most important question: which device, workload, or operator is actually allowed to act. That gap becomes dangerous when service accounts, PLC interfaces, historian feeds, or remote maintenance tooling are present inside the segment. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, and 90% of IT leaders say proper NHI management is essential to zero-trust success in the Ultimate Guide to NHIs.
Zero Trust guidance from NIST SP 800-207 Zero Trust Architecture is clear that location on the network should not be the primary trust signal. In OT, that matters because once an attacker lands inside a segmented zone, flat assumptions about internal trust can let weak credentials, unmanaged endpoints, or forgotten vendor accounts move laterally with little resistance. In practice, many security teams encounter segmentation failures only after an incident reveals that the segment was isolated, but not truly governed.
How It Works in Practice
Strong segmentation should be paired with identity controls that verify both the entity and the context of each request. For OT, that means treating network placement as one input, not the decision itself. Current guidance suggests combining asset-level segmentation with authenticated workload identity, short-lived credentials, and policy checks at connection time rather than allowing broad segment access based on IP ranges or static allowlists.
Operationally, this usually means:
- Using workload identity or device identity for machines, gateways, and automation tools, rather than shared secrets.
- Issuing just-in-time credentials that expire quickly and are revoked after the task or maintenance window ends.
- Applying policy-as-code to decide whether a device may connect based on identity, role, time, source, and command intent.
- Separating human remote access from machine-to-machine traffic so vendor sessions do not inherit implicit segment trust.
This model aligns with the Top 10 NHI Issues because the real weakness is not just overexposure, but unmanaged non-human identities that keep working long after the original purpose has ended. It also fits the incident patterns seen in the 52 NHI Breaches Analysis, where credentials, tokens, and service accounts are repeatedly used to pivot across trusted zones. These controls tend to break down when OT teams must preserve legacy availability for unmanaged devices that cannot support modern authentication or short-lived token flows.
Common Variations and Edge Cases
Tighter identity control often increases integration overhead, requiring organisations to balance segmentation simplicity against operational continuity. That tradeoff is most visible in legacy OT, where equipment may not support certificates, modern protocol wrappers, or per-session authentication. In those environments, best practice is evolving rather than settled, and compensating controls may be necessary while identity readiness improves.
One common edge case is third-party maintenance. A segmented zone can still be exposed if a vendor account, jump host, or remote access appliance has broad standing privilege. Another is protocol translation: if an HMI or gateway can authenticate, but downstream controllers cannot, trust can silently collapse at the weakest hop. Segments also fail when operators rely on broad exceptions to keep production running, because those exceptions often become permanent.
NHIMG guidance in the Ultimate Guide to NHIs — Standards is useful here: identity governance must support lifecycle control, not just initial access. For OT leaders, that means inventorying non-human identities, reducing standing privilege, and aligning access with runtime context before expecting segmentation to contain an intrusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Segmentation fails when non-human credentials are overprivileged or unmanaged. |
| NIST CSF 2.0 | PR.AC-4 | Identity-based access control is the missing layer behind network segmentation. |
| NIST Zero Trust (SP 800-207) | Policy Decision Point | Zero Trust requires runtime authorization, not reliance on network location. |
Require authenticated, least-privilege access for OT connections instead of trusting segment membership.
Related resources from NHI Mgmt Group
- What breaks when passkeys are synced without strong account recovery controls?
- What breaks when non-IT staff can manage identity tasks without lifecycle controls?
- What breaks when a public AI serving API can be reached without strong access controls?
- What breaks when microsegmentation is used without strong IAM controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
