Purdue Model OT Segmentation in 2026: A Step-by-Step Guide to Zones, the Industrial DMZ and Zero Trust

Every few months someone declares the Purdue model dead because a sensor now talks to a cloud broker. Then an incident report lands showing an attacker who walked from a phished office laptop to an engineering workstation over a flat network, and the old layered diagram suddenly looks prescient. Getting purdue model ot segmentation right in 2026 is not about defending a 1990s reference model. It is about using it as a map of data flows, then enforcing those flows with IEC 62443 zones and conduits and adding zero trust only where devices can carry it.

This matters now because NIST released the initial public draft of SP 800-82 Revision 4 in September 2026, with explicit zero trust and IIoT/cloud guidance, while plants keep adding edge gateways that punch through the old layers. You will leave with a ten-step procedure, a concrete industrial DMZ design, a firewall flow matrix, a remote access pattern and a worked example plant.

What this covers: what the Purdue levels really mean, mapping to IEC 62443 zones and conduits, asset inventory, firewall rule design, data diodes, jump hosts, IIoT and MQTT connectivity, zero trust placement, monitoring, a worked plant and failure modes.

Context and Background

The Purdue model descends from the Purdue Enterprise Reference Architecture (PERA), developed at Purdue University in the early 1990s by Theodore J. Williams and an industry consortium. Its hierarchy of functional levels was later absorbed into ISA-95, the enterprise-control integration standard, which is why MES sits at Level 3 and ERP at Level 4 in almost every plant drawing you will see. Our ISA-95 and ISA-99 technical guide covers that lineage in depth.

The original model was about functions and information, not firewalls. Security practitioners later bolted on “Level 3.5”, the industrial demilitarized zone (IDMZ), as a buffer where IT and OT exchange data without either side opening a direct session into the other. That addition became the de facto pattern for OT network segmentation through the 2000s and 2010s, reinforced by vendor reference designs and regulatory regimes. If you work in electric utilities, our analysis of how NERC CIP maps to IEC 62443 shows how electronic security perimeters inherit the same logic.

Three forces now strain the model. First, IIoT and cloud analytics want plant data at Level 5 in seconds, often through MQTT brokers or vendor agents that initiate connections from inside Level 2 or 3. Second, remote access exploded after 2020, and every OEM wants a path to its machines. Third, zero trust became the default security vocabulary in IT, with NIST SP 800-207 defining the architecture in terms of policy decision and enforcement points rather than network location.

Standards have moved accordingly. IEC 62443-3-2:2020 formalises how to partition a system under consideration (SUC) into zones and conduits and assign target security levels. NIST SP 800-82 Revision 3, published in September 2023, broadened scope from ICS to OT generally and added OT overlays on SP 800-53 controls. The Revision 4 initial public draft, released on 21 September 2026 with comments open until 30 November 2026, restructures the guide around CSF 2.0, adds IIoT and cloud convergence, and focuses its architecture guidance on protecting system management functions and applying zero trust principles. The ISA Global Cybersecurity Alliance’s 2024 paper on zero trust outcomes with 62443 makes a similar case: zero trust is applied by context, and the IDMZ perimeter is the first protect surface.

The useful conclusion is not “Purdue versus zero trust.” It is that Purdue tells you where data should flow, 62443 tells you how to group and protect assets, and zero trust tells you how to authorise each session where the technology allows it.

The Purdue Model OT Segmentation Reference Architecture

Purdue model OT segmentation means grouping plant assets by function into levels 0 to 5, placing an industrial DMZ at Level 3.5 so no session crosses directly between enterprise and control networks, and enforcing every permitted flow as an IEC 62443 conduit with a documented owner, protocol and direction. Zero trust then hardens sessions at Level 3 and above.

Figure 1: Purdue levels 0 to 5 with a Level 3.5 industrial DMZ, a separate safety zone, and the conduits C1 to C5 that carry every permitted flow.

Figure 1 shows the target state. Enterprise systems at Levels 4 and 5 never open sessions directly to Level 3. Instead, both sides terminate connections in the DMZ, where brokers, replicas and jump hosts mediate exchange. Below Level 3, conduits narrow further: supervisory systems at Level 2 talk to controllers at Level 1, and the safety instrumented system (SIS) sits in its own zone with at most a read-only conduit for diagnostics.

