OT Network Segmentation for Defense: The Purdue Model with Classification Overlay

Operational-technology (OT) networks in defense systems — the control planes behind radars, propulsion plants, weapon-system test benches, magazine handling, ground-station antenna arrays — fail differently from enterprise IT. A ransomware event on a corporate file share is recoverable; a confused programmable logic controller on a propulsion plant during a contested transit is not. The first engineering question is therefore not "how do we patch faster" but "how is the network carved up, and what crosses each boundary." That is the segmentation question, and for fifty years the canonical answer has been the Purdue Enterprise Reference Architecture, layered over the zones-and-conduits language of IEC 62443. This article walks the model end-to-end, then overlays defense-specific concerns: classification, cross-domain transfer, monitoring of an allegedly air-gapped stack, and the accreditation paperwork that the architecture must ultimately satisfy.

1. Why Purdue Still Matters

Purdue was originally drafted for chemical and manufacturing process control, but its core insight — that a network can be decomposed into layers with strictly defined trust relationships between them — has outlived every generation of hardware it was applied to. A "flat OT" network where engineering workstations, historians, human-machine interfaces, and field controllers all share an unfiltered Layer-2 broadcast domain cannot be defended. There is no observable boundary at which an analyst can say "traffic crossing this point should be Modbus, nothing else"; every host trusts every other host implicitly; a single compromised laptop reaches every PLC by ARP.

IEC 62443 captures the same instinct in different vocabulary: a zone is a grouping of assets sharing common security requirements, and a conduit is the controlled path between zones. Conduits, not hosts, are where security controls are enforced. The Purdue levels are, in effect, a default zoning template — a starting point that defense programs adapt rather than reinvent. For the rest of this article we use Purdue level numbers and IEC 62443 zone/conduit terms interchangeably; in defense cybersecurity practice they describe the same artefact.

2. The Six Purdue Levels

Level 5 — Enterprise. Corporate IT: email, ERP, intranet, contractor access. On a defense site, this is the unclassified business LAN that auditors, payroll, and program managers live on. It must never directly touch process equipment.

Level 4 — Site Business Planning and Logistics. Maintenance management, spares inventory, work-order systems. For a naval combat system this is the shore-side logistics tail; for an air defense battery, the depot-level support system. Still IT-like, still patched on an IT cadence.

Level 3.5 — Industrial DMZ. The single most important zone in the model. Every flow between enterprise IT and operations passes through here, terminated and re-originated by brokered services: historian replicas, jump hosts, patch staging, anti-malware update mirrors. No native protocol crosses the DMZ; nothing on Level 3 establishes a session with anything on Level 4 or above except via a DMZ proxy.

Level 3 — Site Operations. Production-wide systems: the operational historian, batch-management servers, plant-wide engineering applications, OT domain controllers, OT patch servers. On a weapon-system test bench this is the range control room — the place where test conductors orchestrate runs across multiple cells.

Level 2 — Supervisory Control. HMIs, local engineering workstations, alarm servers, line-of-sight SCADA. For a propulsion plant this is the machinery control console; for a radar, the operator's tactical display server. Humans steer the process from Level 2.

Level 1 — Basic Control. PLCs, RTUs, safety instrumented systems, dedicated controllers. The logic that holds steam pressure, slews an antenna, sequences a launcher, or trips a reactor. Real-time, deterministic, often unable to tolerate even a millisecond of jitter introduced by a misconfigured firewall.

Level 0 — Process. Sensors and actuators, valves, motors, transducers, the physics of the system. Increasingly digital (HART, IO-Link, Profibus-PA, FOUNDATION Fieldbus) and therefore increasingly part of the cybersecurity scope.

The crucial property is that the deeper you go, the more deterministic, the less patched, and the less able the equipment is to defend itself. A Level-1 controller built in 2009 has no authentication on its engineering protocol. The whole point of segmentation is to compensate for that with boundary controls.

3. Classification Overlay on Purdue Zones

Defense adds a second axis Purdue did not anticipate: classification. A NATO RESTRICTED logistics view of a maintenance backlog and a SECRET tactical view of the same platform may live at the same Purdue level but cannot share a broadcast domain. The result is a matrix: Purdue level on one axis, classification on the other.

In practice the matrix collapses to a small number of accredited combinations. Level 5 enterprise is typically UNCLASSIFIED or NATO RESTRICTED. The Industrial DMZ may exist at multiple classifications, one per enclave. Levels 3 through 0 — the actual process control — are usually pinned to the highest classification of any data they handle, on the principle that the controller cannot strip classification from its own state. A radar's Level-1 controller running a classified waveform sits in a SECRET enclave even though the controller itself is a commodity PLC.

The architecturally honest move is to draw the matrix early, label each cell with its accreditation owner and its allowable conduits, and refuse to deploy anything that does not fit a labelled cell. This is also where zero-trust principles meet classical defense-in-depth: identity-aware policy inside a zone, hardware-enforced separation between classifications.

4. Cross-Domain Solutions in OT

Once the matrix exists, the question becomes how data moves between cells. Two categories of cross-domain solution dominate OT deployments.

One-way data diodes. Hardware devices (Owl, Waterfall, Fox-IT FoxDataDiode, Advenica) that physically permit traffic in one direction only — typically a fibre-optic transmitter on one side and a receiver on the other, with no return path possible at the physical layer. The classic OT use case is exporting historian data from Level 3 to a Level-4 or enterprise replica without exposing the OT side to any return traffic. Diodes are the right answer when the data flow is monotonic: telemetry out, nothing in. They are the wrong answer for anything that needs acknowledgment, patches in, or remote vendor support.

