When a remote site sends telemetry across a cellular carrier or the public internet, that data crosses networks nobody controls. A VPN tunnel is how engineers make that untrusted path safe - by wrapping the traffic in encryption so only the two ends can read it. This guide explains what a VPN tunnel is, how it works, and why remote SCADA relies on it.
VPN Tunnel in one line: A VPN tunnel is an encrypted, authenticated connection established across an untrusted network - such as the public internet or a cellular carrier - that encapsulates traffic so it travels privately between two endpoints. In SCADA it lets a remote site and the head end exchange data securely as if they shared a private network.
A VPN tunnel does two things at once: encapsulation and encryption. Encapsulation wraps each original packet inside a new outer packet addressed to the far tunnel endpoint, so the internal addresses and structure are hidden and the traffic can be routed across the public network. Encryption scrambles the payload with keys known only to the two ends, so anyone intercepting it on the way sees ciphertext, not readings or commands. Authentication ensures each end is really who it claims to be, using pre-shared keys or certificates.
The result is a logical private link riding over a shared physical one. Two sites connected by a VPN tunnel behave as though they were on the same private network, even though their traffic actually crosses many hops of untrusted infrastructure. IPsec is the classic protocol suite for this in site-to-site setups; other options include OpenVPN and WireGuard. The choice affects performance and configuration, but the principle - encapsulate, encrypt, authenticate - is the same.
The common SCADA pattern is a site-to-site VPN: a persistent tunnel between the remote site's edge router and a concentrator at the head end, so all field traffic flows encrypted between them. This is often paired with a private APN, giving two reinforcing layers - the APN keeps traffic off the open internet, and the tunnel encrypts whatever does traverse shared links.
How the tunnel is initiated matters for security. A tunnel the head end must reach into means the remote site has to accept inbound connections, which widens its attack surface. An outbound-initiated tunnel, where the field router dials out to the head end and nothing inbound is allowed, is far safer: the site is never directly reachable from the internet, yet a secure channel still exists. Many modern cloud SCADA designs favour this outbound-only model precisely because it removes exposed inbound ports at every remote site.
SCADA protocols were mostly designed for trusted private networks and often carry little or no built-in encryption. Sending them raw across a cellular carrier or the internet would expose readings and, worse, control commands to interception or tampering. A VPN tunnel supplies the confidentiality, integrity, and authentication those protocols lack, without changing the protocols themselves - the tunnel secures the transport underneath.
A cloud SCADA such as Merobix reads field devices over Modbus, DNP3, MQTT, or OPC UA, and a VPN tunnel (or an equivalent outbound, encrypted connection) is what protects that traffic in transit from the site to the cloud. The devices speak their native protocol; the tunnel makes carrying it over public infrastructure safe. A VPN tunnel is not a full security program on its own, but it is a foundational layer for any remote telemetry that leaves a trusted network.
A private APN controls routing - it keeps a cellular SIM's traffic off the public internet on a carrier-controlled network. A VPN tunnel controls confidentiality - it encrypts and authenticates the traffic itself. They address different risks, and many operators use both together for defence in depth.
Because the remote site never has to accept inbound connections from the internet, so it exposes no open ports and cannot be scanned or attacked directly. The field router dials out to the head end to build the tunnel, giving a secure channel without the risk of an internet-reachable site.
Encryption and encapsulation add a small amount of processing overhead and a few extra bytes per packet, which is negligible for typical low-bandwidth SCADA telemetry. The bigger performance factor is the underlying link's latency and bandwidth, not the tunnel itself.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.