Most industrial networks were not designed; they accreted. A switch added for a new line, a router dropped in for the warehouse, a remote site bolted on with whatever connectivity was available that month. The result works until it has to be secured, audited, or scaled — at which point the absence of a reference architecture becomes the central problem. This article walks through a clean IT/OT reference architecture based on the well-established Purdue model, showing where firewalls, switches, and management sit and how traffic should and should not flow. It is deliberately vendor-architecture-led: the principles hold regardless of whose boxes you buy.
The Purdue model in one paragraph
The Purdue model organises an industrial network into layers, from the enterprise IT at the top down through a demilitarised zone (DMZ), then the operations and control layers, down to the field devices — the PLCs, RTUs, and sensors that actually touch the physical process. The core idea is simple and durable: the closer a layer is to the physical process, the more protected and the less exposed it must be, and traffic between layers should be deliberate, inspected, and minimal. The model is decades old and still the backbone of credible OT security design.
The layers, top to bottom
- Enterprise / IT (top) — business systems, email, ERP, general internet access. This is the most exposed layer and the one attackers most often reach first.
- Industrial DMZ — the buffer between IT and OT. Shared services that both sides need (for example data historians, patch servers, remote-access brokers) live here so that IT never talks directly to OT. All permitted flows through the DMZ should be explicitly approved, logged, and inspected or brokered according to risk.
- Operations / process network — supervisory systems, HMIs, operator workstations, engineering stations.
- Control network — the controllers themselves: PLCs, RTUs, and IEDs issuing and receiving real-time commands.
- Field network (bottom) — the sensors and actuators in direct contact with the physical process.
Where the boxes go
With the layers defined, placement follows naturally:
- Enterprise-edge firewall — a standard (non-rugged) next-generation firewall at the IT perimeter, handling internet access and enterprise traffic.
- DMZ firewall — the critical control point between IT and OT. This is where the strictest policy lives: it is the only sanctioned path between the two worlds, and it inspects everything that crosses.
- Rugged firewalls inside OT — between and within the operations, control, and field layers, where the environment demands ruggedised hardware and where OT-aware inspection and virtual patching protect the controllers.
- Rugged switches — the access layer inside OT zones, extending segmentation down to the port and integrating with the firewalls for unified policy.
- Centralised management — a single management plane spanning all sites, giving IT and OT teams shared visibility and consistent, auditable policy without logging into each device by hand.
How traffic should flow
Two traffic directions matter, and good architecture controls both:
- North–south — traffic moving between layers (IT to DMZ to OT). This must always pass through a firewall conduit and be inspected. The default posture is deny; only explicitly required flows are permitted, and IT never reaches OT directly — only via the DMZ.
- East–west — traffic between devices within the same layer. This is where lateral movement happens, and where microsegmentation earns its place: controlling device-to-device traffic so a compromise in one cell cannot spread sideways across the control network.
| Architectural principle The DMZ exists so that IT and OT never speak directly. If you find a flow that bypasses the DMZ — a laptop on the business network with a direct route to a PLC — that is the single most important thing to fix, regardless of what else the architecture gets right. |
Remote sites and the central SOC
Few industrial operations are a single site. Remote substations, pumping stations, and satellite plants each need their own local instance of this architecture — a rugged firewall enforcing local policy and local protection — connected back to a central operations or security operations centre. The remote site stays protected even when disconnected (local enforcement does not depend on the link), while the central SOC gets aggregated visibility and pushes consistent policy outward. Connectivity back to the centre is wired where it exists and cellular where it does not, with SD-WAN steering and healing the path. The same layered model repeats at every site; only the scale changes.
Using this as a design checklist
- Can you draw your current network in these layers? If not, that mapping is the first deliverable.
- Is there exactly one inspected path between IT and OT, through a DMZ? Eliminate every other crossing.
- Are north–south flows default-deny and explicitly permitted only where needed?
- Is there any east–west control inside the OT layers, or is it flat? Flat is the lateral-movement risk.
- Does each remote site replicate the model locally, with local enforcement that survives a link outage?
- Is everything managed and audited from one place, so policy is consistent and changes are traceable?
A reference architecture is not a product you buy; it is a target you converge on, usually over several phases. But having the target written down changes every subsequent decision — each new line, switch, and remote site gets placed deliberately within the model instead of bolted on beside it, and the network stops accreting and starts being designed.
Vays Infotech helps enterprises evaluate, deploy, and support firewall, network, and cybersecurity infrastructure across IT and industrial environments.
