The safest port on a remote site is the one that is never open. An outbound-only connection is the architecture that makes that possible: the field device reaches out to the cloud, so nothing on the internet can reach in. This guide explains what an outbound-only connection is, how it works, and why cloud SCADA relies on it.
Outbound-Only Connection in one line: An outbound-only connection is a link that is always initiated by the field device reaching out to a server, never by an external party connecting in, so the site needs no open inbound ports or public IP and cannot be reached uninvited from the internet.
The device - a gateway, RTU, or edge unit at the site - opens a connection to the cloud endpoint and keeps it, or reopens it on a schedule to send data. Because NAT and firewalls allow outbound sessions and automatically permit the return traffic that belongs to them, the device receives responses over that same connection without anyone having to open a port. Common forms are polling out over a device-initiated session, an MQTT client publishing to a broker, or an HTTPS or WebSocket tunnel.
The contrast is the legacy model, where a central server dials into each site and every site must forward a port through its firewall to be reachable. That model needs a public IP per site (increasingly unavailable behind carrier NAT) and turns each open port into an attack surface. Outbound-only inverts the direction and removes both problems.
The security upside is direct: a site with no listening inbound services and no forwarded ports presents almost no externally reachable attack surface. There is nothing on the internet to scan, probe, or brute-force. Combined with transport encryption and device authentication, outbound-only connectivity is one of the strongest and simplest hardening measures available for remote OT, and it aligns with modern defense-in-depth guidance.
It is also what makes cloud SCADA practical at scale. Since carriers hide sites behind carrier-grade NAT, a head end cannot connect inbound anyway - so the device must initiate. Merobix is built for exactly this: field devices connect out to the platform, so a whole fleet of cellular wells and pipeline sites is monitored with no inbound ports opened at any location, no static IPs required, and no port-forwarding to maintain.
Because the site opens no inbound ports and has no listening services exposed, there is nothing for an attacker on the internet to scan or connect to. The device initiates every connection, so uninvited inbound access is simply not possible.
NAT and firewalls automatically permit the return traffic that belongs to a session the device started, so responses, commands, and acknowledgments flow back over that same connection - no separate inbound port is needed.
Yes - it is the natural fit. Since carrier NAT gives sites no reachable inbound address, a device-initiated outbound connection is often the only way to link a cellular site to the cloud, which is why cloud SCADA platforms like Merobix are built around it.
Primary references from the standards bodies and regulators that define this topic:
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.