The Purdue Model in 2026: A Complete OT Security Guide

The Purdue model is the layered reference architecture almost every industrial cybersecurity conversation starts from, and it is genuinely useful — as a shared vocabulary for where equipment sits. Where it goes wrong is when people treat its levels as security zones. They are not the same thing, and conflating them produces a zone model that mirrors a vendor diagram rather than your actual risk.

This guide covers the levels, how real plants depart from them, and how the Purdue model should feed into an IEC 62443 zone model without dictating it.

What this guide covers

• The Purdue model levels
• The Purdue model level is not a security zone
• Where real plants depart from the Purdue model
• Mapping your plant onto the Purdue model
• How the Purdue model feeds an IEC 62443 zone model
• The demilitarised zone at level 3.5
• Segmenting a flat network without stopping the plant
• Frequently asked questions
• Where to go next

The Purdue model levels

Safety systems are shown separately rather than at a level. Their segregation is a requirement in its own right, not a consequence of where they appear on a drawing.

The Purdue model level is not a security zone

This is the point that matters most. Levels describe function. Zones are defined by shared security requirements and derived from risk. They frequently cut across levels.

Two outcomes a level-equals-zone approach would miss, both of which are correct:

• A high-criticality area at level 1 placed in its own zone, separate from other level 1 equipment, because the consequence of its compromise is materially different.
• A safety system placed in its own zone regardless of which level it appears at.

Use the Purdue model to reason about where things sit and what should legitimately talk to what. Then draw zones from consequence, required protection, operational purpose and user population — which is a different exercise.

Where real plants depart from the Purdue model

Draw the idealised diagram and you have documented an architecture you do not have. The departures are the risk, so record those instead.

For each departure record where it is, why it exists, what it means for risk, and whether it will be corrected or compensated. That record is worth considerably more than a clean drawing.

Mapping your plant onto the Purdue model

Assign a level to every asset in your inventory, including auxiliary and building systems. An HVAC controller sharing a network with level 2 is at level 2 for security purposes, whatever the facilities team calls it.

Where an asset cannot be assigned cleanly, that is itself a finding worth recording. Dual-homed devices and vendor packages are the usual cases, and they are usually the ones that matter.

Is the Purdue model obsolete?

You will hear this argued, usually on the grounds that cloud services, industrial internet deployments and remote operations break the neat hierarchy. They do — but that is an argument for recording departures, not for discarding the vocabulary.

The model remains the clearest way to explain to a mixed audience why a connection from a business system directly to a controller is a problem. What it is not is a security architecture on its own, and it never claimed to be.

How the Purdue model feeds an IEC 62443 zone model

The practical sequence:

1. Map assets to levels using the Purdue model, and record the departures.
2. Establish worst-case consequence through a high-level risk assessment.
3. Group assets into candidate zones by shared security requirements — which may or may not follow level boundaries.
4. Apply the mandatory separations: IACS from non-IACS, safety from basic control, wireless from wired.
5. Enumerate every crossing and define it as a conduit.
6. Assign target security levels per zone and conduit.

Step 1 is where the Purdue model earns its place. Steps 3 onward are where it stops being the authority.

The demilitarised zone at level 3.5

The one part of the Purdue model that is close to a security control in its own right is the DMZ. The pattern is two enforcement points with a brokering zone between them, trusted by neither side.

What belongs there: replicated historians, reporting servers, file transfer brokers, patch staging, remote access jump hosts, time relays. What does not: control functions of any kind, the authoritative source of anything the plant depends on, engineering workstations, or enterprise business systems.

The rule that makes it work is direction. No session should originate on the enterprise network and terminate on a control device. If one does, you have a third network segment rather than a DMZ.

Segmenting a flat network without stopping the plant

Most sites reading this will recognise the first departure in the table above: a flat network spanning several levels, grown over a decade, with no internal boundaries. The honest question is not how to draw the ideal architecture but how to get from here to there without an outage.

The route that works is incremental and starts with visibility rather than enforcement. Put passive monitoring at the points where boundaries will eventually sit and watch the traffic for a full production cycle, including a startup and a shutdown. That record tells you what genuinely communicates with what, which is almost never what the drawings say.

From there, implement boundaries in the order that buys the most containment per unit of operational risk: the enterprise edge first, then the safety system, then high-consequence areas, then everything else. Each boundary starts in monitor-only mode so you can see what it would have blocked before it blocks anything.

Record the whole thing as a deferred separation with compensating measures and a date. A plan with a target architecture, an order and a schedule is a managed position that an assessor will accept. An idealised diagram filed as though it were reality is not.

Interim measures that genuinely help

While the segmentation programme runs, these reduce exposure without major work: access control lists on existing layer 3 boundaries, private VLANs, port security on managed switches, disabling unused switch ports, and removing the dual-homed connections that bridge levels. None of them is a substitute for proper zoning, but all of them are cheaper than an incident.

Frequently asked questions

How many Purdue model levels do we need to implement?

None, as such — it is a reference model, not a requirement. What you need is segmentation proportionate to assessed risk. The levels help you reason about where boundaries belong; they do not tell you how many to build.

Does IEC 62443 require the Purdue model?

No. IEC 62443 requires partitioning into zones and conduits based on shared security requirements. The Purdue model is a widely used input to that thinking, but the standard does not mandate it and a compliant zone model may look nothing like the hierarchy.

Where do wireless and remote access sit?

Neither maps cleanly onto a level, which is one of the model’s real limitations. Both are handled as separate zones with their own conduits — wireless segmented from the wired IACS, and remote access entering through a controlled jump host in the DMZ rather than at whatever level the target sits.

What about IIoT devices reporting to the cloud?

This is the departure worth taking most seriously. A device at level 0 or 1 with its own outbound internet path bypasses every boundary the model implies. Record it, assess it, and confirm the plant can still operate when that connection is severed.

Where to go next

Once you have mapped the levels and recorded the departures, the actual security work is partitioning: our guide to IEC 62443 zones and conduits covers the sequence and the eight questions that expose a weak model. Assigning protection strength comes next, in IEC 62443 security levels.

If you are working out which parts of the standard apply to you, IEC 62443 parts explained sorts them by role. The partitioning methodology itself is IEC 62443-3-2.

Our IEC 62443 Toolkit includes a reference architecture and zone model guide that works exactly this way — map to the Purdue model, record the departures, then partition from risk — alongside the zone and conduit register, design rationale report and segmentation standard. The Purdue model gets you a shared picture; the zone model is what actually contains a compromise.