Treat the levels as a data-flow contract, not a wiring diagram

The most common misreading of the Purdue model is to treat each level as a VLAN. A plant with six VLANs named L0 to L5 and an any-any rule between adjacent VLANs is not segmented; it is labelled. The levels describe which functions exist and which should talk to which. The enforcement unit is the zone, and the permission unit is the conduit.

This framing matters because modern assets do not respect levels. An edge gateway may poll PLCs like a Level 2 system, buffer data like a Level 3 historian and publish to the cloud like a Level 4 integration. Forcing it into one level produces either an over-permissive rule or a broken integration. Mapping it as a member of a specific zone with explicit conduits to each peer resolves the ambiguity.

The industrial DMZ breaks sessions; it does not just add a firewall

The defining rule of an industrial DMZ is that no protocol session traverses it end to end. Traffic from the enterprise terminates on a DMZ host, and a separate session, often a different protocol, continues into the plant. A historian replica is the canonical example: the plant historian pushes to a DMZ replica, and business users query the replica. Nobody in the office ever opens a socket to Level 3.

Two firewalls, or one firewall with three legs and strictly separate rule sets, bound the DMZ. Many designs use different vendors for the IT-facing and OT-facing firewalls to avoid a single vulnerability defeating both, though that doubles the operational skill required. Either way, the DMZ should hold no assets the plant needs to keep running. If the DMZ is lost, production continues; only data export and remote access stop.

Purdue levels map onto IEC 62443 zones and conduits

IEC 62443-3-2 gives the partitioning method the Purdue model lacks. A zone is a group of assets sharing the same security requirements; a conduit is a logical grouping of communication channels connecting zones that share the same requirements. Each zone and conduit receives a target security level (SL-T) from SL 1, protection against casual or coincidental violation, to SL 4, protection against intentional violation by attackers with extended resources and IACS-specific skills.

The standard’s partitioning requirement (ZCR 3) is explicit about separations that Purdue only implies. ZCR 3.2 separates business and IACS assets, ZCR 3.3 separates safety-related assets, ZCR 3.4 separates temporarily connected devices, ZCR 3.5 separates wireless devices, and ZCR 3.6 separates devices connected via external networks. Those last three are exactly where IIoT and remote access break naive Purdue designs.

Purdue level	Typical assets	Typical 62443 zone	Illustrative SL-T	Primary enforcement
5 and 4	ERP, email, BI, cloud tenants	Enterprise zone, out of SUC scope	n/a	IT controls
3.5	Brokers, replicas, jump hosts, patch staging	IDMZ zone	SL 2 to SL 3	Dual firewalls, hardened hosts
3	MES, historian, engineering workstations, domain for OT	Site operations zone	SL 2 to SL 3	Firewall, host controls, zero trust sessions
2	HMI, SCADA servers, alarm servers	Area or cell zones	SL 2	Zone firewall, allowlisting
1	PLCs, RTUs, drives controllers	Cell zones, often merged with Level 2	SL 2	Conduit filtering, protocol inspection
SIS	Safety controllers, safety HMIs	Dedicated safety zone	SL 3 or higher	Physical separation or one-way conduit
0	Sensors, actuators, IO	Inside cell zone	n/a	Physical security

The SL-T column is illustrative. Your actual targets come from the risk assessment, not a lookup table, and a pharmaceutical batch line will rate differently from a warehouse conveyor.

How to Apply the Purdue Model: A Ten-Step Procedure

The procedure below follows the IEC 62443-3-2 workflow but keeps the Purdue levels as the organising map. Steps one to four are analysis; five to ten are build and operate. Skipping analysis is the most expensive mistake in OT network segmentation, because every rule written without a flow inventory becomes either an outage or a hole.

Define the system under consideration and build an asset inventory.
Assign each asset a Purdue level and a functional role.
Run an initial risk assessment and draw candidate zones.
Capture real traffic and build a conduit flow matrix.
Design the industrial DMZ with brokered services.
Write firewall rules from the flow matrix, default deny.
Use data diodes where one-way flow is enough.
Route all remote access through DMZ jump hosts.
Connect IIoT and cloud through outbound-only brokers.
Layer zero trust and continuous monitoring on top.

