3 Sept 2026 · 8 min read
The tunnel was never the hard part
security · scada · practice
Pick nine o'clock tonight. Name every person and every company who could open a connection to a controller in your plant at that hour.
Not who is authorised. Not who has a good reason. Who could.
Almost nobody can answer that, and it is not because anyone was careless. Answering it properly means reading three or four firewalls, the local accounts on a jump server, a support contract signed by somebody who has since left, a cellular modem that arrived fitted to a machine, and one contractor's laptop. Five places, five owners, and not one of them wrong on its own.
The industry's own measurements say the same thing more bluntly. Looking at more than fifty thousand remote-access-enabled devices on industrial networks, Claroty's Team82 found 55% of environments running four or more separate remote access tools, and a third running six or more. Around 79% had at least two tools that were never built for this job at all: no session recording, no roles, in many cases no second factor.
HOW MANY WAYS IN, PER SITE
Nobody chose six. They arrived one at a time, each with a machine or a contract, each perfectly defensible on the day. This is the same slow renovation that turns an air gap into a diagram nobody has revisited, and it produces the same result: a plant whose doors cannot be listed by the people responsible for them.
We kept buying tunnels
Strip those tools down and they are all the same product underneath: a way to make an encrypted pipe between two places. We have been buying that product since the late nineties, and buying it over and over, because every vendor brings their own.
The awkward thing is that the encryption stopped being difficult a while ago. WireGuard, in the mainline Linux kernel since 2020, is roughly 4,000 lines of code. The IPsec implementation it competes with runs to several hundred thousand; OpenVPN is over a hundred thousand and leans on OpenSSL besides. Small enough to read was the explicit design goal, and security researchers now do it in about a day.
So the hardest part of the problem, whether the traffic is private and whether the far end is who it claims to be, is now a component one person could review over a long afternoon. It costs nothing.
WHAT ACTUALLY GOT SOLVED
in 1998
The part that never shrank is the list. Who may reach what, for how long, on whose authority, and how you would know afterwards. That is exactly as hard as it was in 1999. It is also the part that has never really had a product on the plant floor, which is why every site solves it with a spreadsheet and a shared password.
So look at what the new ones are actually selling
Tailscale is the well-known one, and how little of it is network engineering is the interesting part. The tunnel is WireGuard: free, somebody else's, unmodified. What you pay for is the layer above. Identity, key distribution, getting two machines behind separate routers to find each other, and the policy deciding which of them may speak at all.
That is a management product wearing a network product's clothes, which is exactly why it is worth an OT engineer's attention. The plant's problem was never a weak tunnel. Two consequences matter more than the marketing does.
The door dials out
Conventional remote access needs something in the plant that listens: a forwarded port, a concentrator with a public address, a modem that answers. Whatever listens is permanent, it is what gets scanned all day, and it outlives the project that justified it by years.
On a mesh overlay both ends dial out and meet in the middle. Nothing inside the fence accepts an unsolicited connection, so the site firewall carries no inbound rule for remote support at all.
WHICH DIRECTION THE CONNECTION STARTS
That is the security property worth having, and notice that it has nothing to do with cryptography. It is about which direction the connection starts.
The list becomes a file, and the file can fail a test
The second consequence is that "who may reach what" collapses into one document
instead of being smeared across five devices. Machines carry tags rather than
addresses, so tag:vendor-drives may reach tag:line-3-drive and nothing else,
and the whole policy is a text file with a history showing who widened what, when.
It is the same move that turned
gateway configuration into something you can review and rebuild from,
applied to the one thing in the plant nobody ever wrote down.
Then the part I think is genuinely new for our industry: that file can carry assertions about itself. You write down, permanently, that the vendor tag must never reach anything in the safety zone, and a policy change that breaks the assertion is rejected. Not logged, not flagged in a quarterly review. Refused at the moment somebody tries to save it.
A NETWORK RULE WITH A TEST ATTACHED
A network rule with a test attached is not a small thing. The normal way a plant finds out that a change opened something is that a person notices months later, usually while looking for something else. It also lands neatly on what IEC 62443 already asks for: groupings by consequence rather than by cable. A tag is a zone you can enforce, and a grant between two tags is far closer to a conduit than any VLAN ever was.
A job in Seville
A drive on a bottling line in Seville faults on a Tuesday. The vendor's specialist is in Leipzig and needs about two hours with it.
How it usually goes: an account on the shared jump server, the same one four other vendors use, password sitting in an email thread from 2022. The VPN profile routes them to the whole cell, because that is the only granularity the profile has. The job finishes. The access does not, because removing it would first require somebody to find it.
The same job on an overlay: the specialist's laptop joins as a temporary node authorised for that window, and deletes itself when they disconnect. One line goes into the policy file saying the vendor tag may reach that one drive on that one port. Not the cell, not the HMI, not the historian. The session records to a machine in Seville that you own. When the window closes the node is gone, and withdrawing access means deleting a line in front of a reviewer, not raising a change request against a firewall nobody wants to touch.
WHAT IS STILL VALID ON FRIDAY
The traffic was not badly encrypted before. The difference is that this time, six months later, you can still say exactly what happened, and the door is not still standing open.
Two places it falls over
A PLC will never run an agent. All of the above assumes software on the endpoint, and your controllers, drives, meters and older panels are never going to have it. The standard answer is a subnet router: one machine on the overlay that forwards to a range of plant addresses. It works, and it quietly hands back a good part of what you came for, because per-device identity stops at that router. Behind it you are back to addresses and ports, and a wide enough range is a flat VPN with better branding.
WHERE PER-DEVICE POLICY ACTUALLY ENDS
Keep the routed ranges deliberately narrow, put the router as close to the equipment as the cabinet allows, and be honest on the drawing about where per-device policy ends and plain routing begins.
Administration depends on a server you do not own. Tailscale documents this clearly, to its credit. If its coordination service is unreachable, existing connections keep running, peers stay cached, and the rules already on each device go on being enforced. What stops is change: no new devices, no refreshed keys, no rule updates, and no revocation. Devices only drift apart as keys expire, which by default takes months rather than minutes.
A dropped link does not stop the plant, then, but it freezes your ability to administer it, and there is a version of a bad day where cutting somebody off is the urgent thing. That is the same dependency question as whether the plant can still let you in when the link is down, and it takes the same answer: federation flows down, dependency never flows up. If somebody else's control server is unacceptable, an open-source implementation called Headscale speaks the same protocol to unmodified clients. Read its own documentation first: it scopes itself at personal and small-organisation use, not a plant estate.
And the obvious one: none of this is a certified industrial product. It is not an answer to an assessor who wants a demonstrated zone boundary, and it does not make a Modbus controller authenticate anybody. It constrains who can reach the controller. What happens after they arrive is unchanged.
The thing to actually go and do
None of this needs a procurement exercise to test. Pick one machine a vendor supported in the last twelve months. Write down every path that reaches it today and who holds the credential for each. Then find the date each of those paths was supposed to close.
If the first list takes more than an afternoon and the second is mostly blank, the tunnel was never your problem. Nobody is going to break the encryption. They are going to walk through a door somebody opened for a good reason in 2021, that nobody has ever been asked to close.
What happens after somebody does reach the controller is a separate and worse question — a seven-agency advisory describes project files stolen with the vendor's own software, reusable logic edited, and shutdown and alarm logic disabled: they didn't turn anything off.
Where remote access sits among the other walls a plant needs, and why the stricter plants allow it only for troubleshooting and emergencies: one firewall is not segmentation.
Keep reading
Newsletter
New essays, by email.
SCADA, cloud, AI, and the plant floor — a short email when something new is published. No noise, unsubscribe anytime.