Segmenting OT networks with the Purdue model and IEC 62443 zones

Operational technology (OT) segmentation is often discussed as if it were a single design choice, but in practice it is a set of decisions about trust boundaries, process dependencies and operational tolerance. For many UK SMEs, the challenge is not whether to segment, but how to do it without disrupting production, safety systems or maintenance access.

The Purdue model remains a useful starting point because it gives teams a shared language for industrial architecture. IEC 62443 then adds a more precise way to define boundaries using zones and conduits. Used together, they help you move from a flat, difficult-to-defend OT network to a structure that is easier to monitor, control and change safely.

If you want a broader introduction to the standard itself, our article on IEC 62443 explained for manufacturing organisations is a useful companion. This article assumes you already know the basics and focuses on how to apply the Purdue model and IEC 62443 zones in a real environment.

Why the Purdue model still matters in modern OT segmentation

What the Purdue model is and where it helps

The Purdue model is a layered reference architecture for industrial systems. In simplified terms, it separates enterprise IT from supervisory systems, control systems and field devices. That separation is still valuable because it reflects how industrial environments usually operate: business systems should not talk directly to PLCs, and field devices should not be exposed to broad network access.

For practitioners, the main value of the model is clarity. It helps teams identify where traffic should be tightly controlled, where monitoring should be richer, and where remote access should be mediated. It also gives project teams a common way to discuss architecture with operations, engineering and suppliers.

Where the model is too coarse on its own

The limitation is that the Purdue model is a reference model, not a security design. Real OT environments rarely fit neatly into one layer per function. A plant may have multiple production lines, shared historians, vendor support paths, engineering workstations and safety systems that do not map cleanly to a simple diagram.

That is why the Purdue model alone is usually too coarse for security implementation. It tells you where the broad layers are, but not how to group assets within a layer, how to handle shared services, or how to set different trust levels for different parts of the same process. For that, IEC 62443 zones and conduits are more useful.

How IEC 62443 zones and conduits refine the Purdue model

Defining zones by function, trust and risk

In IEC 62443 terms, a zone is a group of assets that share similar security requirements. That grouping is not just about technology. It is about function, process dependency, exposure and the consequences of compromise. Two PLCs may sit in the same Purdue layer but belong in different zones if they support different production lines or have different availability requirements.

When defining zones, start with the process rather than the network. Ask which assets must communicate, which assets can be isolated, and which systems have similar impact if they fail or are manipulated. A zone should be small enough to be meaningful, but not so small that it becomes impossible to operate.

For a practical method, many teams begin by documenting the current architecture and then overlaying zones on top of the existing Purdue layers. Our guide to zone and conduit modelling under IEC 62443 goes into the modelling approach in more detail.

Using conduits to control and monitor traffic between zones

A conduit is the controlled communication path between zones. It is not just a cable or VLAN. It is the set of technical and procedural controls that govern traffic, such as firewall policy, protocol restrictions, authentication, logging and inspection. In other words, the conduit is where you enforce the rules of interaction.

This distinction matters because many OT environments have segmentation in name only. They may have VLANs or firewall zones, but if the rules are broad, the remote access is shared, and the logging is weak, the conduit is not really controlled. A good conduit design should answer four questions: who can talk, what can they talk to, on which protocol, and under what conditions.

Mapping Purdue levels to IEC 62443 zones in practice

Typical mappings for enterprise, DMZ, supervisory and control layers

In a typical industrial environment, the enterprise network sits above the OT environment and should be separated by a demilitarised zone, often called an industrial DMZ. That DMZ is where you place services that need to exchange data between IT and OT, such as patch repositories, jump hosts, file transfer services or replicated historian feeds.

Below that, the supervisory layer often contains SCADA servers, HMI systems and engineering workstations. These systems usually deserve separate zones because they have different exposure and different operational roles. A supervisory zone may need access to multiple control zones, but the control zones should not be able to freely reach back into enterprise systems.

At the control layer, PLCs, remote I/O and related controllers are often grouped by production line, cell or process unit. That is usually where the greatest segmentation value is found, because it limits lateral movement and reduces the blast radius of a compromise.

Handling shared services, historians and remote access

Shared services are where many OT segmentation programmes become messy. Historians, time synchronisation, patching, antivirus management and remote vendor support can all create exceptions. The right approach is to treat each shared service as a design problem, not an exception to be ignored.

For example, a historian may need to collect data from several control zones and forward it to business reporting systems. That usually means placing the historian in its own zone or in the industrial DMZ, then using tightly scoped conduits to each source zone. Similarly, remote access should terminate in a jump host or remote access broker rather than directly into a control zone.

Where remote access is required, use strong authentication, session recording where appropriate, and time-bound access approvals. If you are designing secure remote paths, our article on secure communications over insecure networks is relevant to the transport and trust model, even though OT environments often need additional protocol and availability considerations.

Designing a segmentation model for a real OT environment

Start from asset inventory and communication flows

