Why Standard VPN Fails
in Industrial Environments

VPN makes sense in the enterprise world. A central server sits inside the corporate network, engineers connect from outside, and a full tunnel brings them onto the LAN as if they were physically present. The model is well understood, widely deployed, and thoroughly supported by IT security policy.

The problem is that this model carries a set of assumptions — about who controls the network, who manages the server, who configures the firewall — that simply do not hold in industrial environments. A machine builder shipping equipment to a customer factory operates in an entirely different reality. And in that reality, standard VPN fails reliably, predictably, and expensively.

The Customer's IT Department Will Say No

A traditional VPN requires something on the customer's network: an open port, a forwarding rule, or at minimum a VPN client that connects out to your server. Any of these requires the cooperation of the customer's IT department.

That cooperation is rarely forthcoming. Corporate IT security policies typically prohibit third-party VPN access to internal networks. Even when the policy technically allows it, the process to get approval — security review, ticket, network change request, change control window — takes weeks. By the time the firewall rule is approved, the machine has been sitting idle and the customer is already unhappy.

And if the machine gets moved to a different facility — which happens — the process starts again from scratch.

NAT and Dynamic IP Make It Unreliable

Even when IT cooperates, the network topology fights you. Most factory internet connections sit behind NAT — the machine has a private IP address, not a public one. To reach it from outside, you need port forwarding configured on the gateway, pointing to the machine's local address.

That local address is usually dynamic. The factory router assigns it via DHCP. If the machine reboots, it may get a different IP. Now the port forwarding rule points to nothing, and the VPN stops working — silently, until someone notices during a live service call.

You can work around this with static IP reservations and DDNS, but both require more IT involvement on the customer side — and more things to go wrong.

VPN Opens Too Much

This is the reason careful IT departments block third-party VPN access even when asked nicely. A full-tunnel VPN does not give you access to one machine — it gives you access to the network segment that machine lives on.

Once connected, a service engineer can see other PLCs, other machines, SCADA servers, network switches — everything on that subnet. This is not theoretical. It happens on every VPN session, and a customer's IT security team knows it.

The result is a deadlock: the people who need remote access can't get IT approval because IT correctly identifies the security risk. So they end up either skipping remote access entirely, or using unauthorised workarounds that are genuinely dangerous. Neither is a good outcome.

Mobile Networks Break It Entirely

A growing number of industrial machines and remote installations use LTE or 4G as their primary internet connection. Here, standard VPN doesn't just struggle — it frequently cannot establish a connection at all.

The reason is Carrier-Grade NAT (CGNAT). Mobile operators use CGNAT to share a single public IP address across thousands of devices. This means there is no public IP address pointing to your device — there is no way to initiate an inbound connection to it whatsoever.

Even when a connection does establish over mobile, VPN tunnels are sensitive to IP address changes that happen when the device hands off between cell towers. A session that's been running for an hour can drop instantly as the device moves — and reconnecting takes minutes, not seconds.

VPN Is Not the Wrong Technology — It's in the Wrong Context

VPN solves the right problem in the enterprise: giving remote employees access to internal resources they are already authorised to reach. It assumes a controlled environment, cooperative IT administration, and stable infrastructure.

OT remote access has none of those conditions. The machine is on a customer's network. The IT team works for the customer, not the machine builder. The connection needs to work from day one, without configuration at the remote end, on any internet connection including mobile. That requires an outbound-only, device-level connection — not a network-level tunnel.