OT Network Segmentation: Zones, Conduits and the Industrial DMZ Explained

OT network segmentation is the practice of dividing an operational technology environment into groups of assets, so that a compromise or fault in one group cannot freely reach the rest. Each group is given a defined set of allowed connections to every other group, and everything outside that allowed set is blocked and, ideally, logged.

The purpose in OT is slightly different from IT. In enterprise IT, segmentation is largely about confidentiality and least privilege. In OT, the primary drivers are safety and availability: a compromise that reaches a controller can stop production or, in the worst case, create a physical hazard. Segmentation exists to keep that outcome contained to the smallest possible part of the plant.

Not all separation is equal. The four patterns below are commonly used together at different points in an OT architecture, and it matters which one is applied to which boundary.

In practice, most OT estates use routed separation and firewalled zones for day-to-day boundaries between Purdue levels, and reserve physical separation for the small number of assets, such as a recovery copy, that need to survive a total compromise of the network.

ISA/IEC 62443 formalises segmentation through zones and conduits. A zone is a group of assets that share a common set of security requirements and a target security level. A conduit is an explicitly defined and controlled connection between two zones, with a documented source, destination, protocol and enforcement mechanism.

Zone

A group of assets with common security requirements and a shared target security level.

Conduit

An explicitly defined, controlled connection between two zones.

Security level target

The level of protection a zone or conduit is designed to achieve, from SL-1 to SL-4.

Zone boundary

The physical or logical point where a zone's enforcement is applied.

IEC 62443-3-2 covers the risk assessment used to define zones and conduits. IEC 62443-3-3 then sets the technical requirements each zone must meet at its target security level. Purdue levels are the usual starting point for the zone boundaries, but the standard does not require every zone to map one-to-one onto a Purdue level; some estates split a single Purdue level into several zones based on process risk.

The industrial DMZ, commonly called Level 3.5, is a dedicated zone that sits between site operations and enterprise IT. It is not simply a firewall rule between two VLANs. A properly built industrial DMZ has its own hosts, such as jump servers, patch mirrors and replicated historians, and, critically, its own identity domain rather than sharing the corporate Active Directory forest.

Nothing at Level 3 or below should have a direct route to Level 4 or above. Every legitimate interaction is brokered through a service that lives in the DMZ, which creates a point where authentication, inspection and logging can all happen before traffic reaches either side.

Where OT data genuinely needs to reach IT, such as historian data feeding an analytics platform, a unidirectional gateway, often called a data diode, enforces one-way flow at the hardware level. The receiving side gets the data; there is no physical path for anything to travel back into the OT environment. This is standard practice in regulated utilities for specific, well-defined data flows.

A protocol break serves a related but distinct purpose. Instead of a single session tunnelling straight through a boundary, the connection is terminated on one side, inspected or transformed, and a new connection is originated on the other side, usually by a host inside the DMZ. This stops techniques that rely on carrying malicious traffic inside an otherwise permitted protocol across the whole path.

Remote and vendor access is one of the most common ways segmentation is quietly undone. Access for maintenance vendors, system integrators and remote engineers should terminate inside the industrial DMZ, through a jump host or access broker, never with a direct route into Level 2 or Level 1 systems.

1. Request. Access is requested for a specific piece of work, with a defined scope and time window.
2. Authenticate. Multi-factor authentication is required before the session is established.
3. Broker. The session is brokered through a jump host in the industrial DMZ, not a direct VPN into the OT LAN.
4. Record. The session is recorded and logged, with the identity, duration and systems touched.
5. Close. Access is closed at the end of the work item rather than left standing for future convenience.

The management plane is the set of systems used to configure the segmentation controls themselves: firewall managers, switch and router consoles, identity providers and the tools used to administer them. If the management plane sits on the same network it protects, or shares identity with corporate IT, an attacker who compromises it can reconfigure or disable segmentation without touching a single controller.

