OT Network Security: Devices and Architecture

One Gate, No Depth

Most industrial facilities have one firewall at the enterprise boundary and nothing between the business network and the controllers below it. An attacker who bypasses that single gate reaches every PLC on the plant floor without crossing another control. The zone and conduit model from Chapter 6 establishes the policy design: which assets belong in which zones, what traffic is permitted to cross each boundary, and at what security level. This chapter covers the devices and architectures that implement that policy in physical hardware. It addresses a specific structural problem first: the protocols running on OT networks were not designed for security, and the adoption of TCP/IP Ethernet in industrial facilities happened for operational reasons that had nothing to do with security risk. The compensating controls that address those structural properties -- the right firewall class for each boundary, the device-level enforcement that prevents lateral movement inside the control zone, the passive detection tools that alert without creating blocking risk, the hardware data diode that enforces one-way data flow at the physical layer -- are the subject of this chapter. It closes with DMZ architecture: the buffer zone that allows the historian and the enterprise ERP to share data without creating a direct path between the business network and the control network.

Why IACS Networks Are Structurally Vulnerable

Modbus was designed in 1979 as a protocol for serial communication between PLCs and computers in facilities where everything on the wire was physically isolated from the outside world. It has no authentication, no encryption, and no authorization mechanism. Any device that can send a well-formed Modbus message to a PLC can command it without presenting any credential. That is not a software bug waiting for a patch -- it is a structural property of a protocol built before network security was a requirement. Modbus TCP, the version that runs over standard Ethernet, preserved the 1979 protocol unchanged and wrapped it in a TCP transport. The transport layer changed; the security posture did not. DNP3 Secure Authentication has been in development since the late 1990s and has progressed through multiple specification versions; as of 2026, field deployment of DNP3 security extensions remains near-zero across the utility and water sectors it primarily serves. CIP Security adds TLS-based authentication to EtherNet/IP, but is unavailable on the legacy devices that account for the majority of installed equipment and cannot be economically replaced. The protocols used to control physical processes in most operating facilities today are structurally unauthenticated, and that condition will not change through software updates. Through the 1990s and 2000s, industrial facilities replaced proprietary serial fieldbus wiring with standard Ethernet hardware. The reasons were entirely operational: Ethernet was dramatically cheaper, faster, and better-supported than the proprietary alternatives it replaced. Security was not part of the evaluation criteria, because the assumption was that physical isolation -- the air gap -- would keep the network safe regardless of what the protocols offered. That assumption collapsed as remote access, cloud connectivity, and IT/OT integration became standard operating requirements. The protocols did not change when the networks they ran on became connected. The gap between what the protocols assume and what the network actually is became the primary attack surface of modern ICS security.

The OSI Model as an OT Attack Surface Map

The OSI model's seven layers -- Physical, Data Link, Network, Transport, Session, Presentation, and Application -- describe how network communication is structured from the cable through to the application payload. Each layer is an active attack surface in OT networks, and each layer requires a specific class of security control to address it. Physical-layer threats target the network connection itself: an unauthorized device plugged into an open port on a control network switch gains a Layer 1 foothold before any network-layer control can evaluate it. Port lockdown -- disabling unused switch ports and requiring MAC authentication on active ports -- addresses this at the physical layer before any packet is sent. At Layer 2, MAC address spoofing allows an attacker to impersonate a trusted device by forging its hardware address; this bypasses rules that rely on device identity. At Layers 3 and 4, the Network and Transport layers, the threats include IP address spoofing, port scanning, and unencrypted TCP sessions that expose Modbus or DNP3 payloads to interception. These are the layers that traditional stateful firewalls address. At the Application layer -- Layer 7 -- the threat is not just who is connecting but what they are sending: malformed protocol commands, unauthorized Modbus write function codes, and replayed DNP3 messages that repeat a previously captured legitimate command. A firewall that inspects only IP addresses and port numbers cannot see Layer 7. It knows a packet arrived on port 502 -- the standard Modbus TCP port -- but it cannot see whether that packet contains a read command or a write command. Matching the right security control to the right layer is the core design decision in OT network security, and it determines which threats each tool in the architecture actually stops.

The Six-Tier Device Hierarchy

