What Is an Outbound-Only Connection?

Back to Blog

How an Outbound-Only Connection Works

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.

Why It Matters for Security and Cloud SCADA

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.

What the Site Firewall Should Allow

Outbound-only does not mean unrestricted outbound. The hardened version of this architecture pairs no-inbound with a tight egress allowlist: the gateway may reach only its named platform endpoints on their expected ports - commonly TCP 443 for HTTPS and WebSocket transports, or TCP 8883 for MQTT over TLS - plus whatever DNS and NTP the site design calls for, and everything else is denied in both directions. The exact endpoints are deployment-specific and belong in the site's firewall documentation, not in someone's memory.

The reason to bother is containment. If a field device is ever compromised, an open egress policy hands it a clear path to arbitrary destinations; a scoped allowlist reduces that to the handful of endpoints you already trust and monitor. Combine it with TLS on every session and per-device credentials or certificates - mutual authentication where the platform supports it - so the receiving end can tell exactly which site is connecting and a credential stolen from one site does not unlock the rest of the fleet.

How Commands Travel When Nothing Dials In

Supervisory writes ride the session the device opened. The platform queues the command, delivers it over the established connection, and the device acknowledges completion. That has a sharp consequence: when the session is down, there is no command path at all. For security posture that is a feature - the site is unreachable when disconnected - but it means remote writes must be engineered as best-effort, with explicit state (queued, delivered, confirmed) and timeouts, never fire-and-forget.

It also enforces a healthy division of labor. Anything protective - trips, interlocks, shutdown logic - lives in the local controller and never depends on the cloud path, per the site's engineering and procedures. The outbound link carries monitoring, setpoint adjustments, and non-critical commands, so a link outage degrades visibility, not safety. A site where a dropped session could create a hazard has a design error, not a connectivity problem.

Keepalives, Carrier NAT, and Reconnects

Carrier-grade NAT keeps a session binding alive only while traffic flows; idle bindings are dropped without notice. Devices therefore send periodic keepalives to hold the mapping open, and the tuning matters: too long an interval and sessions die silently - the device believes it is connected while the platform sees it offline until the next reconnect - while too short an interval wastes cellular data. The right interval varies by carrier and is set per the gateway's documentation.

Reconnect behavior deserves the same scrutiny. Well-behaved gateways back off progressively with random jitter, so a regional cellular outage does not end with an entire fleet hammering the platform in the same second. During the outage the device buffers readings locally and backfills on reconnect, so the historian shows a continuous trend rather than a hole. When evaluating any gateway, the outage-and-recovery story deserves more attention than the steady-state one.

An Audit Checklist for No Inbound Ports

Claiming outbound-only and verifying it are different things. A periodic check, carried out per the site's security procedures:

1. Review firewall and router configuration for port forwards, DMZ-host rules, and UPnP - the quiet ways inbound paths reappear.
2. Inventory listening services on the gateway itself; disable WAN-facing web interfaces and protocol servers such as a Modbus TCP slave, or bind them to the LAN side only.
3. Where the site has a public address, run an authorized external port scan and compare the result to the intent: nothing should answer.
4. Confirm TLS with certificate validation on the outbound session, and mutual authentication where supported.
5. Confirm factory-default credentials are gone from every reachable device.
6. Repeat after firmware updates and configuration changes, which can silently re-enable services.

Fold the check into the site's broader reviews - the cloud SCADA security checklist covers the platform side of the same ground, and cellular SCADA gateway security goes deeper on hardening the device that holds the outbound session.

Frequently Asked Questions

Sources & Further Reading

Primary references from the standards bodies and regulators that define this topic:

• Guide to Operational Technology (OT) Security (SP 800-82 Rev. 3) - NIST
• Cybersecurity Best Practices for Industrial Control Systems - CISA