The Purdue Model Revisited: Modern OT Network Architecture (2026 Guide)

23

For decades, the Purdue Enterprise Reference Architecture (often shortened to “the Purdue Model”) has been the most common mental model for industrial control system (ICS) and OT network segmentation. It helped plants separate business systems from control systems, reduce blast radius, and communicate architecture simply—especially to mixed teams of operations, engineering, IT, and cybersecurity.

But OT networks have changed:

• Plants are adopting Industrial IoT (IIoT), edge computing, and cloud analytics.
• Remote access is now a business requirement (vendors, OEMs, integrators, corporate support).
• Virtualization and container platforms have moved into OT.
• Multi-site architectures now rely on SD-WAN, LTE/5G, and managed connectivity.
• Regulations and best practices increasingly align to IEC 62443 “zones and conduits” rather than fixed levels.

So the question isn’t “Is Purdue dead?”
The question is: How do we use Purdue correctly in modern OT network architecture—without letting it become an oversimplified diagram that fails under real operational needs?

This article gives you a practical, modern blueprint: what to keep from Purdue, what to update, and how to implement segmentation, data flows, remote access, and cloud connectivity with resilience-first design.

The Purdue Model is a layered OT reference architecture that separates industrial control networks from enterprise IT. In modern OT network architecture, Purdue is best treated as a conceptual segmentation guide—combined with IEC 62443 zones and conduits—so organizations can securely support remote access, cloud/IIoT data paths, edge computing, and virtualization while maintaining safe, reliable plant operations.

What the Purdue Model Originally Solved (and Why It Worked)

The Purdue Model helped organizations answer four core questions:

1. Where does control happen? (controllers close to the process)
2. Where does supervision happen? (SCADA/HMI and operations)
3. Where does site-level support happen? (historians, patching, backups, OT services)
4. Where does enterprise business happen? (ERP, email, finance, corporate IT)

Most importantly, it promoted a simple principle:
Don’t let enterprise systems directly access control systems.
Instead, introduce a boundary and control data movement across it.

That boundary evolved into the concept many teams call the Industrial DMZ (sometimes “Level 3.5”).

---

Purdue Model Levels (Traditional View) — and the “Modern Interpretation”

Traditional Purdue Levels (quick refresher)

• Level 0: Physical process (sensors, actuators)
• Level 1: Basic control (PLCs, RTUs, drives, I/O)
• Level 2: Supervisory control (HMIs, SCADA servers/clients, local engineering)
• Level 3: Site operations (historians, OT services, patch management, backups)
• Level 3.5: Industrial DMZ (broker zone between IT and OT)
• Level 4: Enterprise IT (business applications, corporate services)
• Level 5: External networks (internet, partners, cloud)

Modern interpretation (the key update)

In modern OT architecture, the “levels” are less important than the security and operational boundaries:

• Zones: groups of assets with similar criticality and trust requirements
• Conduits: controlled communication paths between zones (firewalls, gateways, proxies)

This is why many organizations now treat Purdue as a communication tool (a shared map), while implementing design using IEC 62443 zones and conduits.

---

The Big Problem with “Purdue-as-a-Diagram”

Many incidents, outages, and failed modernization projects share a root cause:

Teams draw Purdue once, then treat it as the architecture—even as the plant changes.

Common symptoms:

• A “Level 2 network” becomes a flat VLAN with everything from HMIs to IP cameras.
• A “Level 3 historian” becomes an all-purpose server that also runs AV management, file shares, and remote tools.
• Cloud connectivity is bolted onto Level 2 because “we needed the data quickly.”
• Vendors are allowed inbound VPN access to PLC networks because “they need to troubleshoot.”

Purdue didn’t fail—oversimplification did.
Modern OT requires a data-flow-first design approach.

---

Purdue Model Revisited: The 6 Design Principles of Modern OT Networks

If you only take one section from this article, make it this one.

1) Design around safety and availability first

OT priorities differ from IT:

• Availability and determinism often outrank confidentiality.
• “Patch Tuesday” doesn’t exist when downtime costs $250k/hour.
• Any security control must respect process constraints and vendor support boundaries.

