Cybersecurity for Industrial IoT: The OT/IT Convergence Problem

The traditional industrial network security model was simple: air gap. The OT network — PLCs, SCADA systems, field instruments — was physically isolated from everything else. No internet connectivity, no corporate network connection, no remote access. Malware can't reach what it can't connect to.

That model worked when OT networks were genuinely isolated. It started breaking down when organizations installed remote access capabilities for vendor support, when corporate networks and OT networks got connected for ERP integration, and when the IoT movement created a new category of devices that deliberately bridge the OT/IT boundary to send sensor data to cloud platforms. Today, most industrial networks are no longer truly isolated — they just haven't been designed for the connectivity they have.

What the OT/IT Boundary Actually Looks Like

In a well-designed facility, the OT/IT boundary is implemented as a demilitarized zone (DMZ) with a two-firewall architecture: one firewall between the OT network and the DMZ, one between the DMZ and the corporate IT network or internet. Data flows out of OT through approved paths; nothing flows in from IT to OT without explicit allow rules and often manual intervention.

In practice, many facilities have grown organically and the boundary is less clean. Common issues: a vendor installed a cellular router directly on the OT network for remote support five years ago and it's still running. Someone connected a laptop to both networks simultaneously to transfer files. A SCADA server has a corporate network interface for reporting and an OT network interface for control, making it a de facto bridge. An IoT gateway was installed by an operations team without IT security review and has outbound internet connectivity from inside the OT VLAN.

Each of these creates a path that wasn't formally evaluated. The air gap model's security relied on there being no path; once there are paths, the assumption of isolation is wrong and the network needs to be defended as if it's connected.

Why OT Devices Are Particularly Vulnerable

IT security has spent 30 years developing patching infrastructure, endpoint detection, certificate management, and secure configuration standards. Most OT devices have none of this. A PLC installed in 2008 is running firmware from 2008. It may have known vulnerabilities with published exploits. It cannot be patched without taking the process it controls offline, which requires a planned maintenance window. In some cases, the original vendor no longer exists and patches are simply not available.

Modbus TCP, which runs on most legacy PLCs, has no authentication. Any device on the OT network can read and write registers on any Modbus device without credentials. An attacker with network access to the OT segment can issue Modbus write commands to change setpoints, disable interlocks, or command actuators directly. The PLC will execute the command because Modbus has no mechanism to distinguish authorized commands from malicious ones.

OPC UA is better: it has proper PKI-based authentication and can require mutual certificate verification. But OPC UA security configuration is often set to "None" (no security) during commissioning for ease of initial setup, and then never changed. A 2021 survey found that over 40% of OPC UA deployments had security mode set to None — essentially disabling the security features the protocol provides.

The IoT Gateway as a Security Boundary

An IoT gateway in a properly designed deployment sits at the OT/IT boundary. It has an interface on the OT network for reading sensor data and an interface (or a WAN connection) for transmitting data outward. This position makes it both a useful security control point and a significant risk if compromised.

The outbound data channel — typically MQTT over TLS to a broker — should be one-directional from a network perspective: the gateway initiates connections and pushes data, but accepts no inbound connections. This is implemented through firewall rules that allow outbound TCP on port 8883 from the gateway's IP, but deny all inbound connections to the OT segment from the DMZ or external network.

The gateway firmware itself must be maintainable. This is a non-trivial requirement: firmware updates need to be deployable without physical access to the device, updates need to be cryptographically signed and verified before execution, and the update mechanism must not create an inbound connection path that bypasses firewall rules. Over-the-air update through an outbound-initiated connection to an update server — where the gateway polls for updates rather than accepting pushed updates — is the secure pattern.

Network Segmentation Inside OT

Treating the entire OT network as a single flat trust zone is its own security problem. If any device on the OT VLAN can reach any other device, then a compromised OT workstation (common due to unpatched Windows XP/7 SCADA systems) can reach every PLC and instrument on the network directly.

NIST SP 800-82 and IEC 62443 both recommend network segmentation within OT: separate VLANs for different process areas or risk levels, with firewall or access control list rules between segments. The change is cheap (modern managed switches support 802.1Q VLANs natively), the operational impact is minimal if done carefully, and the blast radius of any single compromised device is significantly reduced.

For IoT deployments specifically, wireless sensors should be on their own VLAN with access only to the IoT gateway — not to the broader OT network. If a wireless sensor node is compromised or spoofed, it should have no path to PLCs or SCADA systems.

The Patch Problem Has No Clean Answer

The honest answer to "how do you keep OT devices patched?" is that for legacy devices, often you can't. The realistic approach is: patch what can be patched (gateways, workstations, historian servers), compensate for what can't be patched with network controls and monitoring, and establish a roadmap for replacing end-of-life devices on a multi-year schedule as maintenance budgets allow.

The worst outcome is acknowledging that OT devices can't be patched and concluding that no security controls are worth implementing. Network segmentation, outbound-only data paths, and anomaly detection on the OT network traffic are all meaningful controls that significantly raise the cost and complexity of an attack, even against devices that will never see another firmware update.