IIoT · 7 min read · Updated February 2026
IIoT Edge Gateways: Connecting the Factory Floor to the Cloud
Edge gateways bridge OT and IT. What they actually do, why processing at the edge beats sending everything to the cloud, and a specification checklist for choosing one.
Digitalization projects live or die on how cleanly the factory floor connects to higher-level systems. The edge gateway is that bridge — and choosing it well is mostly a matter of asking the right questions.
What an edge gateway does
- Collects data from PLCs, meters and instruments over Modbus, OPC UA, PROFINET or vendor protocols (S7, MELSEC, EtherNet/IP).
- Normalizes and buffers it locally: scaling, timestamps, units, store-and-forward during outages.
- Publishes northbound to IT or cloud systems via MQTT or OPC UA.
- Often runs local logic — threshold alarms, simple calculations, even containers — and secures the boundary with VPN and firewall.
Typical hardware: a compact Linux computer such as the Moxa UC-2112 running an IIoT software stack; a PLC-class controller with IT features such as the WAGO PFC200; or, for remote sites, a cellular gateway such as the OnCell G3150A-LTE in front of a small RTU.
Why edge, not just cloud
Processing at the edge reduces bandwidth (publish changes, not raw scans), adds resilience (store-and-forward during link outages) and keeps latency-sensitive logic on site. It also keeps the PLC out of the internet: the gateway is the only device that talks northbound, which makes the security conversation with IT far simpler.
Specifying a gateway
- Southbound protocols — what do your devices actually speak? Count the Modbus RTU serial devices; they need serial ports or a Modbus gateway.
- Northbound protocol — MQTT (with which payload standard?), OPC UA, or a vendor cloud connector. See OPC UA vs MQTT.
- Data volume — tags, scan rates and retention for store-and-forward; a few hundred tags at one-second scans is trivial, tens of thousands is not.
- Security — VPN, TLS, certificate management, firewall, signed firmware, and a vendor with a real patch cadence (Moxa commits to 10 years of Linux patches on the UC series).
- Environment — temperature range, DIN-rail mounting, 24 V DC with redundant input, fanless.
- Software model — configuration-only tools (Moxa ThingsPro, WAGO Cloud) versus programmable platforms (Node-RED, Docker, CODESYS). Configuration tools deploy faster; programmable platforms adapt longer.
Security is not optional
An edge device sits exactly at the OT/IT boundary that attackers target. Insist on TLS, role-based access, secure boot and regular patches — and place the gateway in a segmented network as described in OT network segmentation.
Start small
One line, 10–30 signals, a broker and a dashboard, 90 days. Prove the data is useful before scaling. Our guide to predictive maintenance with the data you already have shows what to do with the first signals.
We design and commission edge architectures end to end and supply the hardware — talk to an engineer.
Need engineering help with this?
Our engineers apply this to real projects every week — selection, specification, commissioning. Send your question or a part number.
Quick answers
Is an edge gateway the same as a protocol gateway?
No. A protocol gateway (for example Modbus to EtherNet/IP) converts between control protocols on the plant floor. An edge gateway collects data from control devices and publishes it northbound to IT or cloud systems, often with local buffering, logic and security.
Do I need the cloud at all?
Not necessarily. Many customers publish to an on-premise MQTT broker and historian. The edge architecture is the same; only the destination changes.