Almost no industrial IoT project gets to pick its protocol — the equipment already on the plant floor picks it. Here's what actually differs between the protocols you'll be integrating against, and where each one's assumptions run out.
By the time an industrial IoT gateway gets specified, the protocol decision has usually already been made — not by the integration team, but by whatever PLC, drive, or sensor is already installed on the equipment being connected. The real engineering work isn't choosing a favorite protocol; it's understanding what each one assumes about the network it runs on, because those assumptions are exactly where integration projects run into trouble.
Modbus — in its RTU (serial) and TCP variants — remains the most widely deployed industrial protocol precisely because it's simple: a request/response model built around reading and writing numbered registers, with no built-in concept of authentication, encryption, or even a standardized way to describe what a given register means. That simplicity is also its limitation for integration work. Because a Modbus device will execute any correctly formatted request from anything that can reach it, the security posture of a Modbus network is entirely a function of what's allowed to reach it — which is exactly the segmentation argument covered in our note on OT/IT convergence security. And because register maps aren't self-describing, integrating a new Modbus device usually means starting from that device's register-map documentation, not from the protocol spec.
OPC-UA was designed specifically to solve what Modbus doesn't: it provides a standardized, self-describing information model (so a client can discover what data a server exposes and what it means, not just read raw register numbers), built-in authentication and encryption, and a client/server architecture that scales better across a large number of connected systems. The tradeoff is complexity — an OPC-UA server implementation is a meaningfully bigger undertaking than a Modbus one, and it assumes more computing headroom than some legacy field devices have. In practice, OPC-UA is increasingly the protocol of choice at the gateway-to-cloud or gateway-to-SCADA layer, sitting above a Modbus or fieldbus layer that's still doing the actual device-level communication — the gateway's job is often translating one into the other, not just picking one.
PROFINET is common in automation-heavy environments — particularly in Europe and in automotive and packaging-line equipment — and differs from both Modbus and OPC-UA in that it's built directly on Ethernet with real-time extensions for applications where cyclic communication timing genuinely matters (drive control, motion synchronization). Integrating with a PROFINET network for data collection purposes — rather than real-time control — usually means adding a passive listener or a gateway that doesn't compete for the network's real-time bandwidth budget, since introducing non-deterministic traffic onto a PROFINET segment can interfere with the timing guarantees the automation equipment depends on. This is a case where the integration architecture has to respect constraints that have nothing to do with IT-style network design.
Real industrial sites are rarely single-protocol. A plant floor commissioned over 15 years typically has Modbus RTU on older equipment, PROFINET on a newer automation cell, and an OPC-UA layer added when a SCADA upgrade happened — and a retrofit project has to integrate against whatever mix is actually there, not a clean greenfield choice. That's why the gateway, not any single protocol, is usually the right unit of design: a device (or software layer) responsible for normalizing multiple protocol sources into one consistent data model before anything reaches the cloud or a historian, so that upstream systems don't need to know or care which protocol a given data point originally came from. See our note on retrofitting legacy industrial equipment for how that plays out when the equipment itself predates any of these protocols being standard.
Protocol integration work lives or dies on correctly scoping which protocols are actually present on-site and what each one assumes about its network — guessing wrong here costs far more in rework than the initial site survey would have cost. See our firmware work and cloud & device platform work for how we design gateways that normalize multiple industrial protocols into one clean data model, and our industrial IoT development work for the full picture.