Step 1: Define the system under consideration and inventory assets

IEC 62443-3-2 begins with ZCR 1, identifying the SUC, including its perimeter and access points. In practice that means drawing a boundary around a site, a line or a process unit and listing every place a packet or a person can enter: WAN links, cellular modems on skids, USB ports, vendor laptops and wireless access points.

The inventory then lists each asset with its make, model, firmware, IP and MAC addresses, protocols spoken, owner and criticality. CISA, NSA and international partners published joint guidance in August 2025, “Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators,” that recommends a taxonomy by sector and attributes such as communication protocols and criticality. Use it as a field checklist.

Combine three sources. Passive monitoring on SPAN ports or taps sees what talks; engineering project files from the PLC and DCS tools describe what should exist; and a physical walk-down finds the modem taped inside a cabinet. Active scanning has a place, but only with vendor-approved tools and rates, because some older controllers crash on malformed or high-rate probes.

Step 2: Assign Purdue levels and functional roles

Tag each asset with a level and a role, such as “Level 2, packaging line HMI” or “Level 3, site historian.” Where an asset spans roles, record all of them. This tagging is the input for zone design and makes later rule reviews legible to operations staff, who think in lines and units rather than subnets.

Watch for dual-homed machines. An engineering workstation with one NIC on the office network and one on the control network is a bridge that bypasses every firewall you will build. Inventory work at most brownfield sites turns up several. Each must be resolved by moving it fully into one zone, usually Level 3, and giving it controlled access to the other side.

Step 3: Initial risk assessment and candidate zones

ZCR 2 calls for an initial cyber security risk assessment, essentially worst-case consequence assuming compromise. ZCR 3 then partitions the SUC into zones and conduits. Start from the Purdue levels but split further by consequence and by the 62443 separation rules: safety systems apart, wireless apart, temporarily connected devices apart, externally connected devices apart.

A useful heuristic is “one zone per thing you would isolate during an incident.” If ransomware hits packaging line 2, can you cut it off without stopping line 1? If not, line 1 and line 2 belong in separate cell zones. That operational test converts abstract risk language into concrete boundaries operators accept.

ZCR 4 compares initial risk to tolerable risk; ZCR 5 runs the detailed assessment for zones that exceed it, ending with an SL-T per zone and conduit. ZCR 6 documents the cybersecurity requirements specification, including zone and conduit drawings and characteristics, and ZCR 7 requires asset owner approval. Treat that approval as a real gate. Segmentation without an accountable owner decays within a year.

Step 4: Capture traffic and build the conduit flow matrix

Run passive capture for at least one full production cycle, ideally including a shift change, a batch changeover and a maintenance window. Many flows happen weekly or monthly: license checks, backup jobs, time synchronisation fallbacks, recipe downloads. A two-day capture will miss them, and the first time they fail will be during a startup.

Aggregate the capture into a flow matrix: source zone, destination zone, protocol, port, direction, initiator, frequency and business justification. Then challenge every row. Typical findings include office users browsing HMI web servers, PLCs reaching DNS servers on the corporate domain, and historian clients on laptops polling Level 2 directly. Each row you delete is one fewer rule to maintain.

The matrix also becomes a machine-readable contract. The snippet below shows a minimal format and a check that flags any flow that skips the DMZ, the single most important invariant in Purdue model OT segmentation.

# flows.py - validate a conduit flow matrix against Purdue invariants
LEVEL = {"ENT": 4.0, "IDMZ": 3.5, "OPS": 3.0, "AREA": 2.0, "CELL": 1.0, "SIS": 1.0}

flows = [
    # src, dst, proto, port, initiator, justification
    ("OPS",  "IDMZ", "tcp", 443,  "OPS",  "historian push to replica"),
    ("ENT",  "IDMZ", "tcp", 443,  "ENT",  "BI reads replica"),
    ("IDMZ", "OPS",  "tcp", 3389, "IDMZ", "jump host to EWS"),
    ("AREA", "CELL", "tcp", 44818,"AREA", "HMI to PLC EtherNet/IP"),
    ("ENT",  "OPS",  "tcp", 1433, "ENT",  "legacy report query"),   # violation
]

