Purdue model: which conduits actually need a physical break

The Purdue Enterprise Reference Architecture organizes an industrial network into five levels. Level 0–1 is the physical process and the controllers operating it. Level 2 is the supervisory layer — HMIs and engineering workstations. Level 3 is the site operations / MES tier. Level 3.5 is the industrial DMZ. Levels 4 and 5 are the corporate IT and external network respectively.

The model is a vocabulary for talking about boundaries. The boundaries themselves are conduits — pieces of network that carry traffic between levels. In real deployments, those conduits are where most OT-targeted incidents propagate.

Not every conduit should be physical-break-by-default. The HMI tier (level 2) usually needs continuous reachability from the workstations at level 3 — operators are watching the process all day. Putting a relay on that conduit would mean every operator action waits on a window open.

The conduits that benefit are the ones where reachability is needed only during defined events. Vendor maintenance access to a controller (conduit between an external network and level 1). Backup writes from a MES server to an offline vault (conduit between level 3 and a separated storage tier). Patch deployment from the industrial DMZ to a controller (conduit between 3.5 and level 1 during scheduled patch windows). Each of these is a candidate for a default-closed physical break.

The model assumes auditors can determine which conduits were open and when. In practice, this is one of the hardest parts of an industrial audit — firewall logs are partial, segmentation rules drift, and 'documented as closed' often diverges from 'actually closed'.

A physical relay on the conduit changes the audit posture. The log is the device's own state machine — open command received at 03:11, window opened, window closed at 04:46. There is nothing to reconstruct. The relay state is the ground truth, and the operator's documentation is checked against the device log, not the other way around.

The Purdue model assumes a vertical hierarchy that modern industrial networks do not always fit. Edge computing pushes processing toward level 1; some control loops cross between sites over VPN; IIoT devices report into cloud platforms that sit somewhere between levels 4 and 'not in the model at all'. The conduit thinking still applies, but the levels themselves blur.

The conservative reading is: use the Purdue vocabulary to find conduits where traffic should be intermittent, and apply physical breaks there. Do not assume the model itself is a control — it is a way of naming where the controls go.