Network security devices form a hierarchy based on how deep into a packet they inspect. A Layer 2 switch makes no security decisions about content -- it forwards frames based on MAC addresses and has no awareness of what those frames carry. A router operating at Layer 3 reads source and destination IP addresses to make forwarding decisions but does not evaluate packet content. A packet filter firewall adds the ability to allow or deny traffic based on IP address, port number, and protocol type -- but it reads only the header, not the payload. It can block port 502 entirely, but it cannot distinguish a read command from a write command on port 502. A stateful inspection firewall adds session tracking: it maintains a record of active connections and permits only packets that belong to sessions established from the allowed direction. This stops replay attacks -- the firewall rejects packets that arrive outside any recognized session context -- but it still does not inspect application-layer content. Once a legitimate session is established, every command inside it passes through unchecked. An application proxy firewall terminates the connection, reads the complete application-layer payload, and then opens a fresh connection to the destination. It can inspect every Modbus function code, validate every DNP3 message, and reject anything outside a defined policy. The tradeoff is latency: two full TCP handshakes happen for every session, which is tolerable at higher architectural layers but can disrupt control loops at Levels 1 and 2 where timing constraints are tight. A deep packet inspection (DPI) firewall reads the packet payload inline without terminating the session, providing application-layer visibility at speeds that approach stateful inspection. It can parse the Modbus function code inside every TCP segment on port 502 and enforce rules at the protocol command level. This is the only firewall class that can enforce OT protocol-level rules -- distinguishing who is connecting from what they are commanding.

IACS-Specific Firewalls and the Three-Layer Architecture

Standard enterprise firewalls, even DPI-class models, are not sufficient at the device level in operational ICS environments for three reasons. They are not built for OT physical conditions: a server room firewall will not operate reliably at the temperature ranges of a process floor or in the presence of the electromagnetic interference that motor drives and power switching equipment generate. Their application-layer inspection engines are written as generic platforms, not as purpose-built parsers for specific industrial protocols -- there is a meaningful difference between a generic DPI engine that can parse Modbus and a dedicated Modbus inspection engine that understands the complete specification including addressing modes and exception codes. And they cannot be installed inline in legacy OT cell networks without a significant integration effort. IACS-specific firewalls address all three: DIN-rail mounting, fanless sealed housings, and operating ranges typically from -40 to +75 degrees Celsius; purpose-built inspection modules for Modbus TCP, DNP3, EtherNet/IP, IEC 61850 MMS, and IEC 60870-5-104; and form factors designed for installation in existing process panel wiring. The Tofino Security Appliance from Belden deploys inline at the device or cell level using Loadable Security Modules -- protocol-specific inspection engines loaded for each protocol in use. A Modbus TCP Enforcer module configured on a Tofino protecting a PLC cluster permits only read function codes (FC01, FC02, FC03, FC04) from the authorized SCADA server IP address. Write function codes (FC05, FC06, FC15, FC16) are denied from all sources. The PLC has no built-in authentication; the network device provides protocol-level enforcement before traffic reaches the device. The Moxa EDR series combines router, firewall, NAT, VPN, and DPI into a single DIN-rail unit with inspection coverage for Modbus TCP, DNP3, IEC 61850 MMS, and IEC 60870-5-104. The Fortinet FortiGate Rugged adds OT-specific IPS signatures for Siemens, Rockwell, Schneider, and ABB equipment in substation-rated enclosures. A functioning defense architecture deploys these at three layers: an enterprise perimeter firewall at the IT boundary, a control boundary firewall between the business network and the control zone, and IACS device-level firewalls protecting individual PLC clusters from everything else on the control network. Each layer stops threats the layer above it cannot see. The enterprise firewall and the control boundary firewall guard the perimeter but cannot stop a threat that is already inside the control zone -- a compromised workstation on the same network segment as the PLCs, a vendor laptop connected during maintenance, or an attacker who moved laterally from a DMZ host. The IACS device-level firewall limits what any source can command, regardless of where that traffic originated.

IDS, IPS, UTM, and Data Diodes

The central question when evaluating any security tool for use in an OT environment is not whether it has the capability to block. The question is whether the organization can tolerate a false positive at that location. In IT, a false positive on an IPS rule briefly inconveniences a user or requires a ticket. In OT, a false positive that triggers a block action on a Level 1 controller cuts off the commands that controller is issuing to the physical process. The outcome of that block -- on a running reactor, a conveyor system, or a water treatment chemical dosing process -- can be more dangerous than the threat the IPS was meant to prevent. This distinction shapes every tool choice in OT. An Intrusion Detection System monitors network traffic or host activity and generates alerts without taking any blocking action. Network IDS uses passive traffic observation; host IDS monitors activity on individual devices including file modifications, login events, and configuration changes. Both are safe at every OT level because a false positive produces an alert that a human investigates, not an automated block that disrupts a live process. IDS belongs throughout the OT architecture for exactly this reason. An Intrusion Prevention System adds automated blocking: traffic matching a threat signature is dropped before it reaches the destination. CISA has issued explicit caution against deploying active-blocking IPS at lower IACS levels because the false-positive risk directly translates to process risk. IPS is appropriate at Level 3 and the Industrial DMZ where the consequence of a false-positive block is operationally manageable; it should not be deployed at Level 1 or Level 2 without extensive traffic-specific tuning that establishes OT-normal behavior before any blocking rules are active. Unified Threat Management appliances bundle firewall, IPS, antivirus, VPN, and content filtering into a single device. The management simplicity is real: one vendor, one console, one renewal cycle. The architectural risk is also real: one misconfigured rule or one appliance failure takes every function down simultaneously. At an OT boundary, the IPS component of a UTM should operate in detection-only mode until the traffic baseline is established and false-positive rates are confirmed acceptable. A data diode enforces one-way data flow at the hardware level. The hardware component -- typically fiber optic with the receive path physically cut -- makes a return path physically impossible. No configuration error, firmware vulnerability, or software exploit can create a return path because no return path exists in the hardware. Data flows from the control network outward to the historian or monitoring system. Nothing can flow inward. Because TCP requires bidirectional acknowledgments that the diode cannot pass, proxy servers on both sides of the diode solve the timing problem: the source-side proxy accepts the TCP session from the OT device and emulates the acknowledgments locally, while the destination-side proxy receives the data stream and presents it as a new TCP session on the IT side. Data diodes apply where no return path to the OT network can ever be tolerated: historian replication to business systems, regulatory reporting feeds from secure zones, and remote monitoring exports from nuclear, defense, and high-security IACS environments.