def violations(flows):
    for src, dst, proto, port, init, why in flows:
        crosses = {LEVEL[src], LEVEL[dst]}
        if max(crosses) >= 4.0 and min(crosses) <= 3.0:
            yield f"DMZ bypass: {src}->{dst} {proto}/{port} ({why})"
        if "SIS" in (src, dst) and init != "SIS" and dst == "SIS":
            yield f"Inbound to safety zone: {src}->{dst} {proto}/{port}"

for v in violations(flows):
    print(v)

Store the matrix in version control next to firewall configuration. When someone requests a new flow, they edit the matrix in a pull request, the check runs, and the owner of each zone approves. That turns the conduit concept from a drawing into a change-controlled artifact.

Step 5: Design the industrial DMZ

Figure 2: A brokered industrial DMZ. Plant systems push or pull through the OT-facing firewall; enterprise systems reach only DMZ services through the IT-facing firewall.

Figure 2 shows the four services nearly every IDMZ needs. A historian replica serves enterprise reporting. A patch and antivirus staging area lets OT servers pull updates from the DMZ rather than from the internet. A remote access gateway and jump host mediate interactive sessions. A broker, MQTT or OPC UA, mediates telemetry for IIoT and cloud consumers.

Every arrow follows one rule: the more trusted side initiates. The plant historian pushes outward; the OT patch server pulls from staging; the edge gateway publishes outward to the broker. The only inbound path into Level 3 is the jump host session, which is the most tightly controlled flow in the plant.

Keep DMZ hosts out of both the enterprise and plant Active Directory domains, or use a dedicated DMZ domain with no trust relationships. Shared domain trust is one of the most common ways attackers convert a DMZ foothold into control-network credentials. Similarly, do not let DMZ servers reach the internet directly except for specific update endpoints through a proxy.

Size the DMZ for failure. Because production must survive its loss, no plant function should depend on a DMZ service being reachable. Historians and edge gateways must buffer locally while the DMZ is down. A useful sizing target is 72 hours of local buffering, which covers a weekend outage; check the actual capacity of your historian’s store-and-forward feature rather than assuming it.

Step 6: Write firewall rules from the flow matrix

Firewall rules are a compilation target for the flow matrix, not a place to design. Start every zone boundary at default deny in both directions, then emit one rule per approved row, scoped to specific source and destination hosts, a single protocol and port, and the initiating direction. Avoid object groups like “all OT servers” on the source side; they silently grow.

Industrial protocols need more than port filtering. Modbus TCP on port 502, EtherNet/IP on TCP 44818 and UDP 2222, Siemens S7 on TCP 102, DNP3 on TCP 20000 and OPC UA on TCP 4840 all carry commands that can write setpoints or download logic. A next-generation or industrial firewall with deep packet inspection can allow Modbus function code 3 (read holding registers) while blocking function code 16 (write multiple registers), or permit S7 reads but block program downloads outside a maintenance window.

Conduit	Source	Destination	Protocol and port	Initiator	Inspection
C1	BI servers	DMZ historian replica	HTTPS 443	Enterprise	TLS, user auth
C2a	Plant historian	DMZ historian replica	Vendor replication over TCP	Plant	Allow push only
C2b	DMZ jump host	Engineering workstations	RDP 3389	DMZ	Session-bound, time-limited
C2c	Edge gateway	DMZ broker	MQTT over TLS 8883	Plant	Client certificate
C3	Historian collectors	Area HMIs and SCADA	OPC UA 4840	Level 3	Read-only where supported
C4	HMIs	Cell PLCs	EtherNet/IP 44818	Level 2	DPI, write allowlist
C5	SIS diagnostics	Safety zone	Vendor protocol	SIS side	One-way or read-only

Rules also need lifecycle. Tag each with the flow matrix row ID, an owner and a review date. A rule with no matching row in the matrix is a finding. Most mature OT programmes run a quarterly diff between firewall exports and the matrix and treat drift as an incident.

