Why do mixed IT and OT environments break traditional segmentation assumptions?

Why This Matters for Security Teams

Mixed IT and OT environments fail for the same reason many segmentation programs fail: the network is being asked to enforce a safety decision it was never designed to make. In IT, a denied connection may trigger a ticket. In OT, the same denial can interrupt alarms, dosing, telemetry, or a production line. That difference means the control objective is not just confidentiality or containment, but availability, safety, and recovery under constrained maintenance windows. Current guidance suggests segmentation must be treated as an operational design problem, not a pure firewall rule exercise, especially when identities, remote access, and vendor support paths cross the boundary. The NIST Cybersecurity Framework 2.0 is useful here because it frames protection and recovery as coordinated functions rather than a single perimeter decision. NHIMG’s Ultimate Guide to Non-Human Identities is also relevant because most cross-domain traffic is driven by service accounts, APIs, and machine credentials rather than human users. In practice, many security teams discover segmentation failure only after an engineering change, vendor session, or emergency access path has already bypassed the intended boundary, rather than through intentional test of the design.

How It Works in Practice

Effective mixed-environment segmentation starts by mapping what actually needs to talk, when, and under what failure conditions. A flat “IT zone” and “OT zone” split is usually too coarse because historians, patch servers, jump hosts, identity systems, and remote support tools create legitimate dependencies that cannot simply be blocked. The better pattern is to classify traffic by function and criticality, then apply policy that reflects the operational tolerance of each path. That often means:

• Separating control traffic, business traffic, and vendor maintenance traffic into different trust paths.
• Using allowlists tied to exact ports, protocols, sources, and time windows instead of broad subnet trust.
• Constraining non-human identities with least privilege, short-lived credentials, and explicit ownership.
• Monitoring east-west movement for service accounts and machine tokens, not only human logins.

For identity-heavy environments, the security boundary is increasingly the workload identity itself. NHI controls such as lifecycle management, rotation, and revocation matter because a forgotten API key can cross segmentation without touching a human workflow. NHIMG’s research on Schneider Electric credentials breach illustrates how credential exposure can collapse a boundary that looked sound on paper. NIST’s Cybersecurity Framework 2.0 supports this by emphasizing governance, risk management, and response as continuous functions, not one-time network placement decisions. These controls tend to break down in plants with legacy protocols, shared engineering workstations, and vendor remote access because segmentation cannot easily distinguish essential command traffic from unsafe lateral movement.

Common Variations and Edge Cases

Tighter segmentation often increases operational friction, requiring organisations to balance blast-radius reduction against uptime, safety, and supportability. That tradeoff becomes sharper in brownfield OT environments where devices cannot be patched frequently, traffic patterns are poorly documented, and resegmentation may require shutdowns that the business cannot absorb. Best practice is evolving, but there is no universal standard for this yet: some teams favour microsegmentation around high-value assets, while others use compensating controls such as jump servers, protocol-aware gateways, and continuous identity checks. The right answer depends on whether the environment is a hospital, utility, manufacturing line, or hybrid data center, because the acceptable failure mode is different in each case. Two edge cases matter most. First, emergency access can invalidate elegant segmentation if break-glass accounts are shared, static, or broadly trusted. Second, third-party support often enters through exceptions that outlive their original approval. NHIMG’s Ultimate Guide to Non-Human Identities shows why this matters: machine identities outnumber human identities by orders of magnitude, so a single overlooked credential can become the real bridge between zones. The practical test is not whether IT and OT are separated on a diagram, but whether every dependency is provable, minimal, and revocable without stopping the operation.

Related resources from NHI Mgmt Group

• Why do agentic workflows break traditional IAM assumptions?
• Why do AI agents break traditional IAM assumptions?
• Why do workload identities break traditional PAM assumptions?
• Why do autonomous agents break traditional IAM assumptions?