When should OT teams prioritise segmentation over more detection tooling?

Why segmentation should come before more detection in OT

In OT, segmentation becomes the first choice when the environment has legacy controllers, shared trusts, flat routing, or protocols that were never designed to be inspected cleanly. In those settings, more alerts do not stop lateral movement. Containment changes the attacker’s reach, which is often the only reliable leverage when endpoint visibility is limited.

Detection still has value, but it is weaker as a primary control when an attacker can operate through trusted tools, native admin channels, or unmanaged engineering paths. If an asset cannot host an agent or safely support deeper telemetry, the control strategy should start by shrinking the blast radius rather than adding more monitoring around the same exposure.

What segmentation does that detection cannot

Segmentation enforces who can talk to what, which means it can block paths that detection would only observe after the fact. That matters in OT because many environments have long-lived access relationships, vendor pathways, and legacy communications that are difficult to baseline. The practical effect is to turn broad implicit trust into explicit, reviewable communication rules.

A useful way to think about the trade-off is that detection improves awareness, while segmentation changes the attack surface. If remote access, engineering workstations, historian traffic, or controller-to-controller flows are too open, the best alert in the world still leaves the operator relying on response speed after movement has already started.

When to treat segmentation as the priority control

Prioritise segmentation first when one or more of these conditions are true: assets cannot run agents, the protocol stack is fragile or unauthenticated, downtime for tuning is expensive, or the environment includes zones with clearly different criticality. Those are signs that the strongest control is architectural, not observational.

That same logic applies when the main concern is reducing the consequence of compromise rather than proving every action in detail. In OT, limiting reach between business networks, operator tiers, and control layers often delivers more risk reduction per change than deploying another sensor that still depends on traffic interpretation and response staffing.

Risk and Threat Considerations

Flat OT networks create a containment problem, not just a visibility problem. Once an attacker or malicious insider has a foothold, trusted protocols and shared administration paths can let them move laterally faster than alerting can interrupt.

Failure mechanism: Overreliance on detection leaves existing trust paths intact, so compromise can expand across zones before defenders can confirm, triage, and act.

Impact: Segmentation failures can turn a single infected workstation, stolen remote-access credential, or vendor connection into broader plant disruption, unsafe command paths, or extended recovery time.

Practitioner Guidance

What to prioritise: Start with the traffic flows that create the largest blast radius, especially engineering access, remote support, and paths into control zones. If those flows are still broad, additional detection is usually compensating for an architectural gap rather than reducing it.

What to verify: Confirm that each permitted OT connection has a business or operational owner, a defined source and destination, and a clear reason it must remain open. If a rule cannot be justified in those terms, it is usually a candidate for tightening.

Decision rule: If a system is too fragile for agents, too important for uncertainty, or too exposed to trusted protocol abuse, segment first and instrument second. Detection should validate and refine the design, not substitute for it.

Practitioner takeaway: In OT, segmentation is the control that prevents movement; detection is the control that explains it. When visibility is constrained, prevention and containment deserve priority because they reduce the damage an attacker can do before anyone sees them.

Related resources from NHI Mgmt Group

• When should teams prioritise contextual classification over simple field detection?
• When should teams prioritise modern IGA over extending on-prem tooling?
• How do security teams decide whether to prioritise fuzzy hashing over signature-only detection?
• When should teams prioritise real-time anomaly detection over static verification checks?