Migrating Off Legacy VPNs and Jump Hosts: A Do-No-Harm Cutover Plan for OT

Key takeaway: Legacy VPN-and-jump-host stacks create a documented blind spot in OT environments — CISA has found bastion hosts lacking the monitoring and configuration expected of them, and standing pathways nobody tracks. The fix is a phased, do-no-harm cutover: run the new path alongside the legacy VPN, start with the narrowest high-friction case, and consolidate onto one platform site by site. The Dispel Zero Trust Engine eliminates the standing intermediary entirely, with full pathway visibility and concurrent-user pricing that changes the cost case versus per-seat VPN licensing.

“We want to get rid of the VPN” is one of the most common sentences on our calls. “We're worried migration will break something” is the sentence right behind it. Here's a cutover plan that answers both. 

A security analyst at a manufacturing company laid out his problem to us plainly on a call a couple months back. His company runs a VPN client bundled with their firewall, eight hundred users, no real cost to the license. “The money's perfect there,” he said. Everything else about it wasn't. 

He had no way to enforce client versions on external users. A vendor who installed the client three years ago almost certainly hadn't updated it since, and he had no lever to make them. And once someone's VPN client connects, their computer is on his network, full stop. “If somebody has their VPN client going and their computer's infected with something,” he told us, “They in theory could spread something into our network, which is a little concerning.” 

Then he mentioned the detail that's stuck with me since: they have an HVAC vendor who needs a full VPN client installed just to remote in and service their HVAC system. One narrow task, one piece of equipment, and the access footprint of a full network client. “I wouldn't mind reigning in his access,” he said, “and what he's able to get at.” That sentence is the whole VPN-and-jump-host problem in one line. The access always seems to be bigger than the job. 

The Risk Is Real. The Redesign Is Still What Stops People. 

That conversation isn't rare. Some version of it happens on calls every week, teams that want the VPN, the jump box, the workstation nobody remembers provisioning, gone. And right behind the wish is the fear that stops most of them from acting on it, not because they doubt the risk, but because migration sounds like it has to be painful. A network redesign. A cutover weekend. Downtime nobody wants to be responsible for. 

Worth being precise about what that stack actually is first, because “VPN and jump host” usually isn't two competing tools; it's two tools stacked to do two different jobs. The VPN gets a remote user, an employee at home, a vendor dialing in, onto the network perimeter or into the DMZ in the first place. The jump host is supposed to then control what that now-on-the-network person is actually allowed to touch. Neither one was ever meant to be the whole control by itself. 

CISA has already documented what happens when that stack doesn't hold. In a July 2025 advisory, CISA and the Coast Guard found that bastion hosts meant to be the sole access point into SCADA and HVAC systems at a real critical infrastructure organization “lacked the enhanced security configuration, dedicated monitoring, and specialized scrutiny expected of bastion hosts.” Standard IT accounts could reach the SCADA network directly, bypassing the jump host entirely, and the admin credentials protecting it were shared across machines and stored in plaintext. The lesson wasn't that pairing a VPN with a jump host is a bad idea in theory. It's that a jump host is a single high-value target, and once you're on it, or you've routed around it, you're just another authenticated host on the network, with nothing watching what a compromised session does next. That's exactly why most of the OT secure remote access market, Dispel included, has moved to a different model, broadly called Zero Trust Network Access, that removes the standing intermediary instead of trying to harden it further. 

That technical reality is now becoming a policy one too. In July, a U.S. senator sent a letter to CISA, OMB, and NIST demanding a two-year deadline for federal agencies to purge legacy, internet-facing VPN appliances entirely. The letter described the status quo as being “trapped in an endless game of ‘whack-a-mole’ in responding to widespread compromises.” If that's the direction federal procurement is heading, waiting it out isn't really a strategy. The question isn't whether the VPN-and-jump-host stack is a real risk. It's how to get off it without breaking something on the way. 

The Do-No-Harm Cutover Plan 

Here's the plan we walk customers through, and it's built around one rule: nothing gets touched until you know exactly what it does. 

