Why VPNs Fail in OT Environments (and What to Use Instead)

The VPN was a good answer to a 1990s question: how do we extend the corporate network to someone outside the building? Twenty-five years later, it's the default answer to a question it was never designed to answer: how do we let people safely reach industrial control systems?

The record speaks plainly. Exposed VPN gateways headline vulnerability advisories every year, stolen VPN credentials keep appearing as the first step in industrial incident reports, and the most consequential pipeline shutdown in US history began with a single compromised VPN password on an account without MFA. None of these are stories about VPNs being badly configured. They are stories about the VPN model doing exactly what it was designed to do, in an environment where that design is the vulnerability.

Here is why the model fails in OT, why jump servers don't rescue it, and what to evaluate in a VPN alternative.

Five Structural Failures of VPNs in OT

1. A VPN grants a network, not a permission

VPN authentication answers one question, "May this credential connect?", and then places the user on a network segment. Everything reachable from that segment is now accessible to the user and to whoever compromised the user. In OT, where networks are notoriously flat, that means a technician's tunnel intended for one compressor can see the SCADA servers, the historians, and every PLC on the segment. Lateral movement isn't a flaw the attacker introduces; the VPN provides it as a feature.

2. The gateway advertises itself to the Internet

A VPN concentrator must listen publicly to be useful. That makes it enumerable: internet scanners index every VPN portal on earth, continuously, and attackers move within hours of each new gateway CVE. Your remote access system should not be the most discoverable thing you own, yet for most industrial operators, it is precisely that.

3. Credentials are the product

Passwords get phished, reused, stuffed, and sold. Adding OTP-based 2FA helps until attackers phish the OTP too. The VPN model cannot escape credentials because credentials are its unit of trust. In an era of AI-generated phishing that is indistinguishable from legitimate mail, any access system whose security reduces to "will a human be fooled today?" is a standing bet you eventually lose.

4. It can't speak for devices that can't defend themselves

VPNs assume competent endpoints on both sides. But the destination in OT is often a controller with no authentication, a default password it has had since 2009, or a protocol with no concept of identity. Once the tunnel lands on the segment, nothing further protects the device. The security perimeter ends exactly where the risk begins.

5. Operational friction guarantees workarounds

Client software conflicts with vendor tooling, split-tunnel policies break site connectivity, and password resets stall a 2 a.m. emergency session. So people work around it: the cellular modem in the cabinet, the TeamViewer install, the shared account. Every workaround is invisible to security. A control that operates routes around is worse than no control, because it produces confidence without protection.

Don't Jump Servers Fix This?

Jump servers (bastion hosts) try to patch the VPN model by forcing sessions through a monitored middle box. They add real value, session recording, a choke point, but inherit the same structural problems: the jump server is itself a discoverable, high-value target; it authenticates with credentials; its shared accounts blur accountability; and once through it, the user typically lands on the same flat network. Concentrating all access through one hardened host also concentrates all risk in it; when the jump server falls, everything behind it falls at once.

What a Real VPN Alternative Looks Like

Evaluate any VPN alternative for OT against five properties:

Invisible infrastructure. No listening ports for unauthorized parties, nothing for scanners to index. If the access system can be discovered, it will be attacked.

No credentials to steal. Passwordless, device-bound, phishing-resistant authentication. The goal is not stronger passwords; it is no passwords.

Per-device, per-protocol access. Authorization should name the destination: this user, this PLC, this protocol, this window, not a subnet.

Nothing is installed on OT devices. Legacy controllers can't run agents; the control layer must wrap around them.

Faster than the workaround. If authorized access isn't easier than the cellular modem in the cabinet, the modem wins.

This is the model BlastWave built BlastShield around: network cloaking makes the access layer and the assets behind it invisible; passwordless MFA removes the credential class entirely; and software-defined microsegmentation turns "access" into a per-device permission rather than a network grant. It deploys as an overlay, with no changes to the OT devices, and it's fast enough that one customer replaced their legacy VPN with full zero trust access in about ten minutes. (Architecture details: OT Secure Remote Access. Comparison shopping: Best Secure Remote Access Solutions for OT.)

Migration Without a Cliff

Replacing a VPN is not a leap. The practical sequence: run the zero trust overlay in parallel; move the riskiest populations first, vendors and third parties, then remote employees (vendor access guide here); cloak the assets behind the new access layer; then retire the VPN concentrator, removing its attack surface from the internet for good. Each step reduces risk independently; none requires downtime.