2) Segment by function and consequence (Zones), not just by “levels”

Group assets by:

• what they do (control, safety, operations support)
• impact if disrupted
• change frequency
• vendor ownership and support model

3) Make data flows explicit: northbound, southbound, east-west

• Northbound: OT to IT/cloud (telemetry, reports)
• Southbound: commands/configuration from engineering tools to controllers
• East-west: peer-to-peer within OT (controller-to-controller, HMI-to-SCADA)

Modern plants break when you secure northbound flows well but ignore east-west reality.

4) Use the Industrial DMZ as a broker, not a hallway

The DMZ should contain services that:

• terminate sessions
• broker/replicate data
• enforce policy
• create inspection points

The DMZ should not be a place where “we put a server because we didn’t know where else it goes.”

5) Prefer one-way or mediated integrations for analytics

Most business use-cases need OT data, not OT control. Architect for:

• replication
• publish/subscribe
• buffering and store-and-forward
• API gateways

6) Operationalize the architecture

An OT architecture that isn’t maintained becomes fiction. You need:

• ownership (who approves changes?)
• documentation tied to reality
• asset inventory + network visibility
• tested backup/restore and failover

---

Purdue + IEC 62443: A Practical Mapping That Actually Works

Instead of arguing “Purdue vs IEC 62443,” treat them as complementary:

• Purdue gives you an intuitive layered story.
• IEC 62443 gives you implementable segmentation rules (zones/conduits) and security levels.

Example mapping (typical)

Purdue concept	IEC 62443 concept	What you implement
Level 0–1 control	Control zone	Controller networks, I/O networks, drive networks, strict change control
Level 2 supervision	Supervisory zone	SCADA/HMI services, operator stations, app servers
Level 3 operations	Operations zone	Historian, OT patch staging, backup, AD (if used), monitoring
Level 3.5 DMZ	DMZ zone	Jump hosts, remote access gateways, data brokers, replication nodes
Level 4 enterprise	Enterprise zone	ERP/BI/SOC tools, corporate AD, enterprise data lake

---

Modern Purdue: What Goes Where (A Practical Placement Guide)

Level 0–1 (Process + Control): Keep it tight and deterministic

Typical assets:

• PLCs, RTUs, DCS controllers
• Remote I/O, safety PLCs (often separate zone)
• Drives (VFDs), MCC interfaces
• Instrumentation networks (HART/fieldbus gateways)

Modern best practices:

• Separate safety from basic control where possible (separate zones).
• Avoid routing business traffic anywhere near control VLANs.
• Minimize services: controllers don’t need to “talk to the internet.”

Level 2 (Supervisory): Treat as a production-critical app tier

Typical assets:

• SCADA servers, HMI servers
• Operator HMIs / thin clients
• Alarm/event servers
• Engineering workstations (sometimes here, sometimes separate engineering zone)

Modern best practices:

• Build application tiers (e.g., SCADA core vs clients vs engineering).
• Control admin access: most compromises begin with workstation abuse.
• Avoid letting Level 2 become “anything OT that has an Ethernet port.”

Level 3 (Site Operations): OT shared services—with strict discipline

Typical assets:

• OT historian (primary)
• Backup infrastructure for OT systems
• Patch staging / update repositories
• OT domain services (if used), license servers
• OT monitoring (passive sensors, syslog, time services)

Modern best practices:

• Keep Level 3 “site OT services,” not a shadow IT.
• Be cautious running general enterprise tools directly in OT.
• Treat Level 3 as the place where you implement recovery: gold images, backup, restore testing.

Level 3.5 Industrial DMZ: The most misunderstood layer

Typical assets:

• Remote access gateway + MFA (brokered access)
• Jump hosts (bastions)
• Historian replication node (or data diode receiver)
• File transfer gateway / malware scanning enclave
• API gateway / MQTT broker bridge (depending on design)
• Proxy services and inspection points

Modern best practices:

