The Purdue model for OT firewall reviews

The Purdue model is the most common way to describe where things sit in an industrial network, from the sensors on the plant floor up to the corporate data center. It is a reference model, not a standard, and nothing in it is mandatory. What makes it useful in a firewall review is that it gives everyone the same words for “this traffic crossed too far”.

Where the Purdue model comes from

The model grew out of the Purdue Enterprise Reference Architecture, developed at Purdue University in the early 1990s by Theodore J. Williams and an industry consortium. Its level structure was carried into ISA-95 (published internationally as IEC 62264), the standard for integrating enterprise and control systems. NIST SP 800-82r3, the US guide to operational technology (OT) security, names the Purdue model and ISA-95 levels as industry-recognized ways to organize OT network segmentation (section 5.2.3.1).

The Purdue model levels

Level	Name	What usually lives there
L5	Enterprise	Internet, partners, remote access
L4	Business	Office users, email, ERP, corporate servers
L3.5	IDMZ	Jump hosts, historian replicas, patch and file brokers
L3	Operations	Historians, MES, OT domain controllers, engineering workstations
L2	Supervisory	HMIs, SCADA servers, alarm stations
L1	Basic control	PLCs, RTUs, DCS controllers
L0	Process	Sensors, actuators, drives, I/O networks

Level 3.5, the industrial DMZ, is not in the original model. Industry practice added it as the place where IT and OT meet, so that nothing passes directly between Level 4 and Level 3. The IDMZ guide covers what belongs there.

Real sites rarely map one zone to one level cleanly. A cell zone can hold both HMIs and PLCs, and a single historian might be reachable from two levels. The levels are a lens for reading traffic, not a rule that every network must be rebuilt to match.

Adjacent levels: what NIST SP 800-82r3 says

The model itself is descriptive. The firewall guidance comes from NIST SP 800-82r3, section 5.2.3.1:

• Firewall rulesets “should be established to only permit connections between adjacent levels, tiers, or zones.”
• Sites using a Purdue architecture “should implement firewall rules and connection paths that prevent Level 4 devices from directly communicating with Level 2, 1, or 0 devices.”
• Outbound rules from the control network deserve the same care: organizations “should consider making outbound rules as stringent as inbound rules.”

The same section notes that a DMZ can act as the enforcement boundary between segments, as its Fig. 16 shows. IEC 62443 does not require Purdue levels; it is built on zones and conduits (see the IEC 62443 guide). The two fit together: Purdue levels are a common way to draw the zones.

Paths a Purdue-based firewall review questions

Read the firewall rules and the traffic they carry against the levels, and a short list of patterns stands out. Each one is a path where the rules let traffic skip the boundaries the levels describe.

• IT straight into OT. Business traffic (L4) or enterprise traffic (L5) that reaches L3, L2 or L1 without stopping in the IDMZ.
• Internet or VPN reaching control. Remote sessions that land on an HMI or PLC network instead of a jump host.
• Skip-level conduits inside OT. An engineering workstation at L3 talking straight to PLCs at L1, with no supervisory boundary in between.
• OT calling out. An L2 or L1 device opening sessions to the internet or the business network.
• Remote and file-sharing tools onto L2 or L1. RDP, SMB, SSH, VNC and similar tools reaching supervisory or control networks.
• Rules that allow everything. An any-any rule makes every level reachable from every other, whatever the zone design says.

A rule that allows one of these paths is worth questioning even if no traffic used it this week. A rule that is carrying live traffic is the one to fix first.

How SegAudit reports Purdue findings

SegAudit places each zone on the Purdue level you confirm, from L0 to L5 with the L3.5 IDMZ, and reads the firewall rules and traffic log you collected against those levels. Paths that break the adjacent-level pattern become findings with the sessions, hosts and allowing rule behind them, and each one cites the IEC 62443-3-3 requirements and NIST SP 800-82r3 guidance it relates to. Findings are never phrased as the Purdue model “requiring” anything.

In the Northline sample (a made-up three-site company that ships with SegAudit), the engine reports findings such as:

• “IT L4 talking straight into L2 · 38 sessions” (critical)
• “Internet (L5) reaching L1 OT · 13 sessions” (critical)
• “Skip-level conduit L3 → L1 · 15 sessions” (high)
• “ssh from L3 onto L1 · 10 sessions” (high)
• “L2 OT initiating to the internet · 40 sessions” (critical)

The zone map shows the same picture as a level-by-level grid: every count in red is traffic between levels that are not adjacent.

Each finding comes with a proposed rule change and a rollback, and the change package groups them into change windows for the site’s own change process.

Common questions

Does the Purdue model require an IDMZ? No. The model describes levels; it does not require anything. NIST SP 800-82r3 suggests a DMZ as an enforcement boundary, and IEC 62443 asks for zone boundary protection. The IDMZ is the usual way sites meet both.

Is the Purdue model outdated? Cloud services, IIoT and remote support have blurred the levels, and NIST SP 800-82r3 shows a three-tier IIoT model next to Purdue in the same figure. The levels remain the common language for asking whether a path is too direct.

What if our zones do not match the levels? Confirm each zone’s level for the review. A zone that mixes levels is itself worth noting, since its internal traffic never crosses a firewall.