The moment a plant floor starts feeding data to a cloud platform, it inherits a security problem neither classic operational technology nor classic IT was designed to solve on its own.
Operational technology — the PLCs, sensors, and control systems that run a plant floor — was historically designed for availability and physical safety, on a network that was assumed to be physically isolated. IT security was built for a different threat model: internet-facing systems, frequent patching, and centrally managed identity. Industrial IoT projects sit exactly at the seam between those two worlds, and the security failures that make headlines almost always trace back to that seam being treated as a simple network cable rather than the trust boundary it actually is.
Most industrial IoT deployments introduce a gateway device that bridges an OT-side fieldbus protocol to an IT-side or cloud-side connection — see our note on industrial protocol integration for the protocol side of that bridge. It's tempting to treat that gateway as a pure protocol translator, but it's also the single point where the OT network's trust assumptions meet the IT network's. A gateway that accepts unauthenticated writes back down to the OT side, or that shares credentials across both networks, turns a data-collection project into a control-plane exposure. Designing the gateway's authentication, and strictly limiting what it's allowed to write back into the OT network, needs to happen at the architecture stage — not as a hardening pass after a pilot goes into production.
A significant share of the installed base of PLCs and industrial controllers in the field predates any expectation that they'd be network-reachable beyond a physically isolated control network, and many have limited or no authentication on their native protocols. That reality shapes the right architecture: rather than exposing legacy controllers directly, a well-designed system keeps them on an isolated OT segment and lets the gateway be the only thing that talks to both sides. This is as much a decision about what a retrofit project chooses not to expose as it is about what it connects — see our note on retrofitting legacy industrial equipment for the sensing side of that same tradeoff.
Network segmentation between OT and IT is well-understood in principle — a demilitarized zone between the two networks, with the gateway and any historian or data-collection systems living in that DMZ rather than bridging directly. In practice, segmentation erodes over time: a maintenance vendor gets remote access for troubleshooting, a temporary connection for a commissioning task never gets removed, a firewall rule gets loosened to fix an urgent issue and never gets tightened back. Designing the system so segmentation is enforced by architecture — separate physical or VLAN-isolated networks, a gateway that can't be used as a pivot point — makes it more resilient to that organizational drift than a policy alone would be.
On the IT side, security monitoring is built around detecting compromise. On the OT side, the more common and more damaging failure mode is a security control interfering with availability — an intrusion-prevention system that blocks a legitimate but unusual control message, or a patch cycle that requires downtime a continuous process can't tolerate. Security architecture for OT/IT convergence has to be designed with that asymmetry in mind: passive monitoring and anomaly detection that observes without inserting itself into the control path, and a patch and update strategy that respects the plant's actual maintenance windows rather than IT's default cadence.
OT/IT convergence security is an architecture decision made once, at the start of a project, not a checklist applied after connectivity already exists. See our firmware work and cloud & device platform work for how we design the gateway and segmentation layer together, and our industrial IoT development work for how this fits into a full plant-connectivity program.
Related reading: the physical-access and blast-radius reasoning that shapes secure boot and device authority on grid-edge hardware applies just as directly to industrial gateways — see our note on grid-edge device security.
