What breaks when IT and OT networks are not segmented?

Why This Matters for Security Teams

Segmentation is the control that keeps an IT intrusion from becoming an operational event. In OT environments, the stakes are not just data loss or endpoint cleanup. A flat network can allow ransomware, stolen credentials, or remote access abuse to cross from office systems into engineering workstations, historians, PLC adjacencies, and safety support services. The result is often ambiguity about what is clean, what is trusted, and what can be restarted safely.

This is why current guidance from NIST SP 800-207 Zero Trust Architecture matters even in environments that cannot adopt pure zero trust everywhere. It gives teams a way to reduce implicit trust, constrain lateral movement, and verify access at each boundary. NHIMG research on the Ultimate Guide to NHIs also shows why identity matters here: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which are often the paths attackers use to cross segmented and unsegmented zones alike.

In practice, many security teams discover segmentation gaps only after business IT access has already been used to reach systems that were assumed to be operationally isolated.

How It Works in Practice

Effective IT and OT segmentation is not just about drawing a network diagram. It requires enforcing one-way assumptions, tightly controlled conduits, and monitored choke points between enterprise networks and operational zones. The practical goal is to make every allowed path explicit, authenticated, logged, and minimal. That typically means separating business user access, engineering access, remote vendor access, and machine-to-machine traffic into distinct trust boundaries.

Security teams usually combine routing controls, firewall rules, application proxies, jump hosts, and identity-based access policy. In OT, best practice is evolving toward least privilege at the boundary rather than broad site-wide trust. The NIST Zero Trust Architecture model supports this by treating access as continuously evaluated instead of assumed. That matters because many OT assets cannot run agents, patch quickly, or tolerate aggressive scanning.

• Separate business IT, supervisory control, and safety-related networks into different security zones.
• Use a controlled jump point for admin and vendor access instead of direct reachability.
• Restrict protocols and ports to the minimum required for operations.
• Log and review identity events for service accounts, remote sessions, and privileged actions.
• Validate backups, restoration steps, and manual fallback procedures before an incident.

Segmentation is especially important for non-human access. Service accounts, API keys, and automation tokens often bridge systems silently, so they need the same boundary discipline as people. NHIMG’s Schneider Electric credentials breach coverage is a useful reminder that credential exposure can become a cross-environment problem when trust boundaries are weak. These controls tend to break down when legacy OT protocols, shared engineering accounts, and remote maintenance exceptions all coexist in the same routed network because implicit trust replaces enforceable policy.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance safety, uptime, and vendor support against reduced blast radius. That tradeoff is real in plants, utilities, and continuous-process environments where every boundary can affect troubleshooting speed or production changes.

There is no universal standard for how much isolation is enough. Current guidance suggests using risk-based zoning rather than assuming that “air gapped” or “firewalled” automatically means secure. Some environments can support strict separation, while others need carefully governed exceptions for historians, patch staging, remote diagnostics, or safety monitoring. The key is to document every exception and treat it as temporary unless a business case says otherwise.

Identity is often the hidden failure point. If an OT zone is technically segmented but a shared admin credential works everywhere, the segmentation is only partial. The same is true when long-lived API keys, hardcoded credentials, or unmanaged vendor accounts are allowed to bypass boundary controls. NHIMG’s guide notes that only 5.7% of organisations have full visibility into their service accounts, which explains why many teams cannot prove containment until after a breach is already underway.

For asset-heavy environments, the practical question is not whether segmentation is ideal. It is whether the organisation can still operate when one zone is quarantined, because resilience planning only matters if the segmentation survives the first incident.

Related resources from NHI Mgmt Group

• What breaks when OT networks are segmented without strong identity controls?
• What breaks when AI-driven attackers reach OT networks before defenders can isolate them?
• Why does machine identity matter more in OT than in standard enterprise networks?
• What breaks when vendor remote access in OT is not tightly controlled?