An IIoT gateway is a small industrial computer that sits between plant equipment and the cloud. It does four jobs: translate the many protocols machines speak into one clean stream, buffer data when the network drops (store-and-forward), filter noise at the edge, and enforce a security boundary between operational technology (OT) and IT. It is the on-ramp from the floor to the data layer.
Everyone talks about connecting the factory. The gateway is the box that actually does it. Without one, a decades-old PLC speaking a 1979 serial protocol has no way to reach a modern analytics platform, and the platform has no safe way to reach the floor. The gateway is the piece that makes the two ends compatible without forcing either one to change. This guide covers what a gateway does, where it sits, why store-and-forward matters more than any spec sheet feature, and how to pick one that will still be trustworthy after the demo is over.
What does an IIoT gateway actually do?
It does four things, and every real gateway is some combination of them. Skip any one and the connection is fragile.
Translation is the headline feature, a gateway speaks the floor's languages downward (Modbus, PROFINET, EtherNet/IP, OPC UA) and one platform-friendly language upward (usually MQTT). Buffering is the underrated one: when the uplink drops, a good gateway keeps recording and sends everything once the link returns, so your history has no holes. Filtering means only meaningful changes travel, a temperature that has not moved does not need to be republished ten times a second. Securing means the gateway is the enforced border between the control network and everything above it, passing data out without opening a door back in.
Where does a gateway sit between machines and the cloud?
Between the control layer and the data layer, physically near the machines, logically at the OT/IT boundary. Think of it as the last device that belongs to the floor and the first hop toward everything above it.
This position is the whole point. Because the gateway straddles the boundary, it can honor two contradictory demands at once: the floor needs a deterministic, isolated control network, and the business needs data out of that network. The gateway satisfies both by reading down and publishing up, so the SCADA and PLC layer keeps its isolation while a data platform still gets a live feed. It is the practical expression of the IEC 62443 conduit, a controlled, inspected pathway between zones.
Why is store-and-forward the feature that matters?
Because plant networks are not data-center networks, they hiccup, and a metric with gaps is a metric nobody trusts. Store-and-forward means the gateway keeps writing to local storage the instant the uplink fails, then backfills the platform in order once the link returns. The result is a continuous record even across outages.
This is where the protocol choice earns its keep. Most gateways publish northbound over MQTT, a lightweight publish-subscribe protocol whose quality-of-service levels can guarantee a message is delivered even over an intermittent connection. Pair that guarantee with local buffering and a network drop becomes a delay, not a data loss. If you are choosing between two gateways and one has generous local storage and delivery guarantees while the other has a longer feature list, pick the one that never loses data. For the wider language question, see our guide to industrial communication protocols.
How do you choose an IIoT gateway?
Work down this list in order. The early items decide fit; the later ones decide whether you will still trust it in two years.
- Confirm the southbound protocols. List what your machines actually speak, Modbus RTU/TCP, PROFINET, EtherNet/IP, OPC UA, and require the gateway to support every one you have, not most of them.
- Confirm the northbound path. MQTT with quality-of-service guarantees is the safe default for moving data to a platform. Beware gateways that only push to one vendor's cloud.
- Demand real store-and-forward. Ask how much local storage it has, how long it can buffer, and whether backfill preserves order and timestamps. Then test it by pulling the network cable.
- Check the security boundary. It should support outbound-only, read-mostly connections, encrypted transport, per-device credentials, and firmware updates, the baseline for an IEC 62443 conduit.
- Size the edge compute. If you want filtering, unit conversion, or lightweight analytics at the edge, the gateway needs the CPU and memory to do it without falling behind.
- Plan the fleet. One gateway is easy; forty is a management problem. Look for central configuration, remote updates, and health monitoring before you scale.
How does a gateway handle a floor full of different machines?
By speaking every dialect downward and one language upward. A single gateway can poll a Siemens cell over PROFINET, a Rockwell line over EtherNet/IP, and a 1990s packaging machine over Modbus RTU, then normalize all of it into one consistent stream. That normalization is the quiet miracle: the platform above never has to know that press 4 talks Modbus and filler 2 talks OPC UA, because the gateway already flattened those differences into a common shape. This is the same reason a plant does not need to rip out old controllers to modernize, the gateway meets each machine on its own terms.
Two practical notes. First, mixed-vintage floors are the norm, not the exception; the average U.S. plant runs equipment spanning several decades, and a gateway is what lets the 1995 machine and the 2025 machine appear side by side on the same dashboard. Second, tapping a machine is usually read-only, the gateway subscribes to tags and reads registers without writing to control logic, so the production risk of adding one, done correctly, is low. That combination, broad protocol support plus non-invasive reads, is why gateways are the backbone of retrofit connectivity rather than greenfield-only technology. For the honest retrofit path machine by machine, see our IIoT deep dive.
Gateway, edge device, or protocol converter, what is the difference?
The terms overlap, and vendors blur them. Here is the honest distinction.
| Term | What it means | When you need it |
|---|---|---|
| Protocol converter | Translates one protocol to another, little else. No buffering or analytics. | Simple point-to-point bridging between two devices. |
| IIoT gateway | Translates, buffers (store-and-forward), filters, and secures the OT/IT boundary. | Getting floor data reliably into a platform or cloud. |
| Edge device / edge computer | A gateway with real compute, runs analytics, containers, or models locally. | When decisions or filtering must happen near the machine, not in the cloud. |
Most plants that think they need "edge computing" actually need a solid gateway with store-and-forward first, and edge compute later for specific cases like local anomaly detection. Buy for the job in front of you. A pile of overspec'd edge computers running nothing is a common and expensive way that connectivity projects stall, right next to the 200-sensor deployment that feeds a dashboard nobody opens. The discipline is the same in both cases: start from a question you cannot answer today, connect only what answers it, and let the first result earn the next box.
What do the standards and protocols say?
- OPC UA is the vendor-neutral standard for secure industrial data exchange, and its PubSub mode is designed to run over transports like MQTT while keeping OPC UA's security and information modeling (OPC Foundation).
- MQTT is a lightweight publish-subscribe messaging standard (OASIS; ISO/IEC 20922) whose quality-of-service levels support guaranteed delivery over unreliable networks, the basis for reliable store-and-forward (MQTT.org).
- The gateway's role as a firewalled, read-mostly boundary between OT and IT is exactly the zones-and-conduits pattern of the ISA/IEC 62443 security standards.
A gateway done right is the single most leveraged box in a connectivity project: it turns a floor full of incompatible, isolated machines into one reliable, secure data feed. That feed is what everything above it, machine monitoring true OEE, dashboards, and AI actions, is built on. Harmony reads from that layer, joins it with orders and operator input, and computes real numbers instead of estimates, with no rip-and-replace to the control system underneath (see how Harmony connects machines and systems). For the bigger picture of getting the floor online, start with our IIoT deep dive and how it dismantles manufacturing data silos.