OT Network Segmentation: When Purdue falls short and IEC 62443 takes over

The Illusion of Segmentation: When Diagrams Don’t Match Reality

Organizations often feel confident in their OT architecture. They have firewalls between levels, a DMZ, and clearly labeled networks. On paper, the structure looks aligned with industry best practices.

But real-world environments frequently behave very differently than the drawing suggests.

Common challenges include:

• Flat Layer 2 networks inside a single level, enabling unrestricted lateral movement.
  • Example: Control networks where firewalls separate Level 3 from Level 2, but within Level 2 everything is reachable by everything.
• Remote access paths (VPNs, vendor tools) bypassing the model entirely.
  • Example: Vendor-maintained machines with their own embedded routers, providing backdoor pathways.
• Shared services or engineering workstations providing unintended cross-zone connectivity.
  • Example: Historian servers bridging OT to IT with overly permissive rules because “production needs it.”
• Cloud and IIoT integrations that don’t map cleanly into the hierarchical level structure.
  • Example: Outbound tunnels opened by cloud-connected devices, undermining DMZ boundaries. 

The Purdue Model was never designed for these modern realities. And because it isn’t risk-based, it cannot explain why certain communication paths need stronger protection—or whether the architecture can withstand modern threats.

Why This Gap between IEC62443 and Purdue Exists

If the Purdue Model is so widely used, why does the confusion persist?

Because it is simple, familiar, and operationally intuitive. And because OT environments are shaped more by availability, vendor constraints, and operational continuity than by abstract security frameworks.

Several factors reinforce this gap:

Operational Priorities

Production uptime dominates decision-making. If a connection is needed to troubleshoot a machine, it is often enabled first and reviewed later, if at all.

Misunderstood Roles

IT, OT, engineering, automation vendors, and integrators all contribute to the network, but no single party “owns” the security architecture end-to-end.

Misplaced Confidence in the Diagram

A Purdue diagram looks structured, so teams assume segmentation is already in place, even if the underlying controls are incomplete or overly permissive.

Lack of Security Objectives

Purdue defines levels, but not security levels, risk classifications, or zone objectives.

Without those, segmentation remains a technical layout, not a security control.

This is where IEC 62443 provides the missing structure.

Where IEC 62443 Changes the Conversation

IEC 62443 does not care about Layers 0–5.

It cares about risk, criticality, and trust boundaries.

Its core concepts introduce clarity that Purdue alone cannot:

- Zones

Groups of assets that share a common security requirement, regardless of which Purdue level they reside in.

- Conduits

Controlled communication paths between zones, where authentication, filtering, and inspection are enforced.

- Security Levels (SL)

Defined protection targets based on the threat capabilities an organization must defend against.

This reframes segmentation from: “Where does this device belong?” to “What security requirements apply to this function, and how must it communicate?”

This difference is foundational.

‍

Purdue provides structure; IEC 62443 provides security intent.

What Should You Do Next?

Improving OT segmentation isn't about discarding Purdue or redrawing the whole architecture. It starts with recognizing that hierarchy alone does not deliver security and aligning your design with IEC 62443 principles.

Leading organizations begin by:

1. Differentiating topology from security

Purdue remains valuable, just not as a segmentation framework.

The shift begins by separating “where things sit” from “how they must be protected.”

2. Defining meaningful security zones

Rather than grouping by level, zones are formed based on risk, function, exposure, and criticality.

3. Establishing trusted conduits

Connections between zones are intentional, justified, and governed, not simply allowed because “the system needs it.”

4. Introducing security levels

IEC 62443’s Security Levels transform architecture from a visual model into a defensible position aligned with threat scenarios.

5. Embedding segmentation into governance

Architecture only remains secure when access control, vendor integration, change management, and procurement requirements support it.

None of this is solved by a tool alone.

It requires coordinated effort across operations, engineering, IT, and security, and a design methodology that translates IEC 62443 concepts into practical, site-specific decisions.

From Diagrams to Defensible Architecture

The Purdue Model and IEC 62443 are not competing approaches.

Together, they create a complete picture:

• Purdue helps you understand how your environment is built.
• IEC 62443 defines how it must be protected.

But turning these two views into a coherent, working architecture is far from trivial. Industrial realities — vendor constraints, legacy systems, availability requirements, and regulatory pressures — demand tailored solutions, not generic templates.

At BxC, we help organizations bridge this gap by evaluating existing architectures, identifying misalignments, and designing segmentation strategies that are both practical for operations and defensible for compliance.

Because in OT, segmentation isn’t a diagram. It’s a security decision and it needs to work in the real world.