The Purdue Model and OT Architecture

Where the model comes from

The Purdue model is a layered reference model that places industrial systems on levels according to their function, from the physical process at the bottom to business planning at the top. It descends from the Purdue Enterprise Reference Architecture (PERA), developed by Theodore J. Williams and the Industry–Purdue University Consortium for computer-integrated manufacturing (CIM) and published as a book by the Instrument Society of America in 1992.

PERA was a model of how manufacturing functions and information fit together, not a security design. Security practitioners later borrowed its levels to describe where OT systems sit and which of them may talk to each other, and added a level that PERA does not have: level 3.5, the industrial DMZ. When people say "the Purdue model" today, they almost always mean this security-flavored version.

The levels

Level numbers rise with the distance from the physical process. Lower levels are faster, more critical and harder to change; higher levels look more like ordinary IT.

Some versions add a separate safety level for safety instrumented systems next to level 1, to stress that safety systems stay independent of basic control (see Safety and Reliability). The components on each level are explained on Industrial Control Systems.

The industrial DMZ

A DMZ in an office network holds the servers the internet may reach. The industrial DMZ (IDMZ, level 3.5) applies the same idea between IT and OT: a separate network segment between two firewalls (or two firewall interfaces) where every connection from IT and every connection from OT ends. Nothing passes through it in one hop. If the business network needs plant data, OT pushes the data into the DMZ and IT fetches it there; if a vendor needs to reach a controller, they land on a hardened host in the DMZ first.

Typical residents of the industrial DMZ:

• Historian replica: a copy of the site historian for reports and dashboards, so office users never query the real one.
• Patch and antivirus update servers: they download from IT or the internet; OT systems fetch approved updates from them.
• Jump host: the controlled entry point for remote and vendor access, with multi-factor authentication, session recording and access granted only when needed. A US joint guide, Adapting Zero Trust Principles to Operational Technology (CISA and partners, April 2026), strongly recommends "dedicated, hardened jump boxes within the OT demilitarized zone (DMZ) acting as the sole entry point for remote access". The general idea is on Remote Access and Privileged Access Management; OT specifics are on Remote Access and Third Parties.
• File transfer: a controlled place to exchange files such as recipes and reports, scanned for malware.

Zones and conduits

The ISA/IEC 62443 series describes network security in OT with two terms. A zone is a group of assets, physical or logical, that share the same security requirements: for example "the PLCs and HMIs of water treatment line 1", or "the substation's protection relays". A conduit is a communication path between zones, together with the security measures on it: the firewall rules, the allowed protocols, the monitoring. Assets inside a zone trust each other more than they trust anything outside; all traffic between zones must use a defined conduit.

Zones and conduits are worked out in ISA/IEC 62443-3-2 (security risk assessment for system design). The Purdue levels are a reasonable starting point for zones, but the standard does not require them: a zone can be a single safety system, a vendor package or one substation, depending on risk. Each zone gets a target security level, which is explained on IEC 62443. The network techniques behind zones are the ones from IT, segmentation, VLANs and firewalls, applied with OT priorities; see also segmentation and microsegmentation.

Engineering workstations

An engineering workstation (EWS) is the computer from which engineers program and configure controllers: it runs the vendor's engineering software, holds the project files (the source of every PLC program and every relay setting) and has network access to the devices. Whoever controls it can change what the plant does, not only what the screens show. That makes it one of the most valuable targets in OT, and several attacks on industrial systems worked by changing controller programs or project files. In April 2026, for example, a CISA advisory (AA26-097A) described Iranian-affiliated actors who reached internet-exposed PLCs, modified their project files and the data shown on HMI displays, and disabled shutdown and alarm logic.

Engineering workstations usually sit at level 3 (sometimes level 2), and they are protected like administrator workstations in IT:

• Used only for engineering: no email, no web browsing, no office work (compare privileged access workstations).
• Reached remotely only through the jump host, with multi-factor authentication.
• Application allowlisting, removable media controls and up-to-date backups of all project files, kept offline.
• Program downloads to controllers logged and compared with the approved versions; where controllers have a key switch, it stays in RUN outside planned work.

Communication rules between levels

The model translates into a few rules that most OT security designs share:

• No direct traffic between the enterprise (levels 4–5) and levels 1–2. An office PC never talks to a PLC or an HMI.
• Every IT/OT session ends in the DMZ. Inbound and outbound connections are separate sessions, ideally initiated from the more trusted side.
• Mostly adjacent levels only. Level 2 talks to level 1 and level 3; exceptions such as the engineering workstation programming level 1 devices are explicit and narrow.
• Deny by default. Every allowed flow has a source, a destination, a port and a reason; everything else is blocked and logged.
• Data flows up more easily than commands flow down. Some sites enforce one direction in hardware with a data diode (see Industrial Networks).

A firewall policy for the DMZ then looks like this. The syntax is generic, for illustration; real products differ.

# Level 4 (203.0.113.0/24) -> DMZ (198.51.100.0/24)
allow  tcp  203.0.113.20    -> 198.51.100.10  443    # reports read the historian replica
allow  tcp  203.0.113.0/24  -> 198.51.100.11  443    # remote-access portal on the jump host (MFA)
# DMZ -> level 3 (192.0.2.0/24)
allow  tcp  198.51.100.11   -> 192.0.2.31     3389   # jump host to engineering workstation
# Level 3 -> DMZ
allow  tcp  192.0.2.30      -> 198.51.100.10  443    # site historian pushes to the replica
allow  tcp  192.0.2.0/24    -> 198.51.100.12  8531   # OT hosts fetch approved updates
# Everything else
deny   ip   any             -> any                   log

