What is the Purdue Model?

Key takeaways

• The Purdue Model is a reference, not a mandate. It gives names and structure to industrial network architecture; the structure is useful even when real installations break it.
• Real-world mid-market manufacturer facilities do not implement strict Purdue separation. Engineering workstations, vendor remote access, and shared identity break the original assumptions routinely.
• The model remains valuable because it provides a vocabulary for discussing the boundaries that matter, even when those boundaries are imperfect.
• For mid-market manufacturers, a simplified Purdue-derived architecture (clear IT/OT separation, industrial DMZ, segmented OT) captures most of the security value at manageable implementation cost.
• The Purdue Model underlies IEC 62443 and informs how NIST CSF 2.0 and CMMC assessors think about industrial environments.

What are the levels of the Purdue Model, and what lives at each?

The Purdue Model defines six levels, numbered 0 through 5, with progressively higher levels representing more business-oriented systems.

Level 0: Process. The physical process itself. Sensors and actuators. The instruments that measure temperature, pressure, position, presence. The actuators that move valves, motors, heaters, and lights. This is the physical reality the rest of the architecture exists to monitor and control.

Level 1: Basic control. PLCs and similar controllers. The devices that execute control logic on inputs from Level 0 and drive outputs back to Level 0. Time-critical, deterministic, often vendor-specific firmware. See What is a PLC attack?.

Level 2: Supervisory control. HMIs, local SCADA systems, batch managers. Operator-facing screens that display state and accept commands. Time-sensitive but not strictly real-time. Typically Windows-based.

Level 3: Site operations. Manufacturing operations management (MOM), MES, historians, alarm management, plant-wide engineering systems. Less time-critical than Level 2. Often Windows-based servers.

Industrial DMZ (between Level 3 and Level 4). Sometimes called Level 3.5. A controlled zone where IT and OT data flows can be inspected and mediated. Historian mirrors, jump servers, and antivirus update servers commonly live here.

Level 4: Site business systems. Enterprise resource planning (ERP), supply chain management, business intelligence at the plant level. IT-flavored systems with operational data flowing in.

Level 5: Enterprise. Corporate IT systems. Email, financials, HR, sales, marketing. The traditional IT environment, separated from operational systems by the levels below.

Each level has progressively different security requirements, change-management practices, and tolerance for disturbance. Level 0 changes affect physical safety; Level 5 changes are organizational. The hierarchy is meant to constrain the blast radius of any single change.

How modern manufacturing breaks the original Purdue assumptions

The original Purdue Model assumed strict separation between levels, with all communication routed through defined interfaces. Modern manufacturing has eroded the assumption in five specific ways.

1. Vendor remote access cuts across levels. OT vendors connect from outside (Level 5 and beyond) directly to Level 1 and Level 2 equipment through remote-access tools. The traffic does not traverse Levels 4 and 3 in the way the original model anticipated.

2. Engineering workstations are dual-homed. An engineering workstation sits at the boundary between Level 3 and Levels 1-2. It is also frequently on the IT network (Level 5) for email and productivity. The single asset spans levels that the model assumes are separated.

3. Historian data flows to enterprise analytics. Level 1 and 2 data flows through Level 3 historian to Level 5 analytics tools (Power BI, Tableau) and increasingly to cloud-hosted analytics. The data flow is necessary; the security implications are not always governed.

4. Cloud-hosted operational systems. SCADA-as-a-service, cloud-hosted historians, vendor-hosted alarm management, IoT platforms. These systems run outside the facility entirely; the Purdue Model has no clean place to put them.

5. Shared identity across levels. A single Active Directory or Entra tenant covers Levels 3, 4, and 5, and often reaches Level 2. Credential compromise at one level is credential compromise everywhere the identity is trusted.

The breakage is not a failure of the model; it reflects operational reality. The Purdue Model still provides the vocabulary for discussing the boundaries that should be enforced and the controls that mediate the crossings.

Why Purdue still matters even in a cloud-connected plant

Four reasons the model remains useful in 2026:

1. Common vocabulary. "Level 2 to Level 3 traffic" is a concise description that an engineer, an IT lead, and a security auditor can all use without misunderstanding. The vocabulary saves time and prevents architecture decisions from being lost in translation.
2. Default architecture template. New facility designs and major upgrades start from Purdue and adjust. The model is the baseline against which exceptions are documented.
3. Compliance and standards reference. IEC 62443, NIST CSF 2.0, CISA guidance, and insurance underwriting all reference Purdue-derived structures. Aligning with the model makes compliance and audit conversations easier.
4. Segmentation foundation. Even where strict layer-by-layer separation is impractical, Purdue-derived segmentation (at least IT/OT plus a DMZ plus segmented OT) captures most of the practical security value. The model is the starting point for that segmentation.

The right framing is "Purdue as reference, not Purdue as prescription". An installation that diverges from the model for documented operational reasons, with compensating controls where the original boundaries would have provided them, is appropriately Purdue-aligned. An installation that diverges from the model accidentally, without acknowledgment, has architectural debt.

Examples of Purdue boundary failures in real audits

What ARG sees in mid-market manufacturer engagements:

• Level 2 HMI reachable from Level 5. An HMI workstation in the control room joined to the corporate domain. Active Directory credentials authorize logon. A compromised corporate account reaches the HMI.
• Level 1 PLC programmable from Level 5. Engineering workstation on the corporate network with PLC programming software installed and network access to PLC programming protocols. A spear phish on the workstation reaches the PLC.
• Historian visible from the public internet. A cloud-hosted historian-mirror server with weak authentication, indexable through certificate transparency logs. The historian is supposed to sit in the industrial DMZ; in this case, it sits in a public-cloud subnet with no DMZ controls.
• Vendor remote-access tool installed at Level 1. Each vendor has its own tool; some of them establish outbound connections continuously and are reachable from the vendor's infrastructure. The traffic does not cross any documented level boundary.
• Shared service account spanning Levels 3 through 5. A service account used by historian, MES, and corporate reporting. Compromise of the account at any level reaches all levels.
• Industrial DMZ that is not actually segmented. Architecture diagram shows a DMZ; firewall rules show the DMZ subnet has bidirectional traffic with both IT and OT zones. The DMZ exists in the diagram but not in the firewall configuration.

