OT Network Segmentation Basics (Operational Technology)

How it works

OT segmentation is both an architecture (how you lay out networks) and an enforcement model (how you permit and monitor traffic). The goal is to reduce “flat network” risk and create chokepoints where access can be inspected, logged, and restricted.

1) Start with zones (group assets by function and risk)

Most OT segmentation programs begin by defining security zones. A zone is a collection of systems with similar criticality and communication needs. Common zones you’ll see:

• Enterprise IT zone: email, ERP, identity services, corporate endpoints.
• OT DMZ (industrial DMZ): jump hosts, patch repositories, AV update relays, historians (sometimes), remote access gateways.
• Operations / supervisory zone: HMI, SCADA servers, engineering workstations (EWS), historians, OPC servers.
• Control zone: PLCs, RTUs, controllers, distributed I/O.
• Safety zone (if present): safety instrumented systems—often segmented even from the control zone.
• Vendor/remote access zone: segregated inbound access and tooling, ideally terminating in the DMZ.

A practical rule: if two systems don’t need to communicate for the process to run, they should not be able to communicate by default.

2) Define conduits (approved pathways between zones)

In IEC 62443 language, the controlled connections between zones are conduits. In practice, conduits are implemented with:

• Firewalls (often industrial firewalls) and ACLs
• Layer-3 segmentation (subnets/VLANs + routed boundaries)
• Application proxies and gateways (e.g., for remote access)
• Data diodes or one-way gateways (for strict unidirectional flow use cases)

Conduits should be explicitly allowlisted: source, destination, protocol, and port—and ideally with application-layer controls when feasible.

3) Enforce least privilege for OT traffic

Segmentation is effective when it’s paired with minimal, documented communication requirements, such as:

• HMI → PLC: only required industrial protocols/ports, only to specific controller IPs
• Engineering workstation → PLC: restricted to maintenance windows or via privileged access paths
• Historian collection: one-way or tightly controlled read-only data flows

This is the main “so what”: segmentation turns your plant network from “everything can reach everything” into purpose-built pathways that match operations.

4) Put an OT DMZ between IT and OT (almost always)

A typical foundational pattern is:

• IT ↔ OT DMZ ↔ OT

The OT DMZ provides a buffer so corporate systems never need direct connectivity to controllers. It’s where you place services that must exchange data with IT (reporting, patch staging, remote access termination, and sometimes replicated historians).

Avoid the common anti-pattern of “opening a few ports from IT to the HMI/SCADA VLAN.” That’s how ransomware and credential theft pivot into OT.

Practical access note: when remote access is required, terminate sessions into the DMZ via a hardened gateway, and back it with strong identity controls and a password manager for privileged accounts. If you need a mainstream option, 1Password is commonly used for operational teams to reduce shared credentials and improve rotation (Try 1Password →).

5) Micro-segmentation: go beyond VLANs when needed

Traditional segmentation uses VLANs and firewalls to separate networks. Micro-segmentation refines this by controlling traffic at a smaller scope (host-to-host or workload-to-workload), using:

• Host-based firewalls or agent-based policy (limited adoption in OT due to change control)
• NAC/802.1X (often challenging with legacy devices)
• Switch ACLs / private VLANs
• Asset-aware industrial firewalls that enforce per-device policies

In OT, micro-segmentation is most realistic for Windows-based OT systems (EWS/HMI servers) and cell/area zones (packaging line, robot cell, skid).

6) Monitor the boundaries (segmentation without visibility is fragile)

Segmentation works best when you can validate assumptions:

• NetFlow/IPFIX at key routing points
• Firewall logs + rule hit counts
• Passive OT network monitoring to baseline industrial protocol traffic
• Alerting on “new talkers,” lateral movement, and unexpected IT-to-OT attempts

A segmentation project should end with proof: known-good flows are allowed; everything else is blocked and logged.

Technical Notes: quick checks and examples

Below are examples you can adapt. Treat these as starting points—OT environments vary widely and changes must follow MOC (Management of Change).

Identify routes and VLAN interfaces (Linux router/jump box)

ip addr
ip route
bridge vlan show 2>/dev/null || true

Show listening services (Windows OT server)

Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Select-Object -First 50
Get-NetFirewallRule -Enabled True | Select DisplayName, Direction, Action

Find firewall rule “permit any any” and high-risk broad rules (conceptual)

Look for patterns in firewall configs/logs such as:

permit ip any any
permit tcp any <OT-subnet> any
src=10.0.0.0/8 dst=172.16.50.0/24 action=allow

Validate firewall rule usage (what’s actually being hit)

On many platforms, check rule hit counters and age. If a rule hasn’t been hit in months, it may be removable—after confirming with ops and safety stakeholders.

When you’ll encounter it

OT segmentation comes up anytime you need to connect, modernize, or recover safely in industrial environments. Typical triggers:

1) Ransomware resilience and incident response
After an IT ransomware event, leadership asks, “Can it reach the plant?” Segmentation is the answer that reduces blast radius and shortens recovery by limiting spread.

2) Remote access for vendors and maintenance
Remote connectivity is common (OEMs, integrators). Segmentation ensures remote sessions terminate in a controlled zone (often the OT DMZ) and don’t directly reach controllers.

3) New SCADA/HMI deployments or plant expansions
New lines, skids, or sites are the best time to design cell/area zones and standardized conduits before “temporary” flat networks become permanent.

4) Convergence and data projects (IIoT, analytics, cloud reporting)
Moving OT data to IT/cloud for analytics frequently pressures teams to open paths. Segmentation provides safe data egress patterns (replication, brokers, one-way flows).

5) Compliance, insurance, and audits
Requirements from IEC 62443-aligned programs, customer security questionnaires, or cyber insurance often ask for segmentation, OT DMZs, and restricted inter-zone traffic.

6) Legacy cleanup and tech debt reduction
Flat networks emerge from years of exceptions. Segmentation projects force documentation: asset inventory, required communications, and ownership—which improves overall reliability.

Practical next step checklist (safe, low-regret)

If you’re implementing OT network segmentation, start here:

1. Inventory assets and owners (EWS/HMI/SCADA/PLCs, vendor laptops, remote access paths).
2. Document required communications (source/destination/protocol/port, plus when it’s needed).
3. Create an OT DMZ and move cross-domain services into it (remote access termination, patch staging, update relays).
4. Implement “deny by default” between zones, then allowlist only what the process needs.
5. Log and review rule hits to remove overly broad access over time.

For endpoint hygiene inside OT zones (especially Windows-based HMIs/EWS in the supervisory layer), choose tooling that won’t disrupt operations and can be centrally managed. Malwarebytes is one commonly used option for malware protection on endpoints (Get Malwarebytes →). (Coordinate changes with operations and follow MOC.)

---

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.