Rules on paper are only half of it: you also have to check what actually crosses the network. The script below takes a list of observed flows (as passive monitoring might report them) and checks each against the allowed level-to-level pairs. Real tools also check ports and protocols; the idea is the same.

# Which Purdue level each known address lives on (from the asset inventory).
LEVEL = {
    "203.0.113.20": "4",     # reporting server, office network
    "198.51.100.10": "3.5",  # historian replica in the industrial DMZ
    "198.51.100.11": "3.5",  # jump host in the industrial DMZ
    "192.0.2.30": "3",       # site historian
    "192.0.2.31": "3",       # engineering workstation
    "192.0.2.50": "2",       # HMI / SCADA server
    "192.0.2.70": "1",       # PLC, pump station
}

# Level pairs that may talk (source, destination). Everything else is denied.
ALLOWED = {
    ("4", "3.5"), ("3.5", "3"), ("3", "3.5"),  # nothing goes straight from 4 to 3
    ("3", "2"), ("2", "3"),
    ("2", "1"), ("1", "2"),
    ("3", "1"),                                # engineering workstation programs PLCs
}

observed = [
    ("203.0.113.20", "198.51.100.10", 443),   # reports read the historian replica
    ("192.0.2.30", "198.51.100.10", 443),     # historian pushes to replica
    ("192.0.2.50", "192.0.2.70", 502),        # HMI polls PLC over Modbus
    ("203.0.113.20", "192.0.2.50", 3389),     # remote desktop straight to the HMI
    ("198.51.100.11", "192.0.2.31", 3389),    # jump host to engineering workstation
    ("192.0.2.70", "203.0.113.20", 443),      # PLC talks to the enterprise
    ("192.0.2.99", "192.0.2.70", 502),        # unknown device polls the PLC
]

counts = {"allowed": 0, "VIOLATION": 0, "UNKNOWN ASSET": 0}
for src, dst, port in observed:
    a, b = LEVEL.get(src), LEVEL.get(dst)
    if a is None or b is None:
        verdict = "UNKNOWN ASSET"
    elif (a, b) in ALLOWED:
        verdict = "allowed"
    else:
        verdict = "VIOLATION"
    counts[verdict] += 1
    print(f"L{a or '?':<3} -> L{b or '?':<3} {src:>13} -> {dst:<13} :{port:<5} {verdict}")
print(f"{len(observed)} flows: {counts['allowed']} allowed, "
      f"{counts['VIOLATION']} violations, {counts['UNKNOWN ASSET']} unknown")

L4   -> L3.5  203.0.113.20 -> 198.51.100.10 :443   allowed
L3   -> L3.5    192.0.2.30 -> 198.51.100.10 :443   allowed
L2   -> L1      192.0.2.50 -> 192.0.2.70    :502   allowed
L4   -> L2    203.0.113.20 -> 192.0.2.50    :3389  VIOLATION
L3.5 -> L3   198.51.100.11 -> 192.0.2.31    :3389  allowed
L1   -> L4      192.0.2.70 -> 203.0.113.20  :443   VIOLATION
L?   -> L1      192.0.2.99 -> 192.0.2.70    :502   UNKNOWN ASSET
7 flows: 4 allowed, 2 violations, 1 unknown

Each finding is a question to follow up, not an automatic incident. The remote-desktop session from level 4 to the HMI breaks the "no direct enterprise to level 2" rule: is a forgotten firewall rule allowing it? The PLC that talks to the enterprise may be a misconfigured vendor feature or something worse. And the unknown device shows why the asset inventory is the foundation of everything else: you can only judge a flow when you know what is on both ends.

Criticism and today's reality

The Purdue model is everywhere in OT security, and so is the criticism of it. PERA described manufacturing functions; it was never designed as a network security architecture, and practitioners keep repeating that it is a reference model, not a blueprint. Real networks rarely match it neatly:

• Flat networks. Many existing plants have one large network for levels 1 to 3, sometimes with the office network one firewall rule away. The levels exist on the drawing, not in the switches.
• Cloud and industrial IoT. Smart sensors and gateways send data straight from level 0 or 1 to a cloud platform, skipping every level in between. Vendors offer cloud-hosted monitoring and remote support. IEC PAS 62443-1-6:2025 addresses applying IEC 62443 to industrial IoT, and the draft Rev. 4 of NIST SP 800-82 (September 2026) adds IIoT and cloud convergence to its scope. See IT/OT Convergence.
• Wide-area systems. A grid operator's SCADA spans a control center and hundreds of substations connected by a telecom network; each substation has its own levels 0 to 2, and the "site" is a whole country.
• Zero trust. Instead of trusting everything inside a level, newer guidance asks for authentication and authorization per connection where the equipment allows it, while accepting that many controllers cannot do this.

The practical conclusion: use the Purdue levels as a shared vocabulary ("that is a level 2 system", "this flow crosses the DMZ") and as a starting point for zones, then design the actual zones and conduits from a risk assessment of your own systems, as IEC 62443 asks.