Segmentation matters because attackers who gain an initial foothold can move laterally across flat networks and reach high value systems. In critical infrastructure, that can turn one compromised host into widespread disruption across energy, healthcare, or water operations. Containment reduces blast radius, improves recovery options, and helps teams preserve mission continuity during an attack.
Segmentation as the Boundary Between a Local Incident and a Systemic Outage
Segmentation matters because critical infrastructure rarely fails in a tidy, isolated way. If operational and enterprise networks are too tightly connected, one compromised workstation, remote access account, or vendor path can become a route into systems that support safety, continuity, and recovery. For sectors such as energy, healthcare, and water, the issue is not just preventing access, but preventing propagation from one zone to the next. CISA cyber threat advisories show how quickly defenders need to think about containment when attacker activity is already underway; segmentation is one of the few controls that can still limit the damage after the first foothold.
Well-designed segmentation also changes the defender’s problem. Instead of trying to protect every asset equally, teams can separate trust zones, constrain management paths, and preserve critical functions even when part of the environment is degraded. That matters because resilience is not only about stopping compromise. It is also about making sure essential services can continue, recover, or be safely shut down when needed. In practice, many infrastructure teams discover their segmentation gaps only after an intruder or misrouted connection has already crossed the first internal boundary.
How Segmentation Works When the Environment Is Mixed IT and OT
In critical infrastructure, segmentation is most effective when it reflects real operational dependencies rather than an abstract network diagram. The usual goal is to separate enterprise IT, supervisory systems, control networks, safety systems, and remote access pathways so that each zone has a narrow, deliberate set of communication routes. The value comes from reducing trust, reducing reachability, and making lateral movement harder even when one layer is compromised.
That does not mean building a perfect wall between every system. Some communications must exist for monitoring, patching, engineering support, identity services, and data export. The practical question is which flows are essential, which are temporary, and which are simply legacy convenience. A segmented design should make those decisions visible. If a protocol, port, or jump path is not required for mission operation, it should not remain open by default. Where remote support is necessary, access should be brokered through tightly controlled administrative paths rather than broad network reachability.
- Separate business systems from control and safety functions so compromise in one zone does not automatically extend to the other.
- Restrict east-west movement inside the environment, not just north-south internet exposure.
- Allow only documented traffic between zones, and treat undocumented flows as exceptions to be justified.
- Preserve monitoring and recovery paths so defenders can still observe and restore systems during an incident.
Segmentation also improves containment during maintenance and incident response. If teams can isolate a zone quickly, they can keep the rest of the plant or service running while investigating the affected segment. That is why EU NIS2 Directive matters here: it reinforces that resilience and control of systemic risk are not optional design preferences. The guidance breaks down when organisations treat segmentation as a one-time perimeter project instead of an operational control that must match changing dependencies, vendor access, and recovery needs.
Where Segmentation Helps Less Than Teams Expect
Tighter segmentation often increases operational overhead, requiring organisations to balance blast-radius reduction against latency, support complexity, and recovery speed.
Segmentation is not a substitute for asset visibility, identity control, or secure remote administration. A poorly governed exception can collapse the value of an otherwise strong design, especially when engineers create temporary routes that later become permanent. The same is true when segmentation exists on paper but shared credentials, flat administrative tooling, or unrestricted jump hosts still allow broad reach within the environment.
There is also a genuine trade-off between resilience and operability. In very complex environments, over-segmentation can slow patching, troubleshooting, and failover if teams cannot move information or manage devices efficiently. The practical answer is not to remove segmentation, but to define tiers of criticality and accept that some zones need more restrictive paths than others. Where consensus is weaker is on how much micro-segmentation is appropriate for legacy OT, because the best level of granularity depends heavily on equipment age, vendor support, and outage tolerance. The safest rule is to segment to the point where a compromise cannot readily become a site-wide or fleet-wide event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack surface, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1021 — Remote Services | Segmentation reduces attacker use of internal remote paths for lateral movement. |
| Recommendation — Hunt for and restrict internal remote service paths that enable lateral movement. | ||
| CIS Controls v8 | 14 — Network Monitoring and Defense | Network boundaries and zone flows are central to controlling movement and exposure. |
| Recommendation — Monitor zone-to-zone traffic and block undocumented communication paths. | ||
| NIST CSF 2.0 | PR.AC-5 — Network Integrity is Protected | Segmentation protects network integrity by limiting reachability across critical zones. |
| RS.MI-3 — Automated mechanisms are implemented to mitigate attacks | Segmentation supports containment when response actions need to isolate affected assets. | |
| Recommendation — Enforce zone boundaries that limit unauthorized internal connectivity. Use isolation controls to contain compromised segments during incidents. | ||
| NIS2 | Article 21 — Risk management measures | Critical infrastructure segmentation supports mandated resilience and operational risk measures. |
| Recommendation — Implement network segregation as part of documented risk-reduction measures. | ||
Practitioner Guidance
What to prioritise: Focus first on the paths that let an attacker or misconfiguration cross from user-facing systems into operations. If those paths remain broad, segmentation will not materially improve resilience.
What to verify: Confirm that every inter-zone connection exists for a stated operational reason, has an owner, and can be revoked without breaking essential service. If no one can explain a flow, it is probably a control gap rather than a requirement.
What practitioners underestimate: The highest-value benefit is often not prevention but containment. A network that can be safely isolated, monitored, and recovered zone by zone gives incident responders options that a flat environment does not.
Practitioner takeaway: Good segmentation is measured by how much of the environment can keep operating after one part is compromised, not by how many boundaries appear on a diagram.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
