What an IoT Gateway Actually Does (and How to Pick One)

An IoT gateway is the box that sits between your machines and your network, translating industrial protocols into something modern systems can consume, buffering data when the connection drops, and holding the security boundary between the plant floor and everything else. It is the least glamorous component in a monitoring system and the one most likely to determine whether the whole thing works. Pick it well and you'll forget it exists. Pick it badly and you'll meet it often.

What Does an IoT Gateway Actually Do?

Four jobs, in order of importance.

First, protocol translation. Your equipment speaks Modbus RTU over RS-485, Modbus TCP, Ethernet/IP, PROFINET, a proprietary serial dialect, or nothing at all beyond a dry contact. Your dashboards and databases speak MQTT, HTTPS, and SQL. The gateway is the interpreter. It polls the machine side on machine terms and publishes on IT terms.

Second, buffering. Networks fail. A gateway worth owning writes readings to local storage and forwards them when connectivity returns, so an outage costs you latency instead of history.

Third, security. The gateway terminates the plant-floor world and originates the network world. Done right, nothing behind it is exposed: the gateway makes outbound TLS connections only, and the crusty unpatched controller it polls never touches the internet.

Fourth, edge logic. Deadbanding, unit scaling, alarm evaluation, sometimes a local dashboard. How much logic belongs here versus upstream is an architecture choice we walk through in our piece on edge computing for manufacturers.

Protocol Translation: The Core Job

This is where gateways earn their keep, and where spec sheets mislead.

A vendor page listing "200+ protocols" tells you little. What matters is whether the gateway handles your protocols, at your revision, with your equipment's quirks. Modbus is nominally simple, yet real devices differ on register addressing offsets, byte order within 32-bit values, and how they behave when polled too fast. A good gateway exposes knobs for all of that. A bad one works in the demo and falls over on the actual machine.

Physical interfaces matter as much as software. Count what you need: RS-485 ports (isolated ones, ideally), RS-232 for older serial equipment, digital inputs for dry contacts, analog inputs if you're wiring 4-20 mA sensors directly, and Ethernet ports, plural, if you want the gateway to bridge an isolated machine network to the plant LAN. Retrofitting a gateway that's one serial port short is a miserable way to save eighty dollars. The wiring side of this, termination resistors, biasing, grounding, deserves its own discussion, and we've written one on connecting legacy equipment over Modbus and serial.

On the northbound side, MQTT has become the default for good reason. Compared with HTTP polling, it's push-based, so a value changes and arrives in milliseconds rather than at the next poll interval. It's lightweight, which matters on cellular. And its publish-subscribe model means adding a new consumer of the data requires no gateway changes at all. HTTP still has a place for simple integrations, but if a gateway's MQTT support feels like an afterthought, keep shopping.

Store-and-Forward: The Feature You Should Refuse to Skip

Here's a scenario that plays out constantly. A monitoring system gets installed, works beautifully for two months, then the plant's internet goes down for six hours on the night shift. Monday morning, someone asks why the OEE report has a hole in it. If the gateway buffered to local flash and back-filled on reconnect, the answer is "it doesn't." If it didn't, that data is gone permanently, and trust in the system goes with it.

When evaluating store-and-forward, ask specific questions. Where is the buffer, in RAM or on persistent storage? RAM buffers vanish on power loss, which tends to coincide with the outages you're buffering against. How large is it, in hours of your actual data rate rather than megabytes? Does back-fill preserve original timestamps? Some naive implementations replay old data with current timestamps, which quietly corrupts your history. Does the buffer survive a firmware update mid-outage?

A related detail: clock discipline. Buffered data is only as good as its timestamps, so the gateway needs a battery-backed real-time clock or reliable NTP, preferably both. A gateway that boots after a power cut believing it's 1970 will label six hours of perfectly good readings with garbage.

How Is an IoT Gateway Secured?

Treat the gateway as the security perimeter, because that's what it is.

The baseline: all upstream communication over TLS, with certificate validation actually enabled, not the "disable verification" checkbox that demo configurations love. Per-device credentials or client certificates, so one compromised or decommissioned unit can be revoked without touching the fleet. No inbound ports open to the internet, ever; remote access, when needed, should go through an outbound-initiated tunnel or VPN.

Then the questions that separate serious vendors from the rest. How are firmware updates delivered and are they signed? What's the update cadence, and how long is the product supported? Is there a real changelog? A gateway is a small Linux computer on your network for the next decade; you are buying the vendor's security practice as much as the hardware.

OTA update capability deserves particular scrutiny. With three gateways, walking around with a laptop is tolerable. With thirty, across two sites, it isn't. Look for remote, staged, signed updates with automatic rollback if the new firmware fails to boot. The rollback part is not optional. An OTA mechanism without it will eventually brick a device that's a four-hour drive away.

Picking One: A Practical Checklist

Beyond protocols, buffering, and security, a few filters eliminate most bad choices quickly.

• Physical fit: DIN-rail mounting, 10-30 V DC power input so it runs from the panel's existing 24 V supply, and a genuine operating temperature range (-20 to +60 °C covers most plants; check yours). Fanless, always.
• Longevity: an advertised product lifecycle of five-plus years, firmware support commitments in writing, and a vendor old enough to have kept such promises before.
• Openness: can you get your data out in standard formats without a mandatory cloud subscription? Gateways that only talk to their maker's platform are rent, not equipment.
• Manageability: fleet-level configuration and monitoring, so gateway number twelve costs minutes, not an afternoon.

Price ranges surprise people in both directions. Capable industrial gateways run from roughly two hundred to two thousand dollars. The expensive ones aren't automatically better; the cheap ones aren't automatically junk. Match the spec to the job. And for one-off or unusual situations, a hardened single-board computer running open-source gateway software is sometimes the right answer, provided someone owns its care and feeding.

The gateway also has to fit systems you already run: your historian, your ERP, your maintenance software. That integration work, deciding what data lands where and in what shape, is where projects succeed or stall, and it's the heart of our systems integration practice.

FAQ

Do I need an IoT gateway if my PLCs already have Ethernet?

Often yes. Direct PLC-to-cloud connections mean exposing controllers to the network, burdening them with communication tasks, and losing buffering. A gateway isolates the PLC, handles TLS and store-and-forward, and gives you one managed point of egress instead of many.

What's the difference between an IoT gateway and an edge computer?

Mostly workload. A gateway focuses on protocol translation and data movement; an edge computer adds general compute for analytics, databases, or vision inference. The categories blur, and plenty of installations start with a gateway and grow edge workloads on the same box until it's time to split them.

MQTT or HTTP for gateway-to-cloud communication?

MQTT for continuous telemetry: it's push-based, efficient over cellular, and reconnects gracefully with queued messages. HTTP remains fine for occasional bulk uploads or simple integrations with existing web APIs. Many gateways sensibly do both.

How many machines can one gateway handle?

For typical polling workloads, one mid-range gateway comfortably fronts ten to thirty machines; the limits are usually serial port count and polling intervals rather than CPU. High-frequency data such as raw vibration changes the math, so size against your actual sample rates.

Choosing a gateway is easier when someone has already been burned by the wrong ones. Willowark specifies, configures, and deploys gateways as part of complete IoT and smart systems for manufacturers. If you're staring at a shortlist and a spec sheet, talk to us before you buy.