Inside the industrial IoT gateway solutions connecting the modern factory

Industrial IoT gateway solutions sit at the centre of every successful factory digitalisation project, doing all of the translation work (e.g. interpreting protocols from legacy devices, or contextualising raw data for decision-makers sitting three layers up the network stack) that makes IIoT function at scale. And yet, they are often the last piece specified rather than one of the first. Get the gateway layer wrong, and every sensor, protocol, and analytics platform built on top of it inherits the same weaknesses. 

This guide sets out the architecture that connects the factory floor to the cloud, and introduces the six areas this series will explore in depth: messaging protocols, wireless connectivity, gateway hardware, security compliance, edge implementation, and the predictive maintenance outcomes the whole stack exists to deliver.

Why industrial IoT architecture needs its own design rules

Consumer IoT and industrial IoT are frequently discussed as though they are the same problem at different scales, but they’re not. A smart thermostat that drops its connection for a few minutes is an inconvenience. A pressure sensor on a chemical reactor that drops its connection for just thirty seconds during an excursion event is a critical safety incident. For example, if the disconnected sensor is tied to a Safety Instrumented System (SIS), the logic solver cannot process the true state of the reactor, preventing automatic mitigating actions like crash-cooling, venting, or stopping chemical feeds.

This distinction shapes every decision in industrial architecture. Consumer IoT optimises for convenience and low unit cost. Industrial IoT optimises for determinism, longevity, and survivability in environments that consumer electronics were never designed to tolerate: electromagnetic interference from variable frequency drives, temperature swings inside unventilated enclosures, vibration from rotating machinery, and network segments that may not have been touched in the years since the control system was commissioned.

The result is a layered architecture that looks deceptively similar to a standard IT stack, but where every layer carries additional constraints. Understanding this layered structure is the purpose of this guide, and each layer maps directly to a post later in this series.

The four layers of an industrial IoT architecture

1. The Sensing and Field Layer: IIoT Sensors and Data Capture

At the bottom of the stack sit the sensors and actuators themselves: vibration accelerometers on rotating equipment, temperature and pressure transmitters, current clamps on motor circuits, and increasingly, retrofitted condition-monitoring devices bolted onto legacy assets that were never designed with connectivity in mind. This layer generates the raw data that everything above it depends on, and its quality is non-negotiable. No amount of downstream analytics can compensate for a poorly calibrated sensor or an intermittent physical connection.

A second, often overlooked consideration at this layer is retrofit versus greenfield deployment. Most industrial sites are not building a factory from scratch; they are adding sensing capability to assets that have been running for twenty or thirty years without any digital instrumentation at all. Retrofitting condition-monitoring hardware onto legacy equipment introduces constraints that a greenfield design never has to consider: limited or non-existent power at the mounting point, enclosures that cannot be modified without invalidating a certification, and installation teams who need to complete the work during a scheduled shutdown window measured in hours rather than days. 

Architecture decisions made further up the stack need to account for this reality, because a gateway or protocol that assumes clean, purpose-built field wiring will struggle against the wiring most sites actually have.

2. The connectivity layer: MQTT and industrial wireless networks

Data generated at the field layer has to travel, and how it travels is one of the most consequential decisions in the entire architecture. Two topics in this series sit squarely in this layer.

MQTT has become the de facto messaging protocol for industrial telemetry, and for good reason. Its publish-subscribe model, lightweight overhead, and built-in support for unreliable networks make it a strong fit for sites where connections drop and bandwidth is limited. The next post in this series looks at how MQTT is implemented in industrial contexts, including broker architecture, quality-of-service levels, and where it fits alongside older protocols like Modbus and OPC UA rather than replacing them outright.

Wi-Fi HaLow addresses a different problem: physical reach. Standard Wi-Fi struggles across the distances and structural interference typical of large industrial sites, tank farms, and outdoor yards. HaLow’s sub-gigahertz operation trades bandwidth for range and penetration, making it a candidate for exactly the kind of long-distance, low-power sensor deployments that industrial condition monitoring requires. We cover this in detail in the second post of the series.

3. The gateway layer: Industrial IoT gateway hardware

This is the layer where the connectivity and protocol choices made above physically converge, and it is arguably the most under-specified part of most industrial IoT deployments. A gateway has to translate between field-level protocols and cloud-facing ones, buffer data during network outages, apply edge logic to reduce the volume of traffic sent upstream, and do all of this reliably inside an enclosure that might sit in a cabinet at 55°C next to a variable frequency drive.

Two posts in this series address this layer from different angles. One covers gateway design principles in general: processing requirements, I/O flexibility, thermal management, and the reliability engineering that separates a gateway that survives five years in the field from one that needs replacing within eighteen months. The other looks specifically at ESP32-based gateways, an increasingly common choice for cost-sensitive deployments where a full industrial PC is unnecessary overhead, and examines where that platform is genuinely fit for purpose and where its limitations start to bite.

