The device-gateway-cloud pattern and why gateways exist
In short: In the device-gateway-cloud pattern, simple devices talk to a nearby gateway over a local or low-power link, and the gateway sends secured data to the cloud. Gateways exist because many devices cannot speak IP or TLS themselves. The gateway becomes a key security checkpoint and must be hardened accordingly.
The pattern
Most real IoT systems follow the same shape. Devices in the field send data to a gateway on site. The gateway connects to a cloud or data-centre platform over the internet or a private network. Applications then read from the platform. Some devices, such as Wi-Fi or cellular sensors, skip the gateway and connect straight to the cloud, but the gateway pattern remains the most common for sites with many devices.
Why gateways exist
A tiny sensor running on a coin cell may speak Bluetooth Low Energy, Zigbee or a factory protocol such as Modbus. It cannot run a full IP stack, store certificates or open a TLS session to the cloud. Even devices that could do so might be too numerous to manage individually. A gateway solves this by speaking the local protocol on one side and IP on the other.
- Protocol translation: converts Zigbee, BLE or Modbus into MQTT or HTTPS messages.
- Buffering: keeps readings when the internet link drops and sends them later.
- Filtering and aggregation: sends averages or changes instead of every raw reading.
- Security boundary: holds cloud credentials, encrypts upstream traffic and blocks unexpected inbound connections.
- Local control: runs rules that must work even when the cloud is unreachable.
- Device management: relays firmware updates and configuration to the devices behind it.
Direct-to-cloud vs gateway
| Factor | Direct to cloud | Via gateway |
|---|---|---|
| Device capability | Needs IP and TLS (Wi-Fi, cellular) | Can be very simple |
| Offline operation | Device must buffer itself | Gateway buffers and runs local rules |
| Credentials | One per device in the cloud | Gateway credential plus local pairing |
| Single point of failure | No | Yes, unless gateways are redundant |
Securing the gateway
Because the gateway sees all local traffic and holds cloud credentials, compromising it is very valuable to an attacker. Treat it as a critical server:
- Use a unique identity, ideally an X.509 certificate stored in a secure element or TPM.
- Make only outbound connections to the cloud; do not expose management ports to the internet.
- Enable secure boot and disk encryption, and keep the OS and applications patched.
- Place it in its own network segment, between the device network and the corporate network.
- Send its logs to central monitoring, and alert on configuration changes.
- Plan redundancy if the site cannot tolerate the gateway failing.
Tip: remember the gateway also protects the devices behind it. A sensor that cannot be patched becomes much safer if only the gateway can reach it.
Practice
Give two reasons a BLE sensor would use a gateway rather than connecting directly to the cloud.
Why should the gateway make only outbound connections?
What is a drawback of the gateway pattern?
Key takeaways
- Devices talk to a local gateway, which forwards secured data to the cloud.
- Gateways exist because constrained devices cannot run IP and TLS.
- They translate, buffer, filter, secure, manage and run local rules.
- A gateway is a high-value target: harden it like a server.
- Use outbound-only connections and a dedicated network segment.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.