A common weakness is running the industrial DMZ inside the same Active Directory forest as corporate IT. Once that is the case, a phished domain administrator has authority on both sides of the boundary, and the firewall between them stops being the real security boundary; the identity domain is.

Segmentation reduces the number of paths available to an attacker, but every conduit that remains is still a route, and needs to be watched. Monitoring at each zone boundary is what turns an approved conduit from an assumption into evidence. Unexpected protocols, unexpected volumes or unexpected destinations on an approved conduit are early indicators that the conduit is being misused.

NCSC guidance on OT connectivity treats monitoring and boundary protection as companion controls, not alternatives: the boundary limits what can happen, and the monitoring confirms what actually did.

A segmentation design is a set of intentions until it has been checked against the live network. Verification means comparing the documented zones and conduits against the actual firewall rule sets and switch configurations, running authorised test traffic between zones to confirm that only the intended paths work, and confirming that monitoring actually captures traffic crossing each boundary.

An outdated segmentation diagram can be worse than no diagram at all, because it creates false confidence during an incident response, when responders assume a boundary holds that no longer exists in the live configuration.

Flat VLANs behind a single firewall

Many industrial estates still run a single flat VLAN for the plant behind one perimeter firewall. Once an attacker gets past that firewall, every controller and historian on the flat network is reachable.

Shared identity across the DMZ and enterprise IT

Placing the industrial DMZ inside the same identity domain as corporate IT means a compromised domain administrator has authority on both sides, regardless of what the firewall rules say.

Undocumented conduits added during a project

A temporary rule added to support a commissioning project or a vendor visit is frequently never removed, and rarely appears on the architecture diagram that the security team relies on.

A backup or management platform reachable from both sides

Running a backup platform as virtual machines on the corporate hypervisor, or as an appliance dual-homed into the corporate LAN, undoes segmentation regardless of how the backup data itself is protected, because the management plane that controls it is reachable from the side the boundary was meant to hold back.

• Zones defined against Purdue levels, with a written security level target per zone
• Every conduit documented with source, destination, protocol and enforcement mechanism
• Industrial DMZ hosts sit in a dedicated identity domain, not the corporate forest
• No system at Level 3 or below has a route to Level 4 or above except through the DMZ
• Unidirectional gateways used for OT to IT flows that only need to publish data
• Remote and vendor access brokered through a jump host, never a direct route
• Management plane for segmentation controls kept separate from the networks it protects
• Cross-zone traffic monitored, not just blocked or allowed
• Rule sets reviewed against the documented conduit list on a defined cycle
• Segmentation re-verified after any change to the corporate identity domain

Firevault's role in an OT architecture is deliberately narrow. Offline Secure Storage® provides the copy of recovery data that is expected to survive a total compromise of the network, including a compromise of the segmentation controls described above. It typically sits in or near the industrial DMZ, or in a dedicated bunker, with no live network interface while it is offline.

Firevault Control governs the connection windows used to update or verify that copy, on a management plane that is kept separate from both the corporate identity domain and the OT production network, so that a compromise of either side does not automatically extend to the recovery copy. Every connection, disconnection and access is logged with identity, timestamp and reason, giving segmentation designs the kind of evidence described in the verification section above, for the one asset a segmentation failure elsewhere is not allowed to reach.

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security

  Segmentation architectures for OT, including a Purdue-style DMZ and IEC 62443 zones and conduits as an alternative model.

• ISA/IEC 62443 series

  The zones and conduits model, security level targets, and technical requirements for each zone.

• NCSC, Secure Connectivity Principles for Operational Technology

  UK guidance on OT exposure, centralised connectivity, boundary protection, segmentation and monitoring.

• CISA, Layering Network Security Through Segmentation

  US guidance on segmentation architecture and common implementation weaknesses.

• NCSC, Recovering from a Cyber Incident

  The relationship between segmentation, isolation and recovery during an incident.

Related Firevault guides