DMZ Architecture: The Buffer That Holds

The historian problem is the clearest expression of the IT-OT connection dilemma. Operations needs production data in the ERP and business reporting systems. The historian collects that data from the control network. If the historian connects directly to both the business network and the control network, a compromise on the business side creates a routed path to the SCADA server. If the historian has no connection to the business network, operations loses the data integration it depends on. The DMZ resolves this without forcing a choice between security and function. The Industrial DMZ, introduced in Chapter 2 and implemented in the Zone and Conduit design from Chapter 6, sits between the enterprise zone and the control zone. Systems inside the DMZ can communicate with both networks. The enterprise network and the control network cannot communicate with each other directly -- every data path between them routes through the DMZ. This makes the DMZ the most tightly controlled zone in the architecture and the most consequential one to configure correctly. The historian in the DMZ receives data pushed from the control network and serves read queries to the enterprise network. Business systems never query the live historian directly -- they query the DMZ copy. The control network never reaches the business network. Remote access servers, VPN concentrators, and jump servers -- the hardened access point that all remote sessions must traverse before reaching any OT system -- all terminate in the DMZ rather than inside the control zone. Patch repositories serve OT systems from the DMZ; OT devices pull updates from the DMZ server while the DMZ server pulls from the internet, keeping the control network isolated from direct internet exposure. The architectural choice between one firewall with three interfaces and two separate firewall appliances is a risk tolerance and compliance question. A single three-interface firewall connecting the enterprise, DMZ, and control networks is simpler to manage and costs less. The risk is that a single misconfigured rule on that one appliance creates a direct path from enterprise to control; one firewall vulnerability can compromise all three zones simultaneously. Two separate firewall appliances at each boundary -- optionally from different vendors to prevent a single platform vulnerability from compromising both boundaries -- provide higher assurance. Regulations and standards that mandate architectural defense-in-depth typically require the two-firewall design. The absolute architectural rule, regardless of which design is chosen, is that the enterprise network and the control network must never communicate directly. Every path between them must route through the DMZ. This is not a configuration preference -- it is the principle that makes the DMZ function as a security boundary. Any direct enterprise-to-control connection destroys the DMZ's purpose regardless of how securely the DMZ itself is configured.

What's Next

Chapter 9 has built the device and architecture layer: the six-tier hierarchy that maps inspection depth to enforcement capability, the three-layer defense architecture that ensures no single boundary failure exposes the control network, the selection criteria for IDS, IPS, data diodes, and UTM based on whether a false positive is tolerable at each location, and the DMZ design that resolves the historian-to-enterprise data sharing problem without creating a direct enterprise-to-control path. Chapter 10 moves to the access control layer: remote access architecture, authentication mechanisms for OT environments, and the wireless controls that apply when field sensors and maintenance tools connect without cables.

Reflect

• The firewall class hierarchy identifies deep packet inspection as the only class that enforces protocol-level rules. For the most critical conduit boundary in your environment -- the one carrying Modbus or EtherNet/IP traffic between the SCADA zone and the field device zone -- can the firewall enforcing that boundary distinguish a read function code from a write function code? If not, it is enforcing a connection policy, not a command policy.
• The three-layer defense architecture places IACS device-level firewalls at the PLC cluster level to stop threats that have already entered the control zone. Does your environment have any enforcement at the device level, or does every device in the control zone have unrestricted access to every other device on the same network segment?
• The IDS vs. IPS distinction in OT environments turns on whether a false positive at that location creates a process risk. For each security tool currently deployed in your control network, is it in detection mode or blocking mode -- and for any tool in blocking mode, has the OT-normal traffic been baselined to establish an acceptable false-positive rate before blocking was activated?
• The DMZ architecture section states that the enterprise and control networks must never communicate directly. Examine the firewall rules governing your Industrial DMZ -- or the zone that performs that function in your environment. Is there any rule that permits a direct connection from a business network IP to a control zone IP without routing through an intermediate system in the DMZ?