Two operational details catch teams out. Time synchronisation must be designed: if Level 1 relies on a Level 3 NTP or PTP source, that is a conduit, and losing it has consequences for sequence-of-events records. And name resolution must stay local; PLCs and HMIs should never depend on corporate DNS. Our deep dive on DNP3 Secure Authentication and unsolicited responses shows why protocol-level authentication complements, rather than replaces, these boundary controls in utility SCADA.

Step 7: Use data diodes where one-way flow is enough

A data diode, or unidirectional gateway, enforces one-way transfer in hardware, typically with a fibre link that has a transmitter on one side and only a receiver on the other. Because there is no physical return path, no software misconfiguration can open an inbound channel. That property is why diodes are common in nuclear, high-consequence chemical and some utility deployments.

The trade-off is that TCP needs acknowledgements, so diodes run proxy software on each side that terminates TCP locally and replays data over the one-way link. Historian replication, syslog forwarding, file transfer and some OPC UA or MQTT feeds work well this way. Anything interactive does not: no remote desktop, no patch pull, no bidirectional application protocol.

Use the diode where the business requirement is genuinely read-only telemetry out of the plant. Pair it with a separate, normally disabled path for remote access and patching that requires physical or procedural activation. Do not let a diode become a reason to skip the DMZ; the diode feeds a DMZ replica just as a firewall would.

Step 8: Route all remote access through DMZ jump hosts

Figure 3: Vendor remote access through a DMZ gateway, with control-room approval, a recorded jump host session and automatic revocation.

Remote access is where most OT compromises begin, so it deserves the strictest pattern. Figure 3 shows the flow. The vendor authenticates to a DMZ gateway with multi-factor authentication and device posture checks. A control-room approver grants a time-boxed session to one named asset. The gateway opens a recorded session on a jump host, which reaches the target through a single firewall rule that exists only for the session.

The pattern enforces four properties. Nobody connects from the internet directly into Level 3. Every session has a human approver who knows what the plant is doing right now. Every session is recorded, which gives forensic evidence and a deterrent. And access disappears automatically when the window closes, so forgotten VPN accounts cannot accumulate.

File transfer is the usual weak point. Vendors need to move firmware, logic and backups. Route files through a DMZ transfer service that scans them and holds them for the approver, rather than enabling clipboard and drive mapping on the jump host. Disable outbound internet access from the jump host so it cannot become a general-purpose pivot.

Finally, hunt for shadow paths. Cellular routers on OEM skids, TeamViewer-style agents on HMIs and modems on legacy RTUs bypass every control above. Your passive monitoring should alert on any outbound connection from Levels 1 to 3 to an internet address, and your inventory should list every cellular device by IMEI.

Step 9: Connect IIoT and cloud without breaking the model

Figure 4: IIoT connectivity that preserves Purdue model OT segmentation. Edge gateways read from controllers, publish outbound to a DMZ broker, and administrative sessions pass through a zero trust enforcement point.

IIoT is the force most often blamed for “breaking Purdue.” In practice it breaks only designs that let cloud services reach into the plant. The pattern in Figure 4 keeps every connection outbound. An edge gateway at Level 3, or in its own edge zone, polls PLCs read-only over OPC UA, Modbus or vendor drivers. It then publishes over MQTT with TLS, conventionally port 8883, to a broker in the DMZ, and the DMZ broker bridges outbound to the cloud.

MQTT suits this well because clients initiate connections and brokers never dial into clients. Sparkplug B adds state management and birth and death certificates, so consumers learn when an edge node drops. Our guide to MQTT store-and-forward edge gateways covers buffering when the DMZ or cloud link is down, and our unified namespace architecture piece explains why a single broker hierarchy should not become a single flat trust domain.

Three rules keep IIoT inside the model. Commands from the cloud never flow down by default; if a use case needs write-back, such as setpoint optimisation, it goes through a separately approved conduit with a local Level 2 or 3 application that validates and rate-limits writes. Wireless IIoT sensors get their own zone, per ZCR 3.5, connected to the edge through a conduit rather than bridged onto the control VLAN. And vendor cloud agents that insist on running on HMIs or PLC engineering stations are treated as externally connected devices under ZCR 3.6, which usually means moving them onto a dedicated edge host.

