An IIoT edge gateway is the device that turns a factory full of PLCs, meters and drives into a stream of structured MQTT messages that the rest of the business can use. This article explains the four jobs every gateway does (protocol translation, buffering, security and edge compute), shows a reference architecture, and gives you a practical checklist for choosing one.
Why Industrial Sites Need Edge Gateways
Industrial equipment was built to talk to other equipment on the same network, not to the cloud. A typical plant floor mixes Modbus RTU over RS485, Modbus TCP, OPC UA, EtherNet/IP, PROFINET and vendor-specific protocols, often on networks that are deliberately isolated from the office and the internet. Those protocols are mostly request-response: a client must poll each device for each value.
Cloud systems, dashboards and analytics expect something else: secure, outbound, event-driven data with consistent names and units. The gateway is the translator and the guard post between the two worlds. Without one, every application that wants machine data would need its own drivers, its own network path into the OT network and its own polling load on fragile controllers.
The Four Core Roles of an IIoT Edge Gateway
1. Protocol Translation and Data Modeling
The gateway polls or subscribes to devices in their native protocols and republishes the data over MQTT. Good gateways do more than copy registers: they apply scaling, units and names so that 40001 = 2351 becomes {"temperature_c": 23.51} on a meaningful topic like acme/plant1/packaging/line2/filler/temperature.
That naming step is where a gateway contributes to a Unified Namespace. If each gateway publishes into a shared ISA-95 style hierarchy (enterprise, site, area, line, cell), consumers can find data without knowing which gateway or protocol produced it. Specific translation paths are covered in the Modbus TCP to MQTT and OPC UA to MQTT gateway guides.
2. Buffering and Store-and-Forward
Plant networks and WAN links fail. A gateway that simply drops data while the broker is unreachable leaves gaps in history that are often impossible to backfill. Industrial gateways queue messages locally, on disk rather than only in memory, and replay them in order when the connection returns. The design details (buffer sizing, timestamps, replay rate) are in store and forward for MQTT.
3. Security Boundary
The gateway is usually the only device that touches both the OT network and an external network. That makes it the right place to enforce several rules:
- Outbound-only connections. The gateway opens a TLS connection to the broker; nothing on the internet initiates connections into the plant.
- Credential isolation. Only the gateway holds broker credentials. PLCs never do.
- Read-only by default. Writing setpoints from the cloud should be explicitly enabled per tag, if at all.
- Network segmentation. Two network interfaces, one per zone, with no routing between them, or placement in an industrial DMZ.
4. Edge Compute
Some logic belongs next to the machine: filtering noise, computing averages, detecting threshold crossings, or running alarms that must work even when the cloud is unreachable. The most valuable edge computation is often also the simplest: report by exception, which publishes a value only when it changes meaningfully and can reduce traffic dramatically compared with fixed-interval polling.
Reference Architecture
Shop floor (OT network) Edge Cloud / IT
------------------------ ----------------- ------------------
PLC (EtherNet/IP) ---\ | IIoT edge | TLS | MQTT broker |
Energy meter (Modbus) ----+----> | gateway | -----> | (8883) | --> dashboards
CNC (OPC UA / MTConnect) --/ | - drivers | outbound| | --> historian
| - modeling | only | | --> analytics
| - buffer | | |
| - RBE / rules | ------------------
-----------------
The gateway publishes to topics that follow the plant hierarchy. A typical payload looks like this:
{
"ts": "2026-10-16T08:14:03.512Z",
"values": {
"spindle_speed_rpm": 11980,
"spindle_load_pct": 41.5,
"program": "O1234",
"state": "RUNNING"
},
"quality": "GOOD",
"source": "gw-plant1-02"
}
Including a source timestamp, a quality flag and the gateway ID in every message makes buffered replays and troubleshooting far easier.
Choosing an IIoT Edge Gateway: Selection Checklist
| Criterion | Questions to ask |
|---|---|
| Protocol drivers | Does it support every protocol on your floor today, including legacy serial? Are drivers licensed per protocol or per tag? |
| MQTT client quality | MQTT 3.1.1 and 5? TLS with custom CA? Configurable QoS, retained messages, Last Will, keep alive? |
| Payload options | Plain JSON, Sparkplug B, or both? Can you control topic structure fully? |
| Store-and-forward | Disk-backed? How much? Ordered replay? Throttled replay? |
| Edge logic | Deadbands, scaling, scripting, or containers for custom code? |
| Hardware | DIN rail, wide temperature range, fanless, industrial power input, serial ports? |
| Management | Remote configuration and firmware updates without opening inbound firewall ports? |
| Security | Secure boot, signed updates, role-based local access, separate network interfaces? |
| Lifecycle | How long will the vendor support it, and can you export configuration if you replace it? |
Common Gateway Types
- Dedicated industrial gateways. Purpose-built DIN-rail units with a vendor configuration tool. Fast to deploy, limited to the protocols and logic the vendor provides.
- Industrial PCs running gateway software. More flexible: run a commercial connectivity platform, Node-RED, or your own containers. Requires more IT-style maintenance.
- PLCs and controllers with built-in MQTT. Many modern controllers can publish MQTT directly. This removes a box but puts network responsibilities on the controller, which not every plant is comfortable with.
- Microcontroller gateways. For small retrofits, a microcontroller can bridge a few Modbus devices to MQTT, as in the ESP32 Modbus RS485 to MQTT tutorial. Good for pilots and non-critical monitoring.
Sparkplug B or Plain JSON?
Gateways increasingly offer Sparkplug B, which adds a standard topic namespace, birth and death certificates for state awareness, and compact Protobuf payloads. Plain JSON is easier to read and consume from any tool. Many plants use both: Sparkplug B from gateways, and a readable ISA-95 JSON view for consumers. ConnectMQ can decode Sparkplug B payloads and republish them into ISA-95 topics, for example turning spBv1.0/factory1/DDATA/line1/cnc1 into connectmq/factory1/production/line1/cnc1/telemetry, so both styles coexist on one broker. The broader picture is in the industrial IoT with MQTT guide.
Testing a Gateway Before Rollout
Before connecting a gateway to production data, point it at a test broker and verify topics, payloads and reconnect behaviour:
mosquitto_sub -h broker.connectmq.com -p 1883 -i gw-test-viewer-81 -t "connectmq/demo/gw-test-81/#" -v
Configure the gateway to publish simulated or non-sensitive values under connectmq/demo/gw-test-81/... on the public MQTT test broker, then unplug its network cable for a few minutes and confirm buffered messages arrive in order when you reconnect. Remember that the public area is readable by anyone, so never send real plant data there.
Where the Broker Fits
The gateway is only half the system. The broker it publishes to must handle TLS, authentication, many concurrent subscribers and retained state for every tag. Running that infrastructure yourself means patching, certificate renewal and monitoring. A fully managed MQTT service removes that burden, and options range from shared serverless brokers for pilots to dedicated clusters or brokers deployed in your own cloud account for stricter requirements. If you want to understand the trade-offs of hosting first, see the guide to choosing a cloud MQTT broker, and for deciding how much logic should stay at the edge versus in the cloud, read edge computing vs cloud computing in IIoT.
Get Your Gateways Talking to ConnectMQ
ConnectMQ gives every gateway a TLS endpoint on port 8883, issued credentials bound to its client ID, a live topic explorer and a devices view organised by ISA-95 levels. Create a free Serverless broker at app.connectmq.com, no credit card required, and point your first gateway at it.
Frequently Asked Questions
What is the difference between an IIoT edge gateway and a router?
A router forwards network packets without understanding them. An edge gateway understands industrial protocols, reads values, converts them into meaningful messages and publishes them over MQTT.
Do I need a gateway if my PLC supports MQTT?
Not always. A gateway still helps when you have many legacy devices, need disk-backed buffering, or want to keep broker credentials and internet access off your controllers.
Should the gateway use Sparkplug B?
Use Sparkplug B if your consuming applications support it and you want standardised state management. Use plain JSON if many simple tools need to read the data directly; some plants publish both.
How much data should a gateway buffer?
Size the buffer for the longest outage you want to survive at your normal data rate, with headroom. Report by exception reduces both normal traffic and buffer requirements.