Transfer guards. Application-aware gateways (Forcepoint DDP, Fox-IT DataDiode in guard mode, Everfox Trusted Gateway, Owl ReCon) that inspect and filter content crossing a classification boundary in either direction. A guard can release a sanitised maintenance work order from SECRET to RESTRICTED after verifying it carries no classified annotations, or pull a vetted PLC firmware update from a lower enclave into a higher one. Guards are slower, more expensive, and harder to accredit than diodes, but they are the only honest answer when bidirectional flow is genuinely required.

The engineering rule is to start with a diode and only escalate to a guard when the operational use case proves bidirectional flow is unavoidable.

5. East-West vs North-South Segmentation

Purdue is primarily a north-south model: traffic moves up and down the levels and is filtered at each conduit. But modern attacks are east-west — once an adversary is on a Level-2 HMI, the next move is sideways to the neighbouring HMI, not upward to the historian. East-west segmentation inside a Purdue level is therefore the second front.

Micro-segmentation in OT is harder than in IT for three reasons. First, many legacy protocols (Modbus/TCP, DNP3, IEC 60870-5-104, S7) carry no authentication and assume a flat L2 domain. Second, controllers cannot run host-based firewalls without violating their real-time guarantees and frequently their vendor warranty. Third, deterministic timing budgets mean a misconfigured policy enforcement point can take the plant down faster than the attacker would have.

The two practical approaches are VLAN-plus-ACL designs on managed industrial switches (Hirschmann, Cisco IE, Moxa) and SDN overlays purpose-built for OT (TXOne, Claroty xDome Secure Access, Dragos with NAC integrations). VLANs are familiar and accreditable but coarse; SDN is finer-grained but introduces a controller whose own availability becomes a single point of failure. Most real programmes end up running both, with VLANs as the baseline and SDN policies layered on top for high-value cells.

6. Monitoring an Air-Gapped Stack

Every OT programme claims to be air-gapped. Almost none actually is. There is a USB port on the engineering laptop, a vendor laptop that comes in once a quarter, a maintenance modem that was decommissioned on paper but still has a SIM card, a wireless instrument that was added during a refit. The architecture must assume the air gap is leaky and instrument accordingly.

Passive monitoring platforms — Nozomi Networks Guardian, Claroty CTD/xDome, Dragos Platform, Tenable OT Security — sit on span ports inside each zone and reconstruct asset inventories, protocol baselines, and anomaly signals from passively observed traffic. They never inject packets, which is what makes them deployable on production OT without vendor pushback. Combined with historian-based detection (queries against the historian for impossible setpoint changes, command rates above human capability, sequences that violate process interlocks) and engineering-workstation EDR, they form a defensible monitoring stack even when the network is nominally isolated. This is the lineage explored in our ICS/OT forensics walkthrough.

7. Identity and Access in OT

Identity in OT is dominated by three populations: engineering workstations used by site staff, vendor remote-access sessions, and break-glass accounts held for casualty control. Each requires its own discipline.

Engineering workstations should authenticate to an OT-side directory — never the enterprise IT directory — with hardware-rooted credentials and session recording. Sharing the corporate Active Directory across the Industrial DMZ is the single most common architectural mistake in defense OT; it converts an enterprise credential compromise into an OT compromise. Pair this with hardware roots of trust on the workstations themselves to bind the credential to the device.

Vendor remote access is the perpetual risk. The right pattern is a jump host in the Industrial DMZ, brokered access with full session recording, time-boxed authorisations, and an operator-in-the-loop "screen-share" model rather than autonomous vendor connectivity. The wrong pattern — still common — is a permanent site-to-site VPN from the vendor's office into Level 3.

Break-glass procedures must exist because OT priorities sometimes invert the cyber priorities: in a casualty, a watchstander needs to override a controller now, not after a token rotation. Document the break-glass credentials, store them physically, log every use, and treat each use as an incident requiring post-event review.

8. Accreditation Evidence

None of the above matters unless the segmentation survives accreditation. An Authority to Operate (ATO) package for a defense OT segment typically contains: the zone-and-conduit diagram with classification labels; the IEC 62443 Security Level Target (SL-T) determination per zone, justified against the threat model; conduit-by-conduit control mappings (what filters, what protocols, what logging); evidence of cross-domain solution accreditation (NCDSMO baseline for US, national equivalents in NATO members); residual-risk statements for any control gap; and an operational continuous-monitoring plan describing how the SL-T will be re-evidenced over time.

SL-T determination is where engineering meets paperwork. IEC 62443-3-2 defines four security levels (SL 1 through SL 4) representing the capability of the adversary the zone must resist — from casual to nation-state with extensive resources. A radar control segment on a forward-deployed platform is typically SL 3 or SL 4. The chosen SL drives every downstream control requirement in IEC 62443-3-3, from password policy to cryptographic algorithm choice. Pick the SL too low and the accreditor rejects the package; pick it too high and you cannot afford to build it.

Finally, re-accreditation is a recurring cadence, not a one-shot event. Most defense regimes require a full re-evaluation every three years and a delta review on any "significant change" — which, in OT, includes the next vendor firmware update. Architect the segmentation so that the evidence regenerates itself: configuration captured in version control, monitoring outputs archived as accreditation artefacts, change records linked to risk re-assessments. The segmentation you cannot re-prove is the segmentation you no longer have.