Modular plants raise the same questions in a different form. Process modules described by Module Type Package and orchestrated over OPC UA arrive with their own controllers and network. Our explainer on MTP and VDI 2658 process orchestration shows why each module is naturally a 62443 zone, with the process orchestration layer reaching it through a single OPC UA conduit.

Step 10: Layer zero trust and continuous monitoring

Zero trust, in the NIST SP 800-207 sense, means no implicit trust based on network location; every session is authenticated and authorised by a policy decision point and enforced by a policy enforcement point, using identity, device posture and context. Purdue model zero trust is not a replacement for zones. It is a session-level control that works where endpoints can carry identity, which in most plants means Level 3, the DMZ and remote access.

That placement matches current guidance. The ISAGCA paper notes that systems at Level 3 and above can generally support local access controls and network policies implementing zero trust principles, while Level 0 devices are only partly suited. Reporting on the SP 800-82r4 draft describes the same line: zero trust for compatible systems at Level 3 and above including the OT DMZ, Levels 1 and 2 treated as zone boundaries, and Level 0 out of scope, because many PLCs, controllers and HMIs cannot support the required technologies. I could not verify that exact wording in the draft PDF itself, so treat it as reported rather than quoted.

Monitoring closes the loop. Passive network detection on SPAN or tap feeds at each zone boundary and inside critical cells baselines normal industrial traffic and alerts on new talkers, new function codes and logic downloads. Our post on MITRE ATT&CK for ICS and Zeek-based passive monitoring covers detection engineering for that layer. Feed firewall denies into the same pipeline: a burst of denied flows is often the first sign of either an attacker or an undocumented dependency.

Where Purdue Model Zero Trust Fits, Level by Level

Zero trust is often sold as a way to flatten the network and drop zones. In OT that is backwards. Zero trust controls depend on endpoints that can authenticate, carry certificates, run agents or sit behind an identity-aware proxy. Most PLCs cannot. The practical design keeps zones as the hard boundary and adds zero trust inside and above them where the technology fits.

Location	Zero trust fit	What to deploy	What not to do
Remote access	Strong	Identity-aware gateway, MFA, posture, per-session approval, recording	Standing VPN into Level 3
Industrial DMZ	Strong	Per-service authentication, mutual TLS, microsegmentation between DMZ hosts	One flat DMZ VLAN for all services
Level 3 servers and EWS	Good	Host firewalls, application allowlisting, privileged access management, short-lived credentials	Agents that need cloud reachability to enforce policy
Level 2 HMI and SCADA	Partial	Zone firewall, OPC UA user authentication and certificates where supported, allowlisting	Inline agents that can stall operator screens
Level 1 controllers	Weak	Conduit DPI, write allowlists, CIP Security or OPC UA security if supported, key switches	Assuming device identity when protocols lack it
Level 0 and safety	Minimal	Physical security, separate safety zone, one-way diagnostics	Any inline control that could fail closed on a safety function

The ISAGCA paper’s warning is worth repeating: controls should not be added if their failure could cause loss of view, loss of control or lost production. An identity provider outage that locks operators out of HMIs is a safety event. Design every zero trust control in OT to fail open for operator view and control, or provide break-glass local accounts held under physical control.

Protocol support is improving, slowly. OPC UA has long offered application instance certificates, signed and encrypted messages and user authentication; our guide to OPC UA certificates, security policies and GDS trust lists covers the mechanics. EtherNet/IP has CIP Security, and newer controllers from several vendors support it. But installed bases turn over on 15- to 25-year cycles, so plan for a mixed estate for at least the next decade.

Worked Example: Segmenting a Mid-Size Food Plant

The following example is illustrative. The plant, numbers and rule counts are representative of brownfield sites I have seen discussed, not measurements from a named facility.

The site runs two packaging lines and one batch process unit. Inventory finds 240 networked assets: 38 PLCs, 22 HMIs, 6 SCADA and historian servers, 9 engineering workstations, 41 drives, 70 IO-Link masters and smart sensors, 18 wireless temperature sensors, 14 cameras and printers, and 22 miscellaneous devices including three cellular routers nobody listed.

