Segmenting production networks according to the Purdue model: zones, conduits and common mistakes

The Purdue model as orientation, not a rulebook

The Purdue reference model divides a manufacturing environment into levels ranging from the physical plant to enterprise IT. In simplified terms, it comprises the process level with sensors and actuators (Level 0), the control level with PLCs and controllers (Level 1), the supervisory level with HMI and SCADA (Level 2), the site-wide operations level with MES and data historians (Level 3), an industrial DMZ above this acting as a buffer zone (often called Level 3.5), and enterprise and corporate IT (Levels 4 and 5).

The value of the model lies in the shared language it provides: it makes visible which systems sit close to the physical process and which are further removed. However, it is not a cabling diagram! Modern environments involving virtualisation, edge computing or cloud-based analytics blur these clear-cut level boundaries. The model remains valuable as a conceptual framework, but the actual security architecture is only created one level below, at the level of zones.

From levels to zones and conduits

IEC 62443 provides the tool for turning the vertical Purdue structure into robust segmentation. Its two core concepts are the zone and the conduit. A zone groups together systems with the same protection requirements and the same security demands. A conduit is a deliberately defined communication link between two zones, with clearly established rules on which communication is permitted and which is not.

This shift in perspective is important: Purdue describes where something sits within the structure; zones and conduits determine how strictly it is secured. Only once every transition between two zones is a named, documented and controlled conduit does segmentation exist that truly deserves the name.

Defining zones sensibly

The most common question in practice is what criteria should be used to define zones. The reliable benchmark is protection requirements, not convenience. In practice, a combination of the following proves effective:

• Criticality to the process: A cell whose failure would halt the entire line does not belong in the same zone as an uncritical auxiliary system.
• Function and communication behaviour: Systems that already communicate closely and regularly with one another form natural groups; connections across zone boundaries should be the exception.
• Required security level: IEC 62443 defines graded security levels. Zones with differing target levels should be kept separate, so that the higher requirement is not undermined by the lower one.

A well-designed zone layout keeps the number of necessary transitions low. If a design results in a very large number of conduits, this is usually a sign that the zone boundaries have been drawn in the wrong place.

Conduits: every transition a deliberate decision

For every conduit, the same questions must be answered: which systems are allowed to communicate, over which protocols, in which direction, and how is the transition monitored? The guiding principle is minimal privilege: only what is demonstrably necessary for operation is permitted, and everything else is blocked. Where data flow is only needed in one direction – for example, when collecting metrics – only that direction is allowed. This ensures that a transition remains no open gateway even if one of the two sides is compromised. (Keyword: "data diode")

Common mistakes in practice

Most segmentation projects fail not because of the concept, but due to recurring patterns in implementation:

Segmentation without enforcement

VLANs alone do not provide separation. If the boundaries between VLANs are not enforced by a controlling instance, the result is a network that looks segmented on paper but in which traffic flows unimpeded. Separation must actually be enforced and logged at the transitions.

Cutting zones for convenience rather than protection needs

Defining zones along building boundaries, manufacturers, or historically grown responsibilities is easy – but arbitrary from a security perspective. Systems with very different protection requirements end up in the same zone, and the weakest participant then determines the risk for the entire zone.

Only north–south, not east–west, controlled

Often, only vertical traffic between levels is secured, while systems within a level can reach one another freely. This is precisely the lateral path that malware uses to spread. Communication within a level must also be part of the zone concept. (Keyword: "micro-segmentation")

Remote maintenance as a backdoor through all zones

A cleanly segmented network loses its value if a maintenance access point from outside reaches directly down to the control level. Remote access must follow the same zone-and-conduit principle as any other traffic, rather than bypassing it.

Over-segmentation that nobody maintains

The opposite is equally risky: a structure so finely grained that operations can no longer manage it properly on a day-to-day basis leads to exceptions, workarounds and outdated rules. Segmentation is only as good as its ongoing maintainability.

The plan ages faster than the network

Segmentation is an ongoing concern. New plant, changed processes and additional services continuously shift the boundaries. Without continuous monitoring of the transitions and regular upkeep of the documentation, the actual state drifts away from the planned one – until segmentation exists only on paper.

A pragmatic way forward

A robust approach begins with a passive inventory of all systems and their communication relationships. On this basis, a zone model is designed according to protection requirements, and every necessary conduit is named. Implementation proceeds step by step: starting with the highest-risk transitions, each carried out within regular maintenance windows and with a defined fallback option. After the changes, ongoing passive monitoring and well-maintained documentation ensure that the structure is not diluted again over time. This creates segmentation that not only withstands an audit, but genuinely makes day-to-day operations more robust.