Good segmentation starts with visibility. You need an asset inventory that includes controllers, servers, operator stations, engineering laptops, network devices, safety systems and any third-party managed components. Just as important, you need communication flows: who talks to whom, on what ports, using which protocols, and how often.

Passive discovery tools are usually preferable in live OT environments because they avoid introducing instability. Network taps, SPAN ports and protocol-aware monitoring can help build a baseline without touching the control devices. From there, map the flows into a data flow diagram and identify the trust boundaries that matter most.

At this stage, do not optimise for the diagram. Optimise for operational truth. If a maintenance laptop is used across multiple lines, that is a real shared dependency. If a vendor support path exists only during outages, that is still a conduit that needs control and logging.

Group assets by criticality, process dependency and trust boundary

Once you understand the flows, group assets by how they are used and what happens if they are compromised. A zone should usually contain assets with similar criticality and similar tolerance for change. Safety-related systems, for example, often need stricter isolation than general supervisory tooling.

Process dependency is also important. If one production line can be isolated without affecting another, that is often a strong argument for separate zones. If a shared engineering workstation can reach multiple cells, you may need to redesign access so that the workstation is not a single point of compromise across the plant.

For architecture teams, this is where the Purdue model and IEC 62443 complement each other. The Purdue model gives the layer view, while zones and conduits let you split a layer into security-relevant segments based on actual risk.

Security controls to place at each zone boundary

Firewalls, industrial protocol gateways and jump hosts

Zone boundaries should be enforced with controls that match the traffic and the operational need. In many cases, that means industrial firewalls with explicit allow rules rather than broad network access. Where protocol translation or data brokering is needed, industrial gateways can reduce direct exposure between zones.

Jump hosts are a common control for administrative access. They provide a single, monitored entry point into a zone and reduce the need for direct RDP, SSH or vendor tooling from the enterprise network. In higher-risk environments, you may also use privileged access management, just-in-time access and session recording.

Do not forget physical and procedural controls. A well-designed boundary can still be undermined by unmanaged laptops, removable media or ad hoc maintenance practices. Segmentation works best when the technical controls and the operating procedures reinforce each other.

Authentication, logging and protocol-aware inspection

Authentication should be strong at the boundary, but it should also be proportionate to the environment. In OT, availability and deterministic behaviour matter, so the design needs to avoid introducing brittle dependencies. Where possible, use central identity for administrative access, but keep local fallback options for resilience.

Logging is essential because segmentation without visibility is hard to validate. Boundary devices should log allowed and denied connections, administrative changes and unusual protocol patterns. Those logs should feed a SIEM or central monitoring platform so that OT events can be correlated with enterprise identity and endpoint activity.

Protocol-aware inspection is especially useful in industrial environments because many OT protocols are simple and predictable. A firewall that understands the protocol can distinguish between normal read operations and riskier write or function calls. That does not replace engineering judgement, but it gives you much better control than port-based filtering alone.

Common OT protocols and what to watch for at the conduit layer

Modbus, DNP3 and other legacy protocols

Legacy OT protocols often lack native authentication and encryption, which means the network boundary carries more of the security burden. Modbus, for example, is widely used and operationally simple, but it was not designed for hostile networks. DNP3 is more capable, but it still needs careful handling in segmented environments.

Because these protocols are often chatty and predictable, they are good candidates for allow-listing and protocol validation. The conduit should permit only the specific function codes, devices and directions that are required. If a monitoring system only needs to read values, it should not be able to issue writes.

For teams looking at detection design, the same principles used in network monitoring for enterprise environments apply, but with more emphasis on process safety and false positive control. A useful next step is to define what normal looks like for each protocol and each zone, then alert on deviations rather than raw volume.

Detecting unusual commands, scans and lateral movement

At the conduit layer, the main things to watch for are unexpected writes, new source hosts, repeated connection attempts, scans across control devices and traffic that appears outside the normal maintenance window. Lateral movement in OT often looks different from IT, but it still tends to show up as new communication paths or unusual administrative actions.

One practical approach is to baseline by zone and by protocol. If a workstation in one zone suddenly starts talking to devices in another zone, that is worth investigation even if the traffic is technically allowed. Likewise, if a vendor support path is active outside an agreed window, it should be reviewed.

Detection engineering for OT should be conservative. The goal is not to generate large volumes of alerts, but to identify changes in behaviour that matter. That usually means combining network telemetry, asset context and change records.

Security level targets and how they influence segmentation decisions

Using security level targets to set boundary strength

IEC 62443 uses security level targets to describe the level of resistance a zone or system should have against different threat capabilities. In practice, that helps you decide how strong a boundary needs to be. A low-risk monitoring zone may need basic separation and logging, while a more sensitive control zone may need stricter access control, tighter allow lists and stronger administrative mediation.

The important point is that the target should be driven by risk, not by aspiration. If a zone supports a critical process with limited downtime tolerance, the design may need to prioritise resilience and controlled access over aggressive inspection that could introduce instability.

That is also why segmentation decisions should be documented as design intent. When a boundary is built to a particular level of control, the team needs to know why it exists and what assumptions it depends on.

Balancing availability, safety and operational constraints

OT segmentation is always a balancing act. Stronger boundaries can improve containment, but they can also create operational friction if they are too rigid or poorly understood. In industrial environments, availability and safety are often the primary concerns, so changes need to be planned carefully and tested in a controlled way.

That usually means phasing the work. Start with passive monitoring, then introduce visibility and logging, then tighten access paths, and only then consider more restrictive controls. This staged approach reduces the chance of breaking production while still moving the environment towards a better security posture.

Practical design patterns for UK SMEs

Brownfield environments with limited downtime

Most UK SMEs do not have the luxury of redesigning OT from scratch. Brownfield environments usually contain legacy devices, undocumented dependencies and limited maintenance windows. In that setting, the safest approach is incremental segmentation around the highest-value boundaries first.

A common pattern is to create an industrial DMZ, move remote access and shared services into it, then separate supervisory systems from control zones one line or cell at a time. This reduces risk without requiring a full shutdown. Where a full redesign is not possible, compensating controls such as stricter firewall rules, jump hosts and enhanced monitoring can still materially improve resilience.

It is also worth aligning the work with existing governance. If you already run an ISMS, segmentation changes should be tracked as risk treatments, with owners, exceptions and review dates. That makes the work easier to sustain and easier to explain to stakeholders.

New builds and staged segmentation programmes

New OT builds are the best opportunity to get the architecture right from the start. In a greenfield environment, define zones before procurement, not after installation. That lets you choose network equipment, remote access patterns and management tooling that support the intended boundaries.

For staged programmes, use a roadmap. Phase one might be inventory and passive monitoring. Phase two might be the industrial DMZ and remote access redesign. Phase three might be control-zone separation and protocol-aware filtering. Phase four might be validation, tuning and operational handover.

That staged approach is often more realistic for SMEs than trying to implement a perfect end state in one project. It also creates measurable progress, which helps justify further investment.

Validation, monitoring and change control

Testing that segmentation works without breaking operations

Segmentation should be tested in a way that reflects real operations. That means validating both security and process continuity. Check that only intended traffic crosses each conduit, that denied traffic is actually blocked, and that critical workflows still function during normal operations and maintenance windows.

Where possible, test changes in a maintenance window or a representative staging environment. If a staging environment is not available, use a controlled pilot zone with close operational oversight. The aim is to avoid surprises once the boundary is enforced.

Testing should include failure scenarios as well. What happens if a firewall rule is misapplied, a jump host is unavailable or a remote support session fails? Good segmentation design includes fallback paths that are understood and controlled, rather than improvised under pressure.

Keeping diagrams, rules and exceptions current

OT segmentation degrades quickly if the documentation is not maintained. Diagrams, firewall rules, conduit exceptions and asset inventories should be treated as living artefacts. Every new device, vendor connection or maintenance workflow should trigger a review of the relevant zone and conduit.

This is where change control matters. If a temporary exception is granted for a project or outage, it should have an expiry date and an owner. Otherwise, temporary access tends to become permanent. Regular review keeps the design aligned to reality and reduces the chance of hidden pathways accumulating over time.

When the Purdue model is not enough

Flat networks, cloud connectivity and remote operations

Some environments are too distributed or too modern for the Purdue model to be the only architectural lens. Cloud-connected telemetry, remote operations centres, managed service providers and hybrid IT/OT platforms can create paths that do not fit neatly into the classic layered diagram.

In those cases, use the Purdue model as a baseline, but supplement it with other architecture patterns such as zero trust principles, identity-aware access, and explicit service-to-service trust decisions. The key is to model the actual communication paths, not just the idealised ones.

Using additional architecture patterns alongside IEC 62443

IEC 62443 zones and conduits remain useful even in hybrid environments because they force you to define boundaries and control paths. But they work best when combined with broader security architecture thinking. That may include central logging, privileged access management, secure remote access, and supplier assurance for third-party connections.

In other words, segmentation is one control layer, not the whole answer. It should sit alongside endpoint hardening, monitoring, backup resilience and incident response planning. For SMEs, the practical goal is not perfection. It is reducing the number of ways an issue can spread and making the remaining paths visible and manageable.

If you are planning an OT segmentation programme and want help turning the architecture into a realistic delivery plan, speak to a consultant. We can help you assess the current state, define sensible zones and conduits, and phase the work so it fits operational constraints.

Frequently asked questions

Is the Purdue model required by IEC 62443?

No. The Purdue model is a useful reference architecture, but IEC 62443 is better understood as a framework for defining zones, conduits and security requirements. In practice, many teams use Purdue as a starting point and IEC 62443 to refine the design.

What is the difference between a zone and a conduit?

A zone is a group of assets with similar security requirements. A conduit is the controlled communication path between zones, including the technical and procedural controls that govern traffic, access and monitoring.

How do you segment legacy OT networks without disrupting operations?

Start with passive discovery, map real communication flows, and introduce segmentation in stages. A common approach is to build an industrial DMZ first, then separate supervisory and control areas gradually while testing each change in a controlled window.