When does segmentation stop being enough for an old industrial network?

Why segmentation eventually stops absorbing OT risk

Segmentation is still valuable in old industrial networks because it shrinks reachability and slows lateral movement. The problem is that many legacy environments retain trusted conduits that segmentation does not fully govern, such as vendor remote access, jump hosts, engineering workstations, shared admin paths, and removable media. If one of those paths remains open, segmentation reduces blast radius but does not remove the underlying exposure.

That is why segmentation alone becomes fragile when a vulnerable controller, HMI, historian, or engineering asset cannot be patched on a reasonable schedule. In that situation, the security question shifts from “Can the attacker get to it?” to “Can the attacker still send dangerous commands or move laterally once they do?”

What trusted paths usually defeat the design

Legacy OT environments often depend on trust relationships that were never built for modern threat conditions. A vendor VPN, a maintenance laptop, an internal file share, or a removable drive can bridge otherwise well-drawn zones. If those paths can reach the vulnerable system, an attacker may not need to cross the perimeter in the normal way at all.

Operationally, this is why segmentation should be treated as one layer, not a complete compensating control. The Network Segmentation Guide is useful here because the real question is not whether zones exist, but whether east-west paths, admin exceptions, and temporary access routes are actually constrained in practice. In many plants, the exception list is the control surface.

When organisations underestimate this, they often overvalue the diagram and undervalue the traffic that still crosses it. The OT Security Guide is the better mental model for this problem because OT security depends on zones, conduits, and command-aware control, not on segmentation as a standalone promise.

What has to replace segmentation-only thinking

If the asset cannot be patched, the practical goal is to constrain what an attacker can do after they reach it. That usually means inspecting OT traffic, limiting protocols and commands to the minimum required for operations, and tightening remote administration so that access is conditional, logged, and narrowly scoped. Visibility matters because you cannot protect what you cannot observe, especially in protocols that were designed for trust rather than rejection.

The next control layer is often asset-specific rather than network-generic. If the system is exposed through a small number of known conduits, then monitoring those conduits and the vulnerable asset’s command set is more useful than adding another VLAN boundary. The OT Asset Visibility Guide fits this need because compensating controls depend on knowing which assets, protocols, and paths are actually present.

External guidance reaches the same conclusion. NIST’s NIST SP 800-82 Rev 3, OT Security Guide and NIST SP 800-207 Zero Trust Architecture both reinforce that access should be verified continuously and reduced to the minimum needed for the task, while CISA’s Industrial Control Systems resources are the right reference point when you need current industrial guidance and advisories.

Risk and Threat Considerations

Segmentation fails when the attacker can ride a trusted path into the zone or abuse a legitimate internal foothold. In old industrial networks, that matters because one exposed maintenance path, one shared engineering account, or one unmanaged removable device can bypass the intent of the network design and put control logic or process availability at risk.

Failure mechanism: The weakness persists because segmentation controls reachability, but not the trust assumptions behind vendor access, privileged remote sessions, or protocol-level command authority. If those paths remain functional, an attacker can still interact with the vulnerable asset without needing to break the zone boundary in the usual way.

Impact: The likely result is reduced, not eliminated, exposure, with residual risk ranging from unauthorized configuration change to process disruption or downtime. In OT, that residual access can be enough to create safety, availability, or integrity consequences even when the perimeter itself appears well segmented.

Practitioner Guidance

What to verify: Confirm whether any trusted path can still reach the vulnerable asset, including vendor remote access, shared admin routes, jump servers, and removable media workflows. If any of those paths are valid, treat the system as exposed even if the surrounding network is segmented.

Decision rule: If patching must wait, move from segmentation-only thinking to compensating controls that inspect OT traffic and restrict allowable commands at the conduit or asset level. If you cannot inspect or constrain the actual protocol behavior, the control is probably too coarse to rely on.

What good looks like: The environment should show narrow, justified access paths, observable remote sessions, and protocol controls that block unauthorised commands while preserving the minimum needed operations. That is the point where segmentation becomes a useful support control rather than the only barrier.

Practitioner takeaway: Segmentation is a reachability control, not a vulnerability remedy, and in legacy OT the decisive question is whether any trusted path still lets an attacker act on the weakness.

Related resources from NHI Mgmt Group

• What breaks when network segmentation is based on old branch-office assumptions?
• What are the signs that network segmentation is too weak to stop an attacker from moving through an environment?
• Why do traditional firewalls and network segmentation tools often fail to stop ransomware spread?
• Why does network segmentation alone fail to stop identity based attacks?