The protocols that run most SCADA systems were designed decades ago for isolated, trusted networks, and it shows: Modbus, DNP3, and their peers send everything as cleartext with no encryption and no real way to prove a message came from who it claims. That was acceptable when the wire never left a locked room, but it is a serious problem the moment that traffic has to cross a link an attacker could reach. Secure protocol tunneling solves this without rewriting the protocol or replacing the equipment. It wraps the original cleartext traffic inside an encrypted tunnel, so the legacy exchange gets the confidentiality and integrity it never had, while the endpoints keep speaking exactly as they always did.
Secure Protocol Tunneling in one line: Secure protocol tunneling is a technique that wraps a cleartext industrial protocol such as Modbus or DNP3 inside an encrypted transport like TLS or IPsec, so the original traffic crosses an untrusted link protected against eavesdropping and tampering. A small piece of software or a gateway at each end encapsulates the plaintext protocol as it enters the tunnel and unwraps it at the other side, giving the legacy exchange confidentiality and integrity it was never designed to have. Crucially, the SCADA endpoints are untouched: they keep speaking their native protocol, unaware that a secure tunnel now carries it between them.
Legacy industrial protocols carry two weaknesses that matter enormously once traffic leaves a trusted network. The first is a lack of confidentiality: the protocol sends its data in the clear, so anyone who can observe the link can read the values being reported and the commands being sent. The second, and more dangerous, is a lack of integrity and authentication: the protocol has no way to verify that a message is genuine and unmodified, so an attacker positioned on the path can alter a value in transit or inject a command of their own, and the receiving device will act on it as if it were legitimate. These are not bugs; they are simply features the original designers never included because the threat did not exist on an air-gapped bus.
For a long time this was tolerable because the traffic genuinely never crossed anywhere dangerous. Today, that assumption breaks constantly. SCADA traffic now traverses cellular links, radio hops, shared corporate networks, leased circuits, and internet paths to reach remote sites, and every one of those links is a place where an attacker could sit and either read or manipulate the plaintext exchange. A command to open a valve or a report of a tank level, sent unprotected across such a link, is exposed to exactly the eavesdropping and tampering the protocol has no defense against.
The obvious fix, replacing the old protocols with modern secure ones, is usually impractical. The devices at the ends are often embedded controllers with fixed firmware that cannot be changed, the systems have run reliably for years and are risky to disturb, and the cost and downtime of ripping out working equipment to gain encryption is rarely justifiable on its own. What is needed is a way to add the missing protection to the traffic on the wire without altering the devices that generate it, and that is precisely the gap secure tunneling fills.
Secure tunneling works by encapsulation. A component at each end of the untrusted link - a small software wrapper on a host, or a gateway device - sits between the SCADA endpoint and the network. On the sending side, the endpoint emits its normal cleartext protocol to this component, which encrypts the traffic and sends it across the link inside a secure transport. On the receiving side, a matching component decrypts the traffic and hands the original, unchanged protocol to the far endpoint. To the two SCADA devices, nothing has changed; they exchange their native protocol exactly as before, and the encryption happens entirely in the layer between them.
Several transports can provide the tunnel, and the choice depends on the situation. A TLS wrapper, using a tool that sits in front of the application and adds a TLS layer around an otherwise unencrypted connection, is a common and lightweight way to secure a single protocol stream point to point. IPsec builds an encrypted tunnel at the network layer, protecting all traffic between two sites rather than a single stream, which suits a site-to-site link carrying multiple protocols. In each case the principle is identical: the legacy protocol becomes the passenger inside an encrypted envelope, gaining the transport's confidentiality and integrity while remaining untouched itself.
The great virtue of this approach is that it touches nothing that is hard to touch. The controllers, PLCs, and RTUs that would be expensive and risky to modify are left entirely alone, still speaking their original protocol into a local connection that never leaves the trusted side of the tunnel. All the new security lives in the added wrapper components, which can be deployed, updated, and managed without disturbing the control equipment. This separation is what makes tunneling practical to retrofit onto systems that cannot be replaced: the protection is bolted onto the transport, not baked into the devices.
Secure tunneling is especially relevant when legacy field sites connect to a cloud or centrally hosted SCADA system, because that connection is exactly the untrusted, long-distance link the original protocols were never meant to cross. A remote controller speaking cleartext Modbus was designed for a wire in the same building, not for a path that traverses a cellular network and the public internet to reach a platform somewhere else entirely. Wrapping that traffic in a tunnel means the field data and any commands are protected across the whole journey, so the move to remote and cloud monitoring does not come at the cost of exposing plaintext control traffic to everyone along the route.
In this pattern the tunnel typically terminates at the boundary of the field site on one end and at the platform's ingress on the other, so the vulnerable protocol only ever travels in the clear within the physically secured perimeter at each end and is encrypted for the entire distance between them. A platform such as Merobix, ingesting data from remote assets over these links, benefits directly from tunneling because the legacy protocol reaches it with confidentiality and integrity intact, turning an inherently insecure field protocol into something safe to carry across public infrastructure to a central system.
It is worth being clear about what tunneling does and does not do, so it is applied with the right expectations. A tunnel protects the traffic while it is inside the tunnel; it secures the transport, not the endpoints. It does not authenticate the legitimacy of a command that a properly connected but malicious party sends, and it does not defend against a threat that originates inside the trusted zone at either end. Tunneling is therefore one layer among several, the layer that closes the specific and severe gap of plaintext protocols crossing untrusted links, and it works best combined with strong control over who is allowed to establish those tunnels and reach the endpoints in the first place.
Usually because the equipment cannot easily be changed. The controllers, PLCs, and RTUs at the ends often run fixed embedded firmware, the systems have operated reliably for years and are risky to disturb, and the cost and downtime of replacing working equipment purely to gain encryption is hard to justify. Secure tunneling avoids all of that by adding the missing protection to the traffic on the wire while leaving the devices untouched, which is what makes it practical to retrofit onto systems that cannot be replaced.
No, and that is the whole point. The endpoints keep speaking their native cleartext protocol into a local connection that stays on the trusted side of the tunnel. A separate wrapper component or gateway at each end encrypts the traffic as it enters the untrusted link and decrypts it on the far side, so all the new security lives in that added layer. The controllers, PLCs, and RTUs are unaware a secure tunnel now carries their traffic, which is why tunneling can be deployed without disturbing the control equipment.
It protects the traffic while it crosses the untrusted link, giving the plaintext protocol confidentiality against eavesdropping and integrity against tampering for the whole distance inside the tunnel. It does not secure the endpoints themselves: it will not stop a properly connected but malicious party from sending a valid command, and it does not defend against threats originating inside the trusted zone at either end. Tunneling is one layer that closes the specific gap of cleartext protocols on untrusted links, and it works best alongside tight control over who can reach the endpoints.
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.