• The DMZ should terminate sessions and mediate access.
• Avoid direct IT-to-OT connections “through the firewall.”
• Prefer outbound OT connections to DMZ brokers rather than inbound sessions into OT.

Level 4 (Enterprise): Consumers of OT data, not controllers of OT

Typical assets:

• BI dashboards, data lake/warehouse
• ERP, CMMS, quality systems
• SOC/SIEM platforms
• Corporate remote support tools (carefully constrained)

Modern best practices:

• Pull data via DMZ replication, not direct queries into OT.
• Align IT change cycles with OT constraints through governance.

---

Reference Architecture: Modern OT Network (Purdue Revisited)

Below is a practical reference layout that fits Purdue thinking, but implements modern “zones and conduits.”

                Enterprise / IT Zone (Purdue L4)
    +---------------------------------------------------+
    | BI / ERP / CMMS / SOC / SIEM / Data Lake / IdP     |
    +------------------------+--------------------------+
                             |
                             | Conduit: tightly controlled (FW + proxy)
                             v
               Industrial DMZ Zone (Purdue L3.5)
    +---------------------------------------------------+
    | Remote Access Gateway (MFA)  |  Jump Host (bastion)|
    | Historian Replica / Broker   |  File Transfer GW    |
    | API Gateway / MQTT Bridge    |  Patch Relay (opt)   |
    +------------------------+--------------------------+
                             |
                             | Conduit: OT boundary firewall(s)
                             v
              Site Operations Zone (Purdue L3)
    +---------------------------------------------------+
    | OT Historian (primary) | Backup | OT Monitoring    |
    | Patch Staging          | Time/NTP/PTP | Asset Mgmt |
    +------------------------+--------------------------+
                             |
                             | Conduit: internal segmentation
                             v
             Supervisory Zone (Purdue L2)
    +---------------------------------------------------+
    | SCADA Servers | HMI Servers | Operator Stations    |
    | Engineering Workstations (separate sub-zone ideal) |
    +------------------------+--------------------------+
                             |
                             | Conduit: cell/area boundaries
                             v
              Control Zone(s) (Purdue L1)
    +---------------------------------------------------+
    | PLCs | DCS Controllers | RTUs | Drives | Remote I/O |
    +------------------------+--------------------------+
                             |
                             v
                Process Zone (Purdue L0)
    +---------------------------------------------------+
    | Sensors | Valves | Motors | Actuators | Equipment  |
    +---------------------------------------------------+

What’s “modern” here? The architecture is built around brokered conduits and explicit data paths, not “levels with one firewall.”

Modern Data Flows: The Part Purdue Diagrams Often Ignore

Northbound OT data (telemetry) — modern patterns

Common modern patterns include:

1. Historian replication (OT → DMZ → IT)
   • OT historian remains authoritative for operations.
   • Replication node in DMZ pushes curated data to IT.
2. Publish/subscribe via MQTT (OT/Edge → DMZ broker → IT/Cloud)
   • Great for buffering and intermittent connectivity.
   • Scales well for multi-site.
3. OPC UA aggregation (Control/Supervisory → Ops → DMZ)
   • Useful when you need semantic models, not just tags.
   • Requires certificate lifecycle discipline.
4. File-based exchange (reports, batch records, exports)
   • Use a file transfer gateway with malware scanning and auditing.

Best practice: Treat these as integration products, not ad-hoc firewall rules.

Southbound access (engineering and support) — where risk concentrates

Most high-impact OT incidents involve privileged access paths:

• engineering workstations
• remote vendor access
• “temporary” VPNs that become permanent

Modern best practice: Put privileged access behind:

• MFA
• session recording (where feasible)
• jump hosts
• time-based approvals
• least privilege and role separation

East-west OT traffic (within OT) — the hidden blast radius

Even if IT/OT boundary is strong, lateral movement within OT can be catastrophic.

Modern segmentation should include:

• cell/area zones
• controller network segmentation
• strict rules for peer-to-peer protocols
• OT-aware monitoring (passive where possible)

The Industrial DMZ Revisited: From “Network Buffer” to “Security Platform”