Each finding is a Purdue boundary that has been breached by accumulated operational decisions. None of the breaches were intentional security gaps; each was an operational accommodation that traded security against convenience.

How to apply Purdue-aligned segmentation in mid-market environments

A practical Purdue-derived architecture for a mid-market manufacturer:

1. Clear IT/OT boundary. Firewall between Levels 3 and 4, with explicit allowlist rules for permitted traffic. The boundary is enforced at the firewall, not by VLAN alone.
2. Industrial DMZ. Servers that need to be reachable from both IT and OT (historian mirror, jump server, antivirus update server) live in a DMZ subnet with separate firewall rules to each side.
3. OT zone segmentation. Within OT, segment by line, by function, or by Purdue level. The exact segmentation depends on the size and layout of the plant; smaller plants can use functional segmentation, larger plants can approach Purdue level-by-level.
4. Engineering workstation isolation. Workstations that program PLCs sit in a dedicated segment with explicit egress rules. They do not browse the web or receive email from the same network position.
5. Vendor remote-access bastion. All vendor connections route through a controlled jump server in the DMZ. No direct vendor connectivity to Level 1 or 2 equipment.
6. Identity separation. Distinct accounts for engineering and office work. Where full separation is impractical, the group memberships and access rights of dual-purpose accounts are documented and reviewed quarterly.
7. Documented exceptions. Every deviation from the documented architecture is recorded with reason, owner, and target end date. Exceptions are reviewed regularly; old exceptions either get formalized or get removed.

The architecture is achievable for most mid-market manufacturers in a 12-to-24-month program. Starting from minimal OT-specific security, the segmentation produces the largest single security improvement available.

Best practices for monitoring across Purdue levels

Each Purdue level has different monitoring needs.

1. Level 0 (process). Process telemetry is monitored by operations, not by security. Anomalies (out-of-spec output, unusual setpoints) often surface before security telemetry. Coordination between operations and security on process anomalies provides early signal.
2. Level 1 (control). Program checksums, firmware version monitoring, programming-protocol traffic baselines. OT-aware monitoring tools that understand vendor-specific protocols.
3. Level 2 (supervisory). HMI activity logs, operator-account anomaly detection, SCADA configuration change tracking. Application logging where the platform supports it.
4. Level 3 (site operations). Historian access logs, MES change logs, server-level telemetry, application allowlisting alerts. Where vendor support permits, EDR.
5. Industrial DMZ. Bidirectional traffic monitoring, jump server session logging, vendor-access auditing. The DMZ is a high-value monitoring point because all cross-boundary traffic passes through it.
6. Levels 4-5 (business and enterprise). Standard IT security monitoring: EDR, SIEM, identity-provider alerts. Plus alerts for any traffic to OT-side assets.

The monitoring stack does not need to be a single product; integration of OT-aware tooling with the broader security operations function is what matters. Coordination of monitoring across levels is what makes the architecture defensible in operation.

Purdue Model FAQs

Is the Purdue Model still relevant in 2026?

Yes, as a reference model for thinking about industrial architecture and segmentation, even though the strict hierarchy is broken in most modern installations. The Purdue Model gives names and structure to a conversation that otherwise has none. It is a starting point for security architecture, not a rigid prescription.

How does the Purdue Model relate to IEC 62443?

IEC 62443 is the international standard for industrial automation and control system security; it adopts the Purdue Model levels as a foundational concept and adds zone-and-conduit architecture, security levels, and lifecycle requirements. Purdue is the architecture; 62443 is the standard built on top of it.

Can a small manufacturer implement Purdue properly?

Yes, with appropriate scoping. A small manufacturer rarely needs the full 0-through-5 separation that a refinery does; a simplified version with clear IT/OT separation, an industrial DMZ, and segmented OT zones gets most of the security value at a manageable implementation cost.

What is the difference between Purdue and zero trust?

Purdue is a layered, network-segmentation-based model where trust is granted by zone. Zero trust assumes no implicit trust and authenticates every access decision. In OT, the two are complementary: Purdue provides the network architecture, zero trust principles inform how identity and access are managed within and between zones.

How ARG uses the Purdue Model in scoping OT audits

ARG uses the Purdue Model as the scoping vocabulary for OT audits at manufacturing clients. The model is not the deliverable; it is the framework the engagement runs against.

During the on-site audit, David Ashby maps the client's actual architecture against the Purdue reference. The map documents which assets sit at which level, where the documented boundaries are, and where the boundaries diverge from the diagram in practice.

The output is a Purdue-aligned architecture diagram of the client's environment as it actually exists, alongside the diagram as it was originally documented. The two diagrams almost always differ. The audit findings address each divergence: which gaps are operational necessities requiring compensating controls, which are accidental and can be closed, and which are accumulating risk that needs investment.

Findings consolidate into the engagement report with mapping to NIST CSF 2.0, IEC 62443 (where applicable), and CMMC (where the client is a defense-supplier subject to it). The remediation backlog uses Purdue vocabulary so the architecture team, the security team, and the engineering team all reference the same structure when prioritizing investment.

Re-engagement on a one- or two-year cadence retests the closed boundaries and updates the architecture map as the facility evolves.

Apply as a founding client or see how the engagement works for the full delivery cycle.