Every cloud SCADA deployment has one box that touches both worlds: the edge gateway that polls your PLCs on the plant network and pushes data to the platform. Compromise that box and an attacker is inside your OT network with a trusted data path outward. Yet most buyers evaluate gateways on protocol support and price, never asking how the device proves its identity, how updates reach it, or what happens to its credentials when it is stolen from an unmanned site. This guide covers the five properties that make an edge gateway defensible - unique device identity, cryptographically signed telemetry, verified updates, store-and-forward durability, and outbound-only connectivity - and the questions that expose vendors who skipped them.
Part of our SCADA security guide library - 60+ articles on securing industrial operations.
An edge gateway lives in the worst security environment in your company. It sits in unmanned compressor stations, remote well pads, and dusty control cabinets. It is physically accessible to contractors and, at remote sites, to anyone with bolt cutters. It speaks legacy protocols - Modbus, DNP3, BACnet - that have no authentication of their own, a gap documented at length in the NIST SP 800-82 Rev. 3 guide to OT security. And it holds credentials to a cloud platform that aggregates data from your entire operation.
That combination makes the gateway the natural pivot point for an attacker. Steal one and you may harvest credentials that work everywhere. Poison its update channel and you have code execution inside the OT network at every site that installs the update. Spoof its identity and you can feed fabricated process data into the historian and dashboards your operators trust. Each of these attacks has a specific architectural countermeasure, and each countermeasure is either designed in from the start or bolted on badly later.
The good news for buyers: gateway security is unusually easy to evaluate. Unlike an opaque cloud backend, the properties that matter - identity model, signing, update verification, connection direction - are concrete, yes-or-no questions a vendor either answers crisply or dodges. This post gives you the list. For the network-architecture side of the same story, see our guide to securing SCADA on OT networks.
The foundational rule of fleet security is that no two devices share a secret - the same unique-credentials baseline set by CISA's Cross-Sector Cybersecurity Performance Goals. It sounds obvious, but shared broker passwords and copy-pasted API tokens remain common in industrial IoT deployments, because they are easy: flash the same image to fifty gateways and ship them. The cost appears later. When a shared credential leaks - from a stolen device, a contractor's laptop, or a config backup in the wrong S3 bucket - you cannot revoke it without taking the whole fleet offline, so in practice nobody revokes it at all.
A defensible identity model has four parts:
Merobix implements this model directly: every gateway goes through unique device registration with its own credentials, and each device generates its own Ed25519 signing identity - a modern elliptic-curve keypair, standardized as EdDSA in RFC 8032, created on the device, so the private key never transits the network and never exists in a vendor database that could be breached. The platform additionally checks site ownership before any operational action, so even a validly credentialed device cannot act outside the site it is bound to.
Transport encryption is necessary but not sufficient. TLS protects data in motion between two endpoints, but it does not prove which device produced the data, and it does nothing once an attacker holds valid broker credentials. In an unsigned architecture, anyone who obtains MQTT credentials - from a stolen gateway, a leaked config file, or a misconfigured broker - can publish plausible-looking process values: a tank level that reads normal while it overflows, a pressure that reads flat while it climbs.
Message-level signing closes that gap. In the Merobix architecture, telemetry travels in signed envelopes: each batch is signed with the device's Ed25519 private key and carries sequence numbers, timestamps, sample IDs, and payload digests. The platform verifies the signature against the registered device identity and checks sequence continuity before accepting the data, which means it can detect forged readings, tampered payloads, and replayed traffic - an attacker re-transmitting yesterday's healthy data to mask today's event. Accepted telemetry is written durably before historian processing begins, so a crash mid-pipeline does not silently drop readings.
Merobix is also building toward mandatory signed telemetry across every ingestion path, including a signing migration for legacy gateway fleets - because a signing scheme only delivers its full value once unsigned paths stop being accepted. When you evaluate vendors, ask that exact question: is signing enforced, or merely supported? The deep dive on this topic is our companion post on telemetry integrity and replay protection.
Connection direction is the single most consequential gateway design decision. A gateway that listens for inbound connections forces you to open firewall ports from less-trusted zones into your OT network - and internet-exposed industrial ports are indexed by scanning services within hours. A gateway that only initiates outbound TLS connections lets your OT firewall deny all inbound traffic permanently: there is nothing listening, nothing to scan, nothing to exploit remotely.
The Merobix gateway works exclusively on this model. It polls PLCs, RTUs, and flow computers locally - drivers for the major industrial protocols (Modbus, DNP3, OPC UA, EtherNet/IP, Siemens S7, and MQTT), including Modbus RTU/TCP, OPC-UA, MQTT, DNP3, BACnet/IP, EtherNet/IP, and HTTP - and pushes encrypted data outbound. No inbound rules, no static IP requirement, no VPN concentrator accumulating CVEs. The same posture works identically over plant ethernet or a cellular modem, which matters for distributed operations where sites live behind carrier-grade NAT. For organizations weighing this model against on-premise alternatives, our cloud vs on-premise comparison covers the trade-offs in full.
Many "IoT gateways" are a headless Linux computer with a data-forwarding script - functional, but carrying none of the properties above. The comparison that matters:
| Property | Generic Edge Box | Security-First Gateway |
|---|---|---|
| Device identity | Shared or hand-managed credentials; often a password in a config file | Unique per-device registration; device-generated Ed25519 keypair; individual revocation |
| Telemetry integrity | TLS only; any credential holder can inject data | Signed envelopes with sequence numbers, digests, and replay detection |
| Software updates | Manual SSH sessions or unverified pulls from a repo | Signed artifacts, verified before install; versioned installs with atomic activation and rollback on the roadmap |
| Connectivity | Often listens on inbound ports for configuration or polling | Outbound-only TLS; zero inbound firewall rules |
| Outage behavior | Data lost or dependent on ad-hoc scripts | Store-and-forward buffering; durable acceptance on the platform side |
| Control path | Writes pass through unchecked | Control-tag authorization and setpoint bounds checking before dispatch |
The most valuable thing an attacker can compromise is not your gateway - it is your gateway's update mechanism. A poisoned update is code execution on every device that installs it, delivered with the fleet's full trust. This is precisely how the SolarWinds supply-chain compromise - the subject of CISA advisory AA20-352A - reached as many as 18,000 organizations that downloaded the trojanized update, and edge devices in unmanned locations are an even softer target because nobody is watching them install anything.
The countermeasure is end-to-end artifact verification. Merobix ships signed gateway artifacts, and each gateway verifies the signature before installing an update - so a compromised network path, DNS hijack, or malicious mirror cannot deliver code the vendor did not produce. On the roadmap, Merobix is building immutable, versioned gateway installs with atomic activation and rollback, with each installed version's provenance bound to the corresponding cloud release: an update either fully activates or cleanly rolls back, and you can always answer "exactly what code is running at site 47, and where did it come from?" The full supply-chain picture - from the vendor's build server to your cabinet - is covered in our software supply chain security guide for SCADA buyers.
Buyer questions that separate real update security from hand-waving:
Connectivity at industrial sites fails routinely - cellular dead zones, ISP outages, lightning. A gateway that drops data during outages creates two problems. The operational one is obvious: gaps in the historian, missed compliance records, blind spots in trend analysis. The security one is subtler: an attacker who can cause a brief outage can erase the evidence window. Denial of service becomes denial of forensics.
A hardened gateway treats the network as unreliable by design. Merobix gateways keep polling during outages and buffer readings in store-and-forward storage, transmitting the backlog when connectivity returns; sequence numbers and timestamps in the signed envelopes let the platform reassemble the record in order and detect anything missing. On the receiving side, telemetry is accepted durably before historian processing, so a platform-side failure cannot silently discard data either. When evaluating vendors, ask for specifics: how much buffer, measured in hours at your tag count and poll rate, and what happens when the buffer fills - oldest data dropped, newest dropped, or backpressure?
Everything above concerns data flowing out. The stakes rise when the gateway carries commands flowing in - setpoint changes, starts and stops. A secure architecture treats every write as guilty until proven authorized: only explicitly configured writable tags accept commands at all, each command is checked against the requesting user's role and the tag's configured setpoint bounds before dispatch, idempotency protection prevents a retried message from executing twice, and commands move through explicit states - pending, applied, verified, failed, expired - with read-back verification where the protocol supports it. Merobix enforces this chain end to end, with audit records for every command and acknowledgement. If remote control is in scope for your deployment, it deserves its own evaluation pass - our guide to remote control security and safe setpoint writes covers it in depth.
Key takeaway: A defensible edge gateway rests on three cryptographic facts - the device can prove who it is (unique registered identity), prove its data is genuine (signed telemetry with replay detection), and prove its software is authentic (signature-verified updates) - plus one architectural fact: it never listens for inbound connections. Any vendor missing one of the four has an open flank. The Merobix gateway architecture is documented in detail on the security page, and you can walk through it live in a guided demo.
Fifteen minutes on these questions tells you more than any datasheet. Vendors who built the architecture answer instantly; vendors who did not will talk about their firewall. For the complete evaluation framework across all control families, start with our cloud SCADA security checklist.
An edge gateway is the small industrial computer that sits inside the OT network, polls PLCs, RTUs, and instruments over local protocols such as Modbus, OPC-UA, EtherNet/IP, and DNP3, and pushes that data to the SCADA platform over an encrypted outbound connection. Because it bridges the plant network and the outside world, its security posture - device identity, update integrity, and connection direction - largely determines the security of the whole deployment.
Shared credentials mean one leaked key compromises every site, and you cannot revoke a single device without breaking the rest of the fleet. With unique per-device registration and credentials, a stolen gateway can be revoked individually, telemetry can be attributed to a specific piece of hardware, and an attacker who compromises one site gains nothing usable elsewhere. Merobix registers each gateway with unique credentials and a device-generated Ed25519 signing identity whose private key never leaves the device.
A signed telemetry envelope wraps each batch of process data with a cryptographic signature from the device's private key, plus sequence numbers, timestamps, sample IDs, and payload digests. The platform verifies the signature and checks the sequence before accepting the data, which lets it detect forged readings, tampered values, and replayed traffic. Without signing, anyone who obtains broker credentials can inject plausible-looking process data into your historian and dashboards.
The update channel is an attack channel: if an attacker can push code to your gateways, they own your OT network. Signed update artifacts let the gateway cryptographically verify that an update was produced by the vendor before installing it, so a compromised network path or mirror cannot deliver malicious code. Merobix ships signed gateway artifacts with update verification today and is building immutable, versioned gateway installs with atomic activation and rollback bound to the cloud release.
A well-designed gateway keeps polling locally and buffers readings in store-and-forward storage, then transmits the backlog when connectivity returns, so the historian has no gaps. This matters for security as well as operations: an attacker who can cause a short outage should not be able to erase the evidence window. Merobix gateways buffer during outages and the platform accepts telemetry durably before historian processing, so data survives interruptions on either side.
Unique device identity, Ed25519-signed telemetry, verified updates, and zero inbound firewall ports - walk through the architecture with an engineer on your own site's terms.