Before the project, the plant ran one control VLAN with a single firewall to the office network carrying 140 rules, 11 of them any-to-any for “vendor support.” Two engineering workstations were dual-homed.

After applying the procedure, the design has nine zones: enterprise (out of scope), IDMZ, site operations, packaging line 1, packaging line 2, batch unit, safety, wireless sensors and edge. Thirteen conduits connect them. The flow matrix has 46 approved rows after four weeks of capture and two rounds of review, down from roughly 300 distinct observed flows; the rest were unnecessary, such as HMIs resolving corporate DNS and office laptops querying the historian directly.

Telemetry sizing for the edge and DMZ follows from the historian. Suppose 25,000 tags after deadband compression average one change every ten seconds, or 2,500 values per second. At an assumed 30 bytes per value on the wire, that is 75 kB/s, about 0.6 Mbit/s, trivial for any link. Local buffering for 72 hours needs 75 kB/s times 259,200 seconds, roughly 19.4 GB, so the edge gateway and historian store-and-forward volumes are sized at 50 GB to leave headroom for bursts and metadata. Our post on historian deadband and swinging-door compression explains why the change rate, not the tag count, drives these numbers.

Remote access consolidates 12 vendors onto one DMZ gateway with per-session approval. The three cellular routers are removed; one OEM, which contractually required its own modem, gets a dedicated externally connected zone under ZCR 3.6 with a conduit into only its skid’s PLC.

The cutover runs line by line. Each cell gets its zone firewall in monitor mode for two weeks, logging what would have been denied. The team fixes missing rows, then flips to enforce during a planned changeover. Packaging line 2 surfaced a monthly recipe sync from a Level 4 file share that the capture had missed; it was re-routed through the DMZ transfer service before enforcement.

Trade-offs, Gotchas, and What Goes Wrong

The biggest failure mode is segmentation on paper. A drawing with nine zones means nothing if the firewall between two of them has an any-any rule added during a 3 a.m. outage and never removed. Rule drift is inevitable without the matrix-to-config diff described in Step 6.

The second is a DMZ that production depends on. If MES at Level 3 needs a licence server in the DMZ to start, a DMZ outage stops the plant. Every DMZ dependency should be tested by deliberately disconnecting the DMZ during a planned window and confirming that the plant runs.

Third, bypasses accumulate faster than controls. Cellular modems, wireless bridges, vendor remote agents and USB tethering on HMIs all defeat zone boundaries. Without passive monitoring for unexpected outbound connections, you will not know they exist.

Fourth, zero trust tools can fail closed. Agents on HMIs, inline proxies on controller conduits and identity provider dependencies can cut operator view. In OT, availability of view and control is a safety property, so any control that can fail closed must be justified against that risk.

Fifth, over-segmentation has a cost. Each zone boundary is a firewall to patch, a rule set to review and a troubleshooting step during an outage. Splitting a single machine cell into five zones rarely reduces real risk and frequently slows recovery. Use the “what would I isolate in an incident” test to stop.

Sixth, data diodes are sometimes oversold. They guarantee physics, not data integrity; malicious data can still flow outward, and the receiving side still needs hardening. They also make vendor support harder, which tempts teams to add an undocumented bypass.

Finally, IIoT write-back is where cloud projects quietly break the model. An optimisation service that “only adjusts setpoints” is a remote control path into Level 1 and deserves the same rigour as remote access.

Practical Recommendations

Start with the inventory and the flow matrix, not with firewall purchases. Most of the risk reduction in Purdue model OT segmentation comes from deleting flows nobody needs and from closing dual-homed hosts and shadow modems, all of which cost little. The second largest gain usually comes from moving remote access into a brokered DMZ pattern with approval and recording.

Treat IEC 62443-3-2 as your documentation backbone, even if you never seek certification. Its zone and conduit drawings, characteristics and asset owner approval give auditors, insurers and regulators a common language, and they make segmentation survive staff turnover.

Adopt zero trust where it fits, starting at remote access and the DMZ, then Level 3 servers and engineering workstations. Do not wait for controllers to support it, and do not let a zero trust programme argue for removing zone boundaries. Watch the SP 800-82r4 draft as it moves towards final; if your organisation has views on how zero trust should apply to OT, the comment period runs to 30 November 2026.

