OT Network Segmentation: from the Purdue Model to IEC 62443 Zones in Production

The Purdue model: still valid?

For decades, the Purdue model was the reference map for network architectures in industrial control systems. It defines five hierarchical levels, from physical sensors and actuators (level 0) up to enterprise systems (level 5), with communications that should flow vertically, level by level, without horizontal jumps.

The idea is elegant: separate the levels physically and logically so that a compromise at one level does not automatically propagate to the others. A problem at level 1 (field controllers) should not reach level 4 (enterprise systems) and vice versa.

The Purdue model in its pure form has been eroded by modern reality. The push toward direct connectivity (for production data analytics, for predictive maintenance, for integration with ERP systems) has created an ecosystem where cross-level connections have become the norm. The model remains valid as a conceptual framework, but its strict implementation has become rare.

Zones and conduits according to IEC 62443

IEC 62443 updates and generalizes the Purdue concept with the zones and conduits model, which is more flexible and applicable to modern environments.

A zone is a group of assets with homogeneous security requirements and a common level of trust. It is not necessarily tied to a physical level or a specific building: it can be defined by operational function, by criticality, by risk exposure. A typical zone might include all the PLCs of a production line, or all the supervisory systems of a specific plant.

A conduit is the authorized communication channel between different zones. Every communication that crosses a zone boundary must pass through a conduit, which implements the necessary controls: firewalls with specific rules, application proxies, OT traffic filtering systems.

The model is more granular than Purdue: it allows you to define zones based on the reality of the specific environment, not on an abstract hierarchy. It can coexist with existing architectures without requiring a complete restructuring.

The IT-OT DMZ: why it is essential and how to implement it

The highest-risk zone in any modern OT architecture is the interface between the corporate IT network and the OT network. It is the point where production data must flow toward enterprise systems, but where at the same time an IT compromise should not propagate to the OT.

The solution is a dedicated IT-OT DMZ: an intermediate zone that belongs neither to the IT network nor to the OT network, acting as a controlled buffer for data exchanges.

How it works in practice:

• OT systems do not communicate directly with the IT network. They publish data to systems in the DMZ (historian, data collector, API gateway).
• IT systems read data from the DMZ, not directly from the OT.
• Firewall rules allow data flows from the OT to the DMZ, and from the DMZ to the IT. There are no direct OT-IT or IT-OT rules.
• An attacker who compromises the IT network can reach the DMZ, but has no direct access to the OT systems.

Implementation requires reviewing all the existing data flows between IT and OT, often a mapping that does not exist in documented form, and redefining every integration so that it passes through the DMZ.

Micro-segmentation in modern OT environments

Beyond segmentation between IT and OT, there is value in introducing segmentation within the OT network itself. The goal is to limit the lateral movement of an attacker who has already gained access to an OT segment.

In modern OT environments based on industrial Ethernet, micro-segmentation can be implemented with separate VLANs for different functional zones, with ACLs that restrict communications to the strictly necessary flows, and with next-generation firewalls capable of inspecting OT traffic at the application layer (Modbus, DNP3, OPC-UA).

The challenge is to do this without interrupting the communications needed for the plant to operate. Every restrictive rule introduced risks blocking a data flow that someone needs. Segmentation must be preceded by an accurate mapping of all the active communications in the OT network.

Practical steps: where to start without halting production

Network segmentation in a production OT environment is one of the projects with the highest operational risk if poorly executed. Some guidance for doing it in a controlled way:

Start with passive mapping: before touching any configuration, passively monitor network traffic for weeks. The goal is to have a complete map of all active communications. Any segmentation rule based on an incomplete map risks blocking something important.

Introduce firewalls in monitor-first mode: before applying restrictive rules, configure the firewalls in log-only mode. Verify that the planned rules would not block legitimate traffic. Only after a few weeks of verification should you switch to enforcement mode.

Segment the least critical systems first: start with zones that have less operational impact in case of configuration errors. Build experience and confidence before touching the most critical control systems.

Plan maintenance windows for changes: every modification to the OT network architecture should be performed during planned maintenance windows, with operational staff present and a rollback plan ready.

Document every exception: during the segmentation process, cases will emerge where the standard rules cannot be applied for operational reasons. Document every exception with its justification and compensating controls. This document is also the map of residual risk.

Network segmentation is not a project with an end date: it is a continuous process that must evolve with the environment. Every new system introduced, every new data flow, every integration with external systems must be assessed against the existing zoning model.

The MON5 angle

A premise first, to avoid misunderstandings: MON5 is not the firewall and does not enforce segmentation. It does not sit in the path of traffic, does not block packets inline, and is not a micro-segmentation product. What MON5 does is make segmentation designable and then verifiable over time. The distinction matters, because enforcement stays with the network devices you already know.

As the article explains, segmenting without a complete map of communications is the fastest way to bring a line to a halt. This is where MON5 comes in, in two phases. DISCOVER reconstructs the real topology and flows through passive discovery, without interfering with production, so that firewall rules are written against verified dependencies and not against outdated documentation. ANALYZE supports the design of zones and conduits according to IEC 62443, starting from the observed traffic.

When segmentation is in operation, PROTECT verifies over time that it is actually being respected and flags the communications that violate the designed architecture: flows that were never authorized, exceptions that accumulate, deviations from the baseline. To reach segmentation with a reliable map in hand, the first step is an OT assessment.