Network Segmentation for OT Environments

Most serious operational technology incidents share a common enabler: a flat network. When the corporate environment, the engineering workstations and the controllers running physical processes all sit on networks that can freely reach one another, a single phishing email or compromised laptop can end up issuing commands to a pump, a breaker or a production line. Network segmentation is the architectural control that breaks that chain.

Segmentation is not glamorous and it is rarely quick, but in OT it is the single most effective way to contain an incident. This guide explains how to do it properly using the Purdue model, and zones and conduits.

Why OT segmentation is its own discipline

You cannot simply apply IT segmentation thinking to a plant. OT environments are full of devices that cannot be patched, cannot run agents, use proprietary or legacy protocols, and were never designed to be on a routable network at all. Availability and safety outrank confidentiality — an unplanned outage can have physical and even life-safety consequences. And many control protocols have no authentication, so any device that can reach a controller is effectively trusted by it.

That last point is why segmentation matters so much. If the protocol will not protect the controller, the network has to. Segmentation becomes the primary defence, not a supporting one.

There is also a maintenance reality. In IT, if a segmentation rule causes a problem, you adjust it and move on. In OT, a misconfigured rule can stop production, trip a process, or block the very traffic an operator needs during an upset condition. The cost of getting it wrong is high, which is exactly why segmentation in OT rewards careful, evidence-based design over the rapid iteration that works in the corporate network. You are not just dividing a network; you are encoding assumptions about how a physical process communicates, and those assumptions must be correct.

The Purdue model as a map

The Purdue Enterprise Reference Architecture gives teams a shared way to reason about industrial networks by organising them into layers:

• Level 0 — field devices: sensors, actuators, instruments that interact with the physical process.
• Level 1 — controllers: PLCs and RTUs that read sensors and drive actuators.
• Level 2 — supervisory: HMIs, SCADA servers and local control room systems.
• Level 3 — operations: site-wide systems such as historians, manufacturing operations management and engineering workstations.
• Levels 4 and 5 — enterprise IT: business systems, email, ERP and the corporate network.

The model is a reference, not a rigid prescription — modern cloud and remote-access patterns blur the neat layers. But its core lesson holds: traffic should flow between adjacent levels through controlled boundaries, never leap directly from the enterprise to a controller. The classic control point is a demilitarised zone between Levels 3 and 4, where data such as historian feeds is exchanged without the enterprise ever touching the control network directly.

Zones and conduits in practice

The IEC 62443 standard gives us the practical vocabulary: zones and conduits. A zone is a grouping of assets that share security requirements — for example, all the controllers and HMIs for a single process area. A conduit is the controlled, documented communication path between zones, carrying only the specific flows those zones legitimately need.

The discipline is twofold. First, divide the environment into meaningful zones based on function, criticality and trust — not just IT versus OT, but multiple zones within OT so that an incident in one process area cannot spread to another. Second, define conduits explicitly: each one permits named source and destination, specific protocols and ports, and nothing else. Everything not expressly allowed is denied. This is what stops lateral movement once an attacker is inside.

How granular should zones be? There is judgement involved. Too coarse, and you have effectively rebuilt a flat network with a firewall in front of it — a compromise still spreads freely once inside. Too fine, and you create a sprawl of conduits that is hard to maintain and that operations teams will be tempted to work around. A sensible starting point is to draw zone boundaries around process areas that can operate independently, around differing criticality levels, and around groups of assets with genuinely different security needs. A safety system, for instance, belongs in its own zone, separated from the general control network by tightly restricted conduits, because nothing should be able to casually reach a system whose job is to keep people safe.

How to run a segmentation project without an outage

The fastest way to cause the very disruption you are trying to prevent is to drop firewall rules into a network you do not fully understand. A disciplined sequence avoids that:

1. Build an asset inventory. You cannot zone what you cannot see. Use passive discovery on OT networks; active scanning can fault fragile devices.
2. Map the traffic. Baseline real communication flows over a representative period, including periodic, batch and maintenance traffic that only appears occasionally.
3. Design zones and conduits. Group assets into zones, then define the conduits the mapped traffic actually requires.
4. Enforce in monitor mode first. Run the rules in alert-only mode to surface flows you missed before anything is blocked.
5. Cut over in phases. Enforce zone by zone, with rollback ready, rather than flipping the whole site at once.

The same care applies when you introduce new automation. Connecting robotics and automated equipment into a plant is the right moment to design its zone and conduits from day one, rather than retrofitting isolation after the equipment is live.

Secure remote access and the conduits that bite back

Remote access is the conduit most likely to undermine a good segmentation design. Vendors, integrators and your own engineers all want to reach OT systems remotely, and ad hoc remote-access tools quietly punch holes straight through your zones. Funnel all remote access through a controlled, monitored path — a hardened jump host or broker that enforces multi-factor authentication, logs every session, and grants access only to the specific zone required, only for as long as it is needed.

The same vigilance applies to removable media and portable engineering laptops, which cross zone boundaries physically and bypass every network control you have put in place. A contractor’s laptop that has been on a dozen other sites, plugged directly into your controller for a configuration change, is a conduit your firewall never sees. Policy, scanning kiosks and dedicated, controlled engineering devices are the answer here — segmentation on the wire is undone if the threat simply walks in on a USB stick.

Maintaining segmentation over time

Segmentation is not a project you finish; it is a state you maintain. Networks drift. A vendor needs a new flow for an upgrade, an operator adds a device, a temporary rule for a maintenance window never gets removed. Over months and years these accretions erode the design until the carefully built zones are riddled with exceptions no one remembers the reason for. The discipline that protects the investment is change control — every new conduit rule justified, documented and reviewed, and periodic audits that compare the running configuration against the intended design and flag the rules that should no longer exist. Without that, even an excellent segmentation design quietly decays back toward the flat network it replaced.

Segmentation and the broader programme

Segmentation does not replace host-level security — it complements it. The Essential Eight controls harden the IT systems and engineering workstations that bridge into OT, while segmentation contains the damage when those defences are bypassed or when an unpatchable OT host is compromised. For regulated entities, this layered approach also supports obligations under frameworks such as ISO 27001 and, for financial services with operational dependencies, APRA CPS 234.

Get the architecture right once

Segmentation is one of those investments that is far cheaper to design well than to retrofit after an incident. Done properly, it turns a potential site-wide compromise into a contained, recoverable event. Done as an afterthought, it produces brittle rules that operations teams quietly bypass.

CISO Advisory helps Australian utilities, manufacturers and councils design and stage OT segmentation that holds up operationally — from asset discovery and traffic mapping through to zone design and phased cutover. A Virtual CISO engagement can provide the senior architectural oversight to get it right the first time. To discuss your environment, call 07 2112 8502 or reach us through our contact page.