The Industrial DMZ is no longer just “a VLAN between two firewalls.”
In modern OT architecture, it becomes a platform for controlled interaction.

What belongs in the DMZ (high-value candidates)

• Remote access gateways (vendor + employee) with MFA and policy
• Jump hosts (bastions) for interactive sessions into OT
• Historian replication nodes
• Protocol brokers / API gateways
• File transfer gateways
• Patch and signature staging (when designed carefully)
• Visibility tooling (log aggregation, NDR sensors, time sources in some cases)

What should not be in the DMZ

• Long-lived “dual-homed” servers with one leg in IT and one in OT (common anti-pattern)
• Anything that becomes a general-purpose shared server for convenience
• Direct database access paths from IT apps into Level 2 SCADA databases

DMZ design rules (simple and enforceable)

• Rule 1: Sessions terminate in the DMZ (no direct IT-to-OT interactive access).
• Rule 2: Use application proxies/gateways rather than broad port forwarding.
• Rule 3: Treat DMZ assets as high-risk and monitor them aggressively.
• Rule 4: Make “break-glass” access time-bound, logged, and reviewed.

---

Remote Access Architecture (Modern OT Reality)

Remote access isn’t optional anymore. The question is whether you implement it intentionally.

A secure and operationally workable pattern

1. User authenticates to remote access gateway in DMZ (MFA + device posture if possible)
2. User accesses jump host (role-based access)
3. Jump host accesses OT targets (HMI/SCADA/engineering tools) through restricted conduits
4. Sessions are logged; access is time-bound; approvals enforced

Practical segmentation tip

Create separate remote access “lanes”:

• Lane A: vendor/OEM support (restricted targets, strong monitoring)
• Lane B: internal engineering (broader, still controlled)
• Lane C: read-only operations dashboards (when applicable)

Avoid these common mistakes

• Always-on site-to-site VPN that drops vendors directly into Level 2
• Shared accounts for vendor access
• “Temporary” firewall openings without expiry
• Remote desktop exposure without jump host controls

---

Cloud and IIoT: The Purdue Model Didn’t Anticipate This—So You Must

Cloud integration is where teams either modernize successfully or accidentally dismantle segmentation.

Cloud use-cases that drive OT connectivity

• predictive maintenance and condition monitoring
• energy optimization and ESG reporting
• fleet-level analytics across sites
• digital twins and asset performance management
• centralized patch/asset insights (handled carefully)

The modern architectural question

Where does the cloud connection terminate?

Preferred answers:

• At a DMZ broker (API gateway / MQTT bridge)
• At a site operations integration tier (then brokered outward)
• At an edge platform designed for store-and-forward

Risky answer:

• Direct outbound from Level 2 SCADA servers to cloud endpoints

A modern “edge-to-cloud” pattern that fits Purdue thinking

• Level 1/2: control and supervision remain local
• Level 3: OT historian and OT edge compute aggregate data
• Level 3.5: DMZ brokers publish curated datasets outward
• Level 4/5: enterprise/cloud consumes data

This preserves operational independence: the plant keeps running even if the cloud is down.

---

Virtualization and Containers in OT: Where They Fit in Purdue-Revisited

Modern OT increasingly includes:

• virtualized SCADA servers
• VMs for historians and engineering tools
• containerized analytics at the edge (in some environments)

Key architectural implications

• Hypervisors become “infrastructure critical” like a switch or a PLC rack.
• East-west traffic inside virtualization clusters can bypass traditional controls.
• OT change management must include VM templates, snapshots, and backup validation.

Practical recommendation

Treat virtualization platforms as their own zone, with conduits to:

• supervisory applications
• operations services
• management plane (very restricted)

Do not assume “it’s internal so it’s safe.” The management plane is a high-value target.

---

Microsegmentation vs Practical OT Constraints

“Microsegmentation everywhere” sounds good, but OT environments have realities:

• Legacy devices can’t authenticate modern controls.
• Some protocols are chatty or broadcast-heavy.
• Vendor support may require specific connectivity.

A pragmatic approach (recommended)

Start with macro segmentation that delivers immediate blast-radius reduction:

