How should security teams segment OT networks without disrupting production?

Why This Matters for Security Teams

OT segmentation is not just a network design exercise. In brownfield environments, every control change can affect uptime, safety systems, vendor access, and the deterministic traffic patterns that production depends on. Security teams often get this wrong by treating segmentation as a one-time perimeter project instead of a staged enforcement problem. Current guidance from NIST SP 800-207 Zero Trust Architecture supports gradual policy enforcement, but OT requires even more caution because legacy protocols and fragile dependencies limit what can be changed at once.

That is why NHI Management Group stresses identity-first containment and rollback-safe controls rather than brittle re-architecture. The operating model needs to preserve process continuity while shrinking east-west blast radius. The Ultimate Guide to NHIs — The NHI Market shows how pervasive non-human access has become across modern enterprises, which matters in OT where service accounts, engineering workstations, and remote support pathways can all become lateral movement paths. In practice, many security teams encounter segmentation failure only after a maintenance window, vendor session, or incident has already exposed an unmanaged trust path.

How It Works in Practice

The safest pattern is to segment OT by communication intent first, then by enforcement point. Start with a traffic baseline: identify which controllers, historians, HMIs, engineering stations, and remote maintenance channels actually talk to one another. Then define allowed east-west flows narrowly, using identity-aware policy where possible so that access is tied to a known workload, device, or session rather than only an IP range. That aligns with zero trust principles, but in OT the rollout usually happens in stages.

• Map critical assets and their required communications before enforcing blocks.
• Introduce passive monitoring or observe mode to validate the baseline without interrupting production.
• Apply allow-list rules one segment at a time, starting with low-risk paths.
• Use explicit exceptions for vendor support and maintenance, then review them frequently.
• Keep rollback procedures tested so operators can restore traffic quickly if a rule affects process stability.

This is also where identity governance matters. NHI Management Group research notes that organisations frequently struggle with secrets sprawl and over-privileged access, which is relevant in OT because unmanaged service accounts can quietly bypass segmentation intent. The Schneider Electric credentials breach is a reminder that credential exposure can undermine network controls if shared access paths are not tightly governed. Current best practice is to pair segmentation with strict authentication, least privilege, and logging at the enforcement point. These controls tend to break down when flat legacy networks depend on broadcast discovery, shared engineering credentials, or undocumented vendor tunnels because the production dependency graph is not fully known.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance blast-radius reduction against maintenance complexity and recovery speed. That tradeoff is especially pronounced in plants with mixed generations of PLCs, proprietary protocols, and third-party support contracts. There is no universal standard for this yet, but current guidance suggests starting with passive segmentation and moving to active enforcement only after traffic is well understood.

One common edge case is remote vendor access. Best practice is to avoid permanent broad access and instead gate support through time-bound, approved pathways with strong authentication and full session logging. Another is safety-related traffic, where over-segmentation can create unacceptable latency or visibility gaps. In those environments, policy exceptions may be necessary, but they should be narrowly scoped and regularly revalidated. The Ultimate Guide to NHIs — The NHI Market is useful here because it reinforces how hidden non-human access often expands faster than teams can document it. Security teams should also treat emergency access as a separate design case, not as a permanent back door, because incident recovery requirements are different from day-to-day operations.

Related resources from NHI Mgmt Group

• How should security teams apply zero trust to OT without disrupting operations?
• How should security teams implement microsegmentation in industrial environments without disrupting production?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?