The Purdue Model for OT/ICS network architecture, explained

The model predates ICS cybersecurity as a field. Per Wikipedia's summary of the original work, the Purdue Enterprise Reference Architecture "is a 1990s reference model for enterprise architecture, developed by Theodore J. Williams and members of the Industry-Purdue University Consortium for Computer Integrated Manufacturing" — built to describe how a factory's business planning systems and shop-floor control systems should exchange data, not to define a security boundary. The International Society of Automation later formalized the same level hierarchy as part of its ANSI/ISA-95 enterprise-control integration standard, under the name "Purdue Reference Model '95," which is why practitioners sometimes call the whole thing "the ISA-95 model" interchangeably with "the Purdue Model." Only afterward did the ICS security community borrow this existing, already-familiar level vocabulary as a way to talk about network segmentation — CISA's 2016 ICS-CERT defense-in-depth guidance is one of the clearest early examples, listing the "SP-99 (Purdue) Model of Control" as a named element of its recommended secure network architecture.

ISA-95's own Purdue Reference Model '95 defines five layers:

The version most commonly drawn in OT cybersecurity material today — including CISA's and most vendor glossaries' diagrams — extends this by splitting the top layer into a Level 4 (site business/IT) and a Level 5 (enterprise network) for corporate-wide ERP, directory services and other business applications, and by inserting a Level 3.5 industrial DMZ between the OT side (Levels 0-3) and the IT side (Levels 4-5). That DMZ is where firewalls, jump hosts and data-replication servers live specifically so a corporate system never has to open a direct path into the control network — a well-configured DMZ means, per CISA's 2016 guidance, that "no direct communication paths are required from the corporate network to the control network" because each path "effectively ends in the DMZ."

A later addition, and this is the detail most short blog-post explainers get wrong. Williams' original 1990s work and ISA-95's formalization of it describe a data-flow hierarchy for manufacturing integration, with no security boundary anywhere in it — there was no Level 3.5 because there was nothing at that layer to defend against yet. The industrial DMZ is a security-community retrofit, introduced as ICS security practice matured and network segmentation became the primary tool for keeping a compromised corporate IT network from reaching production control systems directly. CISA's 2016 defense-in-depth recommended practice is a good anchor point for that retrofit: it explicitly frames the DMZ as a tool to reduce a specific risk — one interface facing the corporate network, one facing the control network, with firewall rules permitting only the narrow traffic a plant actually needs to cross. The residual risk CISA flags is just as important as the pattern itself: if an attacker compromises a DMZ host, the usual next move is to abuse whatever application traffic the firewall already permits from the DMZ into the control network, so DMZ servers need their own hardening, not just a position between two firewalls.

This matters practically because the Purdue level vocabulary and the IEC 62443 series' own zones and conduits vocabulary (see IEC 62443-1-1: concepts and models) describe overlapping but not identical things — Purdue levels are a specific, named hierarchy; zones and conduits are a more general grouping concept IEC 62443 lets an asset owner define for their own environment, and a site's zones don't have to line up one-to-one with Purdue levels, even though a Level 3.5 DMZ is usually drawn as its own zone in a 62443-style diagram.

Both bodies still use the level hierarchy as their working vocabulary for OT network architecture — it has not been withdrawn or formally replaced. NIST SP 800-82 Revision 3, "Guide to Operational Technology (OT) Security" (published September 2023), continues to frame network architecture and segmentation recommendations around Purdue-style levels and zones, and CISA's 2016 defense-in-depth practice remains listed among CISA's current ICS recommended practices rather than withdrawn. What has changed is the 2024-2026 industry conversation about the model's limits: secondary analysis — Claroty's June 2025 write-up is a representative example — argues that cloud analytics connections sending operational data off-site, third-party remote access for contractors and vendors, and centralized security-monitoring tools that pull data from multiple levels at once all create legitimate exceptions to a clean level-by-level boundary, and that those exceptions can "inadvertently create pathways that compromise the strict segmentation the Purdue Model advocates" if they aren't managed deliberately. The recommended response in that discussion is not to discard the Purdue levels but to add microsegmentation and context-aware access controls around individual assets or small groups of them, so that a single approved cloud or remote-access exception doesn't become a blanket hole through an entire level.

See NIST SP 800-82: OT Security for the broader security-control framework this architecture sits inside, CISA Secure by Demand for OT Products for how this plays into what asset owners should ask vendors for, and MITRE ATT&CK for ICS for how adversary behavior is mapped against exactly this kind of layered environment.