4. The security and analytics layer: IEC 62443 and predictive maintenance

Everything built in the layers below becomes a liability if it is not secured, and this is where IEC 62443 enters the picture. Unlike IT security standards built around office networks, IEC 62443 was written specifically for industrial automation and control systems, addressing the reality that many operational technology assets cannot simply be patched on the same schedule as a laptop, and that availability, not just confidentiality, is often the primary security concern. The fourth post in this series unpacks how IEC 62443’s zones and conduits model applies to IoT devices specifically, and what it means in practice for gateway and device procurement.

At the top of the stack sits the reason any of this exists in the first place: predictive maintenance. Vibration, temperature, and current data flowing up through a well-designed, well-secured architecture become the input for models that can flag bearing wear, motor imbalance, or insulation degradation weeks before failure. The final topic-specific post in this series covers what predictive maintenance systems actually need from the architecture beneath them, and where projects commonly fail not because the analytics were wrong, but because the data feeding them was incomplete or untrustworthy.

Why this Industrial IoT Architecture Guide is structured as a stack

Each of these six topics is often written about in isolation and treated as an isolated purchasing decision as a result. A facilities team evaluates a predictive maintenance platform; a networking team separately evaluates wireless standards; and a security team bolts on compliance requirements after the architecture is already built. The consequence is a stack where each layer was optimised individually, resulting in integration problems that only surface once equipment is already installed because the system as a whole wasn’t designed coherently.

This series is structured deliberately as a stack rather than a list of unrelated technologies, moving from the communication layer upward through gateway hardware, security, and finally the business outcome those layers exist to support. The closing piece in this series returns to this theme directly, examining the integration risks that emerge specifically at the boundaries between these layers, in the same way our previous series on defence electronics integration blind spots closed by examining the interface risk between disciplines rather than within any single one.

Edge computing vs cloud processing in industrial IoT

One architectural question cuts across all four layers rather than sitting neatly inside one of them: how much processing should happen at the gateway, and how much should be pushed upstream to a cloud or on-premises server? This is not a purely technical question; it is shaped directly by the connectivity and security choices made elsewhere in the stack.

A site with limited or intermittent connectivity, the kind of environment Wi-Fi HaLow is often chosen for, generally needs to do more processing at the edge, because it cannot rely on a constant, low-latency link to a central system. Raw vibration data sampled at high frequency may need to be converted into summary features locally, with only the features (rather than the full waveform) sent upstream. Conversely, a well-connected site with fibre to every cabinet has more freedom to centralise processing, simplifying the gateway at the cost of higher bandwidth consumption.

Security requirements under IEC 62443 also push work toward the edge in many deployments, since data is reduced and anonymised at the gateway before it leaves the operational network, which carries less risk than raw data traversing a wider network boundary. This is one of several places where the layers of this stack interact in ways that are easy to miss if each is specified independently, and it is a theme the closing synthesis piece in this series will return to directly.

Industrial IoT architecture: What it means for engineers

For engineering teams, the practical takeaway is to resist specifying each layer in isolation. Protocol choice constrains gateway processing and memory requirements. Wireless medium constrains achievable data rates and therefore what can realistically run at the edge versus the cloud. Security requirements under IEC 62443 constrain which hardware platforms are viable at all, since not every gateway architecture can support the segmentation and update mechanisms the standard expects. Working through these dependencies early, before hardware is procured, avoids costly rework later.

Industrial IoT gateway solutions: What it means for procurement and operations

For those holding budget and operational responsibility, the key point is that industrial IoT architecture is a system-level decision, not a shopping list of point products. A gateway that is cheaper up front but incompatible with the security posture the site will eventually need is not actually cheaper. A wireless standard chosen without reference to the protocol running over it may deliver connectivity without delivering usable data. Evaluating vendors and platforms against the full stack outlined here, rather than against a single layer, is the difference between a pilot project that scales and one that stalls at proof of concept.

A useful discipline for procurement teams is to request a single architecture diagram from any vendor proposal, showing every layer from sensor to analytics dashboard and naming the protocol and security mechanism at each boundary. Vendors who can produce this cleanly are generally the ones who have thought through the integration problem; vendors who can only describe their own layer in isolation are handing that integration risk to the buyer, whether or not that risk is priced into the proposal.

Next in this Industrial IoT series: MQTT 

The next post in this series looks at MQTT in industrial IoT in detail, covering broker architecture, quality-of-service considerations, and how it fits alongside legacy industrial protocols already present on most sites. From there, the series works up through connectivity, gateway hardware, security, and finally predictive maintenance outcomes, before closing with a synthesis piece examining where these layers most commonly fail to integrate cleanly.

Industrial IoT gateway solutions are not a single product decision. They are the architectural backbone that determines whether every other investment in connected industrial equipment delivers a return, or simply generates more data that nobody trusts enough to act on.