1. Name the blind spot before you plan around it. Here's the part most teams don't say out loud. If you're running a legacy VPN and a scattered jump host footprint, you probably can't produce a map of every standing pathway into every site. Vendor profiles nobody's revoked. Jump hosts nobody remembers standing up. That's the exact blind spot CISA found in the field. You can't inventory a system you can't fully see. Start the cutover by accepting that, not by pretending a map already exists. 

2. Bring in the visibility you don't have today. Once a platform like the Dispel Zero Trust Engine is in place, Dispel’s Topology gives you what the legacy stack never did, a live view of every asset and every pathway, health checked, so you know what's load bearing and what's dead weight going forward. You're not retrofitting visibility onto the old VPN sprawl. You're finally getting it, for the first time, on the path that replaces it. 

3. Start with the narrowest, highest-friction access case. Not the whole VPN population on day one. Start with the case that looks like that HVAC vendor, one person, one asset, full network access for a task that needs almost none of it. It's the lowest-risk cutover and the most visible proof that the new path works. 

4. Run the new path alongside the old one. Nothing gets ripped out on day one. The legacy VPN keeps running while the new remote access path is validated against real usage, so there's no cutover weekend and no single point where everything has to work perfectly at once. 

5. Give vendors a fast way in, and the right connection once they're there. Onboarding through a self-service request replaces what used to be a multi-day IT ticket with something a vendor can complete in minutes. And once they're in, they're not forced through the same single connection type as everyone else. The Dispel platform's Tiered Connection Suite matches the connection to the job, a browser connection for fast access, a full virtual desktop for the vendor who actually needs FactoryTalk or a proprietary engineering tool. 

6. Consolidate as you go, not all at once. Every site you cut over collapses VPN, jump host, and often a separate PAM tool into the same platform, on the same policy. By the time you're done, you're not running four tool categories with four renewal dates and four places something can quietly misconfigure itself. You're running one. 

7. Scale on the pattern, not from scratch each time. Once the first sites are live, the rest isn't a redesign, it's a repeat. In at least one Dispel deployment, that's taken a customer from a handful of pilot sites to 100 locations in roughly 90 days, because site two through one hundred followed the same playbook site one had already proved out. 

The Cost Case Nobody Expects 

There's a licensing detail worth knowing before you assume this is a hard sell to finance. Most VPN and jump host tools price per user, every name on the list, whether they connect once a year or once a day. A platform priced on concurrent usage instead, actual simultaneous connections, charges for the twenty people on at once, not the eight hundred who technically have an account. For a lot of the fleets we look at, that alone changes the shape of the business case before you even count what four consolidated tool categories used to cost separately. 

The Migration Isn't the Risk. The VPN You're Already Running Is.

There's the security case, already made above, and then there's the cost that shows up every Tuesday, not just in an incident report, operational friction. Ask anyone who maintains jump hosts for a living what the job actually looks like. Constant patching, manual configuration, audits done by hand. None of that is hypothetical, and none of it is a security team failing at its job. It's hours spent every week maintaining the access path instead of the plant, on a stack where a person requests access, an owner approves it, and when the window closes, the path is gone, not one where nobody's sure whether an old session is still live somewhere. 

Dragos's most recent Year in Review puts a number on exactly this: 73% of all-time Dragos incident response cases trace back to a compromised VPN or jump-host credential, and 81% of OT assessments still find poor segmentation between IT and OT networks. That's not really a tooling problem. It's the two-layer model's own credentials being the thing that keeps getting stolen or reused. 

Every fleet running a legacy VPN and a scattered set of jump hosts is carrying both of these costs at once, the security risk our own customers describe on calls, that CISA has now documented directly, and that a U.S. senator is moving to legislate against, and the operational hours quietly spent maintaining a stack that was never built to scale. The fix isn't a rebuild. It's a phased cutover that starts with the site or the vendor causing you the most concern, proves itself running in parallel, and scales on its own pattern from there. Do-no-harm migration and getting rid of the VPN aren't two different projects. They're the same one, run in the right order.  

A Critical Control for Modern Risk 

Secure remote access and defensible architecture delivers more than 30% risk reduction, according to the Dragos 2025 OT Cybersecurity Financial Risk Report — and it's exactly what SANS ICS Control 4 calls out as a critical safeguard for OT cybersecurity. → Download the SANS report