A short checklist to run this quarter:

Inventory every asset, including cellular and wireless devices, and tag each with a Purdue level and owner.
Capture at least one full production cycle of traffic and build a version-controlled flow matrix.
Confirm no session crosses from Level 4 to Level 3 without terminating in the DMZ.
Remove dual-homed hosts and any-any rules; add DPI write allowlists on controller conduits.
Move all remote access to a DMZ gateway with MFA, approval, recording and automatic expiry.
Make IIoT outbound-only through a DMZ broker; route any write-back through a separate approved conduit.
Place a separate safety zone with at most one-way diagnostics.
Deploy passive monitoring at zone boundaries and alert on new talkers and internet egress.
Disconnect the DMZ in a planned test and confirm production runs.

Frequently Asked Questions

Is the Purdue model still relevant in 2026?

Yes, as a functional and data-flow map rather than a literal network design. Its levels still describe which systems should talk to which, and the Level 3.5 industrial DMZ remains the standard way to stop sessions crossing directly between IT and OT. What changed is enforcement: IEC 62443 zones and conduits replace level-based VLANs, IIoT connections must be outbound-only, and zero trust adds session-level authorisation at Level 3 and above where devices can support it.

What is Level 3.5 in the Purdue model?

Level 3.5 is the industrial demilitarized zone, a buffer network between site operations at Level 3 and enterprise systems at Level 4. It was not in the original PERA hierarchy; practitioners added it later. Its defining rule is that no protocol session traverses it end to end. Services such as historian replicas, patch staging, MQTT brokers and remote access jump hosts terminate connections from both sides, so a compromise of the office network does not give a direct route into the control system.

How do Purdue levels map to IEC 62443 zones and conduits?

Purdue levels are a starting point for zones, not a one-to-one mapping. IEC 62443-3-2 groups assets with the same security requirements into zones and the communication channels between them into conduits, each with a target security level. A single Purdue level is often split into several zones, for example one per production line, and the standard requires separating safety-related assets, wireless devices, temporarily connected devices and externally connected devices into their own zones.

Does zero trust replace network segmentation in OT?

No. Zero trust authenticates and authorises each session based on identity and context, but it depends on endpoints that can carry identity, and many PLCs, controllers and HMIs cannot. Current guidance applies zero trust at Level 3, the DMZ and remote access, while treating Levels 1 and 2 as zone boundaries. Segmentation still limits blast radius, and zero trust controls must never be able to cut operator view or control if they fail.

Do I need a data diode or is a firewall enough?

A firewall is enough for most plants if rules are default deny, scoped, inspected and reviewed. A data diode adds a physical guarantee of one-way flow, which suits high-consequence sites where outbound telemetry is the only business need, such as nuclear or some utilities. The cost is functional: diodes cannot carry interactive sessions, patch pulls or bidirectional protocols, so you still need a separately controlled path for maintenance and remote support.

How should IIoT and MQTT connect to the cloud without breaking segmentation?

Keep every connection outbound. An edge gateway reads from controllers, preferably read-only, and publishes over MQTT with TLS to a broker in the industrial DMZ, which then bridges outbound to the cloud. The cloud never initiates a connection into the plant. If a use case needs write-back, route it through a separately approved conduit with a local application that validates and rate-limits writes, and put wireless sensors and vendor cloud agents in their own zones.

References

NIST, SP 800-82 Rev. 4 Initial Public Draft, Guide to Operational Technology Security, September 2026.
NIST, SP 800-82 Rev. 3 announcement, September 2023.
NIST, SP 800-207 Zero Trust Architecture, August 2020.
ISA, ISA/IEC 62443-3-2 table of contents, zone and conduit requirements ZCR 1 to ZCR 7.
IEC, IEC 62443-3-2:2020 Security risk assessment for system design.
ISA Global Cybersecurity Alliance, Zero Trust Outcomes Using ISA/IEC 62443 Standards, 2024.
CISA and partners, Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators, August 2025.

By Riju — about

How to Apply the Purdue Model in 2026: OT Network Segmentation, Industrial DMZ Design and Where Zero Trust Fits