1. IT/OT boundary + DMZ
2. Separate supervisory zone from operations services
3. Separate engineering workstations from operator HMIs
4. Cell/area segmentation in Level 2/1
5. Safety zone separation (where feasible)

Then progress to finer segmentation where it won’t break operations.

---

Practical OT Segmentation Patterns (That Work in Real Plants)

Pattern 1: Cell/Area Zones (manufacturing-friendly)

Segment the plant into production cells:

• each cell has its own PLCs, HMIs, drives, and local switches
• conduits allow only required traffic to SCADA/historian

Benefits: limits lateral movement and reduces troubleshooting scope.

Pattern 2: Supervisory Core + Access Layer (SCADA-focused)

• SCADA servers in a “core” subnet/zone
• operator clients in an “access” zone
• engineering tools in a separate “engineering” zone
• strict conduits between them

Benefits: reduces risk from workstation compromise.

Pattern 3: Historian-as-a-Hub (operations-focused)

• OT historian collects from Level 2/control zones
• only historian (or a broker) can send data to DMZ/IT

Benefits: centralizes and standardizes northbound data.

Pattern 4: Edge Gateway per Line/Skid (IIoT-focused)

• edge gateway near equipment collects data
• gateway publishes to DMZ broker (MQTT or similar)
• no inbound cloud connectivity to control devices

Benefits: supports modernization without exposing controllers.

---

OT Firewalling and “Conduits”: How to Make Rules Sustainable

Segmentation fails when firewall rules become unmanageable.

Rule design tips

• Build conduits around services, not around “any-any between subnets.”
• Use explicit allowlists for:
  • historian collectors
  • SCADA drivers
  • management tooling
  • time sync (NTP/PTP)
• Implement a ticketed process for changes, with expiry for exceptions.

Naming and documentation (critical for operations)

Document conduits like products:

• Conduit-OT-Historian-Collect
• Conduit-RemoteAccess-JumpToEngineering
• Conduit-IT-Consumes-OT-Data

If you can’t explain what a conduit is for, it’s probably too broad.

---

Monitoring and Visibility: The Missing Layer in Most Purdue Diagrams

A modern OT architecture must include visibility as a first-class component:

• passive network monitoring (ICS-aware NDR)
• centralized logging in OT operations zone (forward selected logs to SOC via DMZ)
• asset inventory tied to network reality
• alerting tuned for OT (avoid noise that operators ignore)

Where monitoring fits

• Sensors at key conduits (IT/OT boundary, DMZ-to-OT, between major OT zones)
• Log aggregation typically at Level 3
• SOC integration through DMZ brokers

Goal: detect misconfigurations and abnormal behavior early without breaking determinism.

---

Time Synchronization: Small Detail, Big Operational Payoff

Time matters for:

• alarm/event correlation
• incident response
• quality investigations
• sequence-of-events analysis

Modern best practice (conceptually)

• authoritative time sources at operations layer
• controlled distribution downward
• avoid uncontrolled NTP from enterprise directly to controllers

(Exact implementation depends on whether you use NTP, PTP, vendor time services, and your process requirements.)

---

“Purdue 2.0” Checklist: Modern OT Network Architecture Requirements

Use this as an actionable architecture review list.

Segmentation & boundaries

•  IT/OT boundary defined with explicit conduits
•  Industrial DMZ implemented as a broker zone (not a transit hallway)
•  Separate zones for supervisory, operations services, and control
•  Engineering workstations isolated from operator stations where feasible
•  Safety systems segmented as their own zone (where applicable)

Data flows

•  Northbound data path uses replication/brokers (historian replica, MQTT bridge, API gateway)
•  Southbound access is brokered (jump host + MFA + approvals)
•  East-west OT traffic constrained by cell/area segmentation

Resilience & operations

•  Architecture supports plant operation during IT/cloud outages
•  Backup/restore procedures tested for SCADA/historian/virtualization
•  Change control process for firewall rules, switch config, and critical servers
•  Time synchronization architecture documented and monitored

Monitoring & governance

•  OT visibility at conduits (passive sensors, logs)
•  Incident response roles defined across IT/OT
•  Vendor access contracts define method, scope, and logging expectations

---

Common Anti-Patterns (and Better Alternatives)

Anti-pattern: “Dual-homed servers” bridging IT and OT

Why it’s risky: creates uncontrolled paths and complex troubleshooting.
Better: single-homed servers with brokered services in the DMZ.

Anti-pattern: Cloud agents installed on SCADA servers

Why it’s risky: expands attack surface and change frequency on critical nodes.
Better: export curated data from historian/edge through DMZ brokers.

Anti-pattern: Flat Level 2 network

Why it’s risky: increases blast radius and broadcast issues.
Better: cell/area segmentation and supervised conduits.

Anti-pattern: Vendor VPN directly to PLC subnet

Why it’s risky: bypasses supervision and auditing.
Better: DMZ remote access gateway → jump host → controlled target access.

---

Example: A Modernized Purdue Architecture for a Multi-Site Manufacturer

Scenario: 12 plants, mixed PLC vendors, centralized analytics, frequent OEM support.

Recommended approach:

• Each plant implements:
  • Control zones per line/cell
  • Supervisory zone with SCADA/HMI
  • Operations services zone with historian + backup + monitoring
  • DMZ zone with remote access gateway, historian replica, file transfer gateway
• Corporate IT consumes data from:
  • DMZ replicas via APIs or replication
  • MQTT bridge for high-frequency telemetry where needed
• Vendor access:
  • only through DMZ gateway with time-bound approvals
  • recorded sessions for high-risk systems

Outcome:

• Plants remain operational if corporate WAN/cloud is down.
• Data pipelines scale without opening inbound access to control networks.
• Vendor support becomes auditable and safer.

FAQs

Is the Purdue Model still relevant for OT networks?

Yes. The Purdue Model is still useful as a high-level segmentation map, but modern OT architectures typically implement segmentation using IEC 62443 zones and conduits, with Purdue used to communicate where systems generally belong.

What is “Level 3.5” in the Purdue Model?

Level 3.5 is commonly referred to as the Industrial DMZ—a buffer zone between enterprise IT (Level 4) and OT (Levels 0–3). In modern architectures, it hosts brokers like jump servers, remote access gateways, and historian replication nodes.

How do you connect OT to the cloud safely?

The safest approach is to broker OT-to-cloud data through an OT integration tier and/or Industrial DMZ using replication, publish/subscribe, buffering, and API gateways—rather than allowing direct cloud connectivity from SCADA or controllers.

What should be in an OT DMZ?

Common DMZ components include remote access gateways with MFA, jump hosts, historian replication nodes, file transfer gateways, and API/messaging brokers that control and monitor data exchange between IT and OT.

What’s the biggest mistake teams make when using Purdue?

Treating Purdue levels as a static diagram instead of designing explicit data flows and enforceable conduits. Modern OT needs maintained segmentation, brokered access, and resilience planning—especially for remote access and cloud.

---

Glossary (Quick Definitions)

• OT (Operational Technology): systems that monitor/control physical processes
• ICS: industrial control system environment (controllers, SCADA, networks, safety)
• Purdue Model: layered reference model for IT/OT separation
• Industrial DMZ: broker zone separating IT from OT
• Zone: group of systems with similar trust/criticality (IEC 62443)
• Conduit: controlled communication path between zones (firewalls, gateways, proxies)
• SCADA/HMI: supervisory monitoring/control and operator interfaces
• Historian: time-series system storing process values/events
• East-west traffic: lateral communications inside OT zones
• Northbound data: OT data sent to IT/cloud for reporting/analytics

Conclusion: Purdue Isn’t Dead—But It Must Be Operationalized

“The Purdue Model revisited” is really about changing how you use Purdue:

• Use Purdue to communicate the big picture.
• Use IEC 62443 zones and conduits to implement segmentation.
• Treat the Industrial DMZ as a broker platform for remote access and data exchange.
• Make data flows explicit and resilient—so the plant runs safely even when IT or cloud services fail.