OT network segmentation vs microsegmentation: which do you need?

In operational technology (OT), start with zone-based segmentation: separate the enterprise network, an OT DMZ, and the control levels, and allow only defined flows between them. Microsegmentation, which isolates small groups or single workloads, is a later step that needs asset identity and discovery that many plants do not yet have.

What does NIST say about OT segmentation?

NIST SP 800-82 Revision 3, the guide to OT security, says a good practice is to characterize, segment and isolate IT and OT devices. Devices can be grouped by management authority, level of trust, functional criticality, data flow or location. It suggests using a recognized model to organize the segments, such as the Purdue model, the ISA-95 levels, the three-tier industrial internet of things architecture, or a mix.

It also recommends a demilitarized zone (DMZ) as an enforcement boundary. Communications between the enterprise level and the operations management level should go through services in the DMZ, and since the DMZ touches outside environments, those services must be monitored and protected so an attacker cannot pivot into OT unnoticed.

Enforcement uses mapped data flows. The guide says organizations typically use mapped data flows to identify required communications, then configure those into the policy engines of switches, routers, firewalls or unidirectional gateways so only authorized communication passes.

What is microsegmentation, and how is it different?

NIST SP 800-215 describes microsegmentation as dividing an internal network, such as a data center or a cloud region, into isolated segments so traffic in and out of each can be monitored and controlled. Its main purpose is to prevent attack escalation. Small segments give better visibility and allow granular access control, which restricts lateral movement by someone who got in or by an insider.

The guide lists prerequisites that are easy to underestimate:

1. A unique identity for each application or service.
2. Trust in that identity: it should not be spoofable and should be continuously verifiable.
3. Discovery of application resources.
4. Segmentation of workloads into groups with the same security requirements.
5. Mapping logical groups to physical or virtual infrastructure.

It also explains why a traditional segment-based approach strains: policies use IP addresses and ports and apply to subnets, and keeping them in sync with changing locations is hard.

Why does this matter more in OT?

SP 800-82 Revision 3 points out that boundary devices between zones do not reduce lateral movement inside a zone. If a zone has fifty controllers and an engineering workstation, one compromised device can reach the rest. That is the gap microsegmentation targets.

But OT adds cautions. The same guide warns that intrusion prevention with automated responses can disrupt OT and suggests placing such units at higher levels, such as the DMZ interfaces. Monitoring tools on OT hosts should be added only if they do not harm performance or safety. A rule that blocks a control message by mistake is a safety event, not just an outage.

A constructed example

A water treatment plant has an enterprise network, a DMZ with a historian, and a control network with 40 controllers, two HMIs and an engineering laptop. Zone segmentation and a firewall between enterprise and DMZ are in place. The plant adds a second firewall between the DMZ and the control network, with five allowed flows from the data map. Later, a vendor laptop is plugged into the control network for maintenance. Zone rules do not stop it from reaching all 40 controllers. The next step is to isolate the engineering laptop's access to specific controllers, and block laptop-to-controller flows outside maintenance windows. That is a microsegmentation decision, made after the zones are stable.

How to check or apply this

1. Draw the data flows first. List who talks to whom, on which protocol, and why.
2. Assign each device to a level or zone using a recognized model.
3. Place a DMZ between enterprise and operations, and allow flows only through it.
4. Write allow rules from the data map and default to deny at each boundary, testing during planned downtime.
5. Identify the 5 to 10 highest-risk lateral paths inside zones: engineering workstations, remote access points, vendor laptops.
6. Add finer controls for those paths only, and test for safety impact before enforcing.
7. Monitor passively first, using taps or SPAN ports, before any blocking.

Quick check

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• NIST SP 800-215, Guide to a Secure Enterprise Network (secure enterprise networks guide)

Last reviewed: 18 October 2026.