The Purdue model still holds: Zero Trust modernises it without replacing it

If you run an industrial network, the Purdue model is probably still the map on your wall. It is the reference almost every OT team reaches for to explain how a plant is layered, from the sensors on the floor up to the business systems at the top. It is a good map. The problem is the territory has changed underneath it.

The Purdue model was designed for a world that was hierarchical, deterministic and, above all, isolated. Traffic moved up and down the levels in predictable ways, and a single firewall in the middle was enough to keep the office network and the control network apart. That world no longer exists. Industrial Internet of Things (IIoT) sensors now talk straight to the cloud, bypassing the hierarchy entirely, and the perimeter that was supposed to hold the line has become a door everyone walks through.

This article explains where the Purdue model still holds, where it breaks in practice, and how a Zero Trust approach modernises its zones and conduits without asking you to rip anything out.

What the Purdue model is, and what it assumed

The Purdue model, more formally the Purdue Enterprise Reference Architecture (PERA), came out of work at Purdue University and later fed into the ISA-95 standard for integrating enterprise and control systems. It organises an industrial environment into stacked levels:

• Level 0, the physical process: the sensors and actuators that touch the real world.
• Level 1, control: programmable logic controllers (PLCs) and remote terminal units (RTUs) that run the process.
• Level 2, supervision: the SCADA systems and human-machine interfaces (HMIs) that operators watch.
• Level 3, site operations: manufacturing execution systems (MES), historians, and the systems that coordinate a site.
• Level 3.5, the industrial DMZ: a demilitarised zone that sits between OT and IT as a buffer.
• Levels 4 and 5, enterprise IT: the business network, ERP, email, and everything corporate.

The design rested on a few assumptions. Networks were effectively air-gapped, or close to it. Traffic flowed vertically and predictably between adjacent levels. Inside any given level, devices trusted each other. And the whole IT-to-OT relationship was mediated by one chokepoint: the Level 3.5 DMZ.

Those assumptions held for decades. They do not hold now.

Where the Purdue model breaks in 2026

The model has not become wrong. The conditions it depended on have eroded, in four specific ways.

IIoT short-circuits the hierarchy. Modern sensors and gateways often connect directly to a cloud platform for telemetry or remote management. That traffic does not climb the Purdue levels and pass through the DMZ; it leaves from somewhere low in the stack and goes straight out. The hierarchy the model assumes is quietly bypassed.

The Level 3.5 perimeter is blind to modern flows. A DMZ firewall is built to inspect north-south traffic, the kind that moves up and down between IT and OT. It has far less to say about east-west traffic inside a zone, and little visibility into the protocols and cloud connections that now cross the boundary. The chokepoint is still there; it just no longer sees most of what matters.

Trust inside a zone is flat. Once an attacker is inside a zone, the Purdue model offers nothing more to stop them. Devices trust each other by default, so lateral movement, the sideways spread from one compromised host to the next, is largely unobstructed. The model defends the boundaries between levels, not the space within them.

Remote access via VPN reopens everything. The standard way to reach an OT system from outside is a VPN, which places the remote user on the network. That grants broad network reach rather than access to one specific machine, and broad reach is exactly the surface that lateral movement exploits. Every contractor laptop becomes a potential path into the zone.

None of this means defence in depth was a bad idea. It means the layers need a trust model that travels with the traffic, not one that lives only at the perimeter. For the wider picture of why convergence dissolves the perimeter, see our IT/OT convergence security solution.

Zero Trust does not replace Purdue, it modernises the conduits

It is tempting to read "the Purdue model is outdated" as "throw it away." That is the wrong conclusion. The levels are still a sound way to describe a plant, and the idea of zones and conduits, groups of assets and the controlled paths between them, is exactly right. What needs to change is the trust assumption inside and between those zones.

Zero Trust replaces implicit trust with verification on every request: who is this, what device are they on, and is that device in a healthy posture, checked each time rather than once at the door. Applied to the Purdue model, this keeps the structure and upgrades the conduits:

• Zones stay as groupings of assets, but trust inside them is no longer flat. Each flow is verified individually, which is what micro-segmentation means in practice: not one VLAN per zone, but one verified path per authorised flow.
• Conduits stop being physical cabling or static VLANs and become software policy. A conduit is defined by who is allowed to talk to what, and enforced wherever the traffic is, rather than only at a DMZ.

The honest boundary here matters. Zero Trust modernises the conduits and the IT-OT boundary. It does not change the physical topology of Levels 0 to 2, and it does not touch the controllers. This zone-and-conduit vocabulary is not arbitrary either: it is exactly what IEC 62443, the industrial cybersecurity standard, formalises, and where we map its foundational requirements onto a Cloudflare architecture.

Modernising OT segmentation with Cloudflare

A Zero Trust layer is not an abstraction; it is a set of capabilities that sit as an overlay around the existing network. Three of them do most of the work of modernising Purdue-style segmentation.

Conduits in software. Cloudflare WAN (formerly Magic WAN) uses virtual networks to keep traffic isolated between environments. A conduit becomes a routing policy rather than a cable run, so the segmentation the Purdue model calls for is enforced in software and can be changed without rewiring a plant.

Remote access without lateral movement. Cloudflare Access applies Zero Trust Network Access (ZTNA): instead of putting a remote user on the network like a VPN, it grants reach to one specific system, over SSH, VNC or RDP, after verifying identity and device posture on each connection. The user never lands on the network, so there is no broad surface to move laterally across.

Micro-segmentation. Because every flow is verified on its own terms, containment becomes logical rather than physical. A compromised host in one zone does not inherit free movement; it faces a policy check at every conduit, which is the practical answer to the flat-trust problem the Purdue model leaves open.

For the capability-by-capability detail behind each of these, including Gateway, Tunnel and WAF, see our breakdown of how Cloudflare secures the IT/OT boundary, feature by feature.

The modernised Purdue model: a reference architecture

The point of the exercise is not to redraw the plant. It is to keep the Purdue levels as they are and overlay a trust layer on the conduits between them. The table below maps each element of the model to what limits it today and how a Zero Trust layer modernises it.

Expert tip: on an existing installation, use the mapping exercise to model each conduit as a virtual network rather than as one more firewall rule. You then change segmentation by editing a policy instead of touching the physical network, and your map stays current as the installation evolves, rather than having to be pieced back together by reading each switch's configuration.

What stays the same: the honest boundaries

A Zero Trust overlay is precise about its reach, which means being equally precise about what it does not touch.

The physical levels stay physical. Levels 0 to 2, the sensors, the PLCs, the control loops, are not modified by a network layer. Cloudflare protects the conduits and the boundary; it does not run on the controller, and it does not change how the process is wired.

And visibility inside a zone is a different job. Inspecting OT protocols such as Modbus, DNP3 and S7, discovering industrial assets, and detecting anomalies in the process itself all require seeing inside the OT network, not just at its edge. That is the territory of OT-native monitoring platforms, which operate alongside the boundary layer. Where each layer fits is the subject of our comparison of Cloudflare and OT-native vendors.

How Brixio modernises Purdue segmentation without downtime

As a Cloudflare Authorised Service Delivery Partner (ASDP), Brixio deploys the segmentation layer as an overlay: it sits around the existing equipment without modifying the controllers and without interrupting production. The method runs in four phases:

1. Audit and discovery: map the real zones, conduits and flows, including the IIoT short-circuits and shadow connections that the documentation misses.
2. Architecture: translate the Purdue zones and conduits into Cloudflare policy, so segmentation is enforced in software rather than inferred from hardware.
3. Documentation and mapping: produce the segmentation map that an audit or a NIS2 review can rely on.
4. Continuous operation: keep the policies aligned as the environment and the threats evolve.

The limit stays clear throughout. Brixio modernises the network and boundary layer; the physical levels and the monitoring inside the zones stay with the OT teams and OT-native tools. This work is most relevant for regulated, asset-heavy sectors such as manufacturing and energy, and connects back to the broader IT/OT convergence security solution. It builds on the rest of the cluster: why IT and OT security follow opposite rules, and what the 2026 threat data shows about where the risk concentrates.

Modernise your OT segmentation

If your segmentation still rests on a single perimeter and static VLANs, the first step is to map your real zones and conduits, then identify where a Zero Trust layer modernises them without touching your controllers. That is exactly what we help you work out. Map your OT segmentation with Brixio.