They validate it against observed traffic, not just design diagrams. If live connections still cross intended boundaries, or if policy changes create unexpected reachability, the segmentation control is drifting and no longer reflects the operational network.
How to tell whether segmentation is still effective in a live plant
Segmentation is only working if the operational network behaves the way the policy says it should. In practice, that means validating real traffic paths, not relying on diagrams or switch configs alone. Security teams look for whether allowed flows stay inside the intended zones and whether anything new can reach across boundaries after changes, exceptions, or network drift.
The check is less about proving the design was good once, and more about proving the control is still reflected in production. That is why ongoing validation matters in industrial environments, where routing changes, remote access additions, temporary exceptions, and vendor support paths can quietly widen reachability over time.
For a broader segmentation baseline, Network Segmentation Guide covers the control intent behind zones, east-west restriction, and microsegmentation, which is the right starting point when teams need to compare policy to what the network actually allows.
What security teams should look for in the traffic itself
Operational validation starts with observing flows between assets, protocols, and subnets that should not talk to each other. If engineering workstations can still reach control networks, if business networks can initiate sessions into protected OT segments, or if east-west traffic bypasses the intended control point, the control is no longer behaving as designed.
The most useful signals are unexpected reachability, new peer-to-peer paths, and connections that survive policy changes that were supposed to tighten the boundary. Teams should also pay attention to control traffic that uses permitted ports but reaches unauthorized destinations, because segmentation failures often show up as policy-shaped exceptions rather than obvious firewall outages.
For OT-specific control expectations, NIST SP 800-82 Rev 3, OT Security Guide is useful because it anchors segmentation in industrial architecture and control-system realities rather than generic enterprise network assumptions.
What usually breaks segmentation over time
Segmentation usually fails through drift, not a single dramatic event. Temporary maintenance rules become permanent, a new firewall object broadens scope, a remote support tunnel is left over after commissioning, or an asset moves without the zone model being updated. In industrial environments, availability pressure can also encourage exceptions that are never revalidated.
That drift matters because the control may still appear healthy on paper while the live network has already changed. The practical question is whether the policy still matches actual reachability after every change, not whether the original design was sound. When a policy update unexpectedly opens a path, that is evidence the segmentation model needs to be reviewed as an operational control, not just an architecture artifact.
If you want the control logic that underpins this approach, NIST SP 800-207 Zero Trust Architecture is relevant because it treats trust as something that must be continuously verified, which aligns with validating segmentation against observed behavior.
Risk and Threat Considerations
When segmentation weakens, the immediate risk is boundary failure, but the bigger concern is blast-radius expansion. A path that should be blocked can let a compromised IT or vendor foothold move deeper into operational systems, and an exception that looked harmless during change approval can become a standing lateral movement route.
Failure mechanism: Policy drift, mis-scoped exceptions, or untracked connectivity changes create live paths that no longer match the intended industrial zone model, so the boundary is effectively weaker than the documented design.
Impact: Attackers or misbehaving systems can reach assets that should have remained isolated, increasing the chance of lateral movement, operational disruption, and wider compromise across plant and enterprise segments.
For industrial visibility and response context, CISA Industrial Control Systems is a useful reference point for sector guidance and defensive context around ICS environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Segmentation is an information flow control across zones and trust boundaries. |
| CM-2 — Baseline Configuration | Segmentation drifts when firewall and network baselines stop matching production. | |
| CA-7 — Continuous Monitoring | Live validation of segmentation depends on ongoing observation of actual traffic and reachability. | |
| Recommendation — Enforce AC-4 so only approved industrial traffic can cross defined boundaries. Maintain CM-2 baselines for segmentation rules, zones, and allowed pathways. Use CA-7 to continuously verify that production flows still match the intended segmentation. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Segmentation depends on controlled network paths, boundary devices, and change discipline. |
| CIS-13 — Network Monitoring and Defense | Observed traffic is the evidence source for whether segmentation still works. | |
| Recommendation — Apply CIS-12 to manage network boundaries and review connectivity changes. Use CIS-13 to monitor east-west traffic and flag unexpected cross-zone reachability. | ||
Practitioner Guidance
What to verify: Treat segmentation as validated only when observed flows match the policy after normal operations, maintenance activity, and recent change windows. If you cannot explain why a cross-zone connection exists, assume the control needs review before you assume the traffic is acceptable.
What to prioritise: Focus first on paths with the highest operational blast radius, such as remote access, engineering workstations, historian interfaces, jump hosts, and any rule that was added for a temporary reason but still remains active.
Practitioner takeaway: The right test is not “does the design look segmented?”, it is “can we still prove the live network respects the boundary when traffic, exceptions, and plant changes are taken into account?”
Related resources from NHI Mgmt Group
- How do security teams know whether a telnet exploit is actually working in the environment?
- How do teams know if OT segmentation is still working?
- How do security teams know whether privileged classification is still working?
- How do security teams know if identity-based segmentation is actually working?