SASE Migration: Moving From VPN and Hub and Spoke Without Opening Gaps

The riskiest period in any SASE programme is not before or after the move but during it, when VPN concentrators, MPLS backhaul, data centre firewalls and the new cloud service all carry live traffic and each assumes another is enforcing policy. This guide covers only the migration: how to sequence the move from remote access VPN and hub and spoke WAN to a SASE or SSE service, how to run the old and new paths side by side without creating bypass routes, and how to cut over and decommission safely. It assumes you have already chosen an architecture; the concepts, components and model choice are covered in the SASE and SSE Guide. It is written for network, security and identity architects and the programme managers who own the cutover plan.

Source note: zero trust migration guidance is attributed to NIST SP 800-207, CISA, NSA and the NCSC as linked in the text, checked in November 2026. Wave order, rollback steps, metrics and targets are NHI Mgmt Group recommendations. Confirm against the official text before relying on it.

Key takeaways

• Plan for a long hybrid period. NIST SP 800-207 says there may be an indefinite period when zero trust and non-zero trust workflows coexist; design coexistence deliberately rather than treating it as a short gap.
• Every old path is a bypass until it is closed. A user moved to the SASE agent who can still reach the VPN, or a branch with both MPLS and local breakout, can route around the new policy.
• Egress IP and DNS changes break more than routing. SaaS IP allow lists, partner firewall rules and conditional access named locations all key on the old data centre egress addresses.
• Observe before you enforce. Run each wave in report-only or monitor mode first, while still enforcing basic controls such as MFA failures and known malicious destinations.
• Decommissioning is a security control. The migration is not finished until VPN profiles, concentrator accounts, firewall rules and MPLS circuits that the new service replaced are gone.

What you are migrating away from

Hub and spoke designs send branch and remote user traffic back to a data centre over MPLS or IPsec, through a central firewall and proxy stack, and out to the internet from one or two egress points. Remote access VPN extends the same model to individual users: once the tunnel is up, the user is on the network. CISA, with the FBI and partners in New Zealand and Canada, has published Modern Approaches to Network Access Security, which highlights the vulnerabilities and misconfiguration risks of traditional VPN deployments and encourages organisations of all sizes to move towards zero trust, SSE and SASE for better visibility.

The migration therefore changes three things at once, and each needs its own plan:

Sequencing the migration

NIST SP 800-207 section 7.3 describes an incremental approach: survey actors, assets and processes; rank processes by importance and risk and start with a lower-risk one (it names cloud-based processes and those used by remote workers as frequent candidates); formulate policies and their dependencies; pilot candidate solutions; deploy in observation mode; then expand. Applied to SASE, a practical order is:

1. Survey flows and dependencies: export VPN logs, proxy logs and firewall rule hit counts to find who reaches what, over which protocol, from where. Record every place the current egress IP is allow-listed: SaaS tenant IP restrictions, partner firewalls, payment gateways, conditional access named locations and email relays.
2. Prepare identity and devices: federate the SASE service with your identity provider, provision users and groups with SCIM, and decide the device posture signals each policy will use. NIST notes that common elements such as identity, device management and logging must work in both hybrid and zero trust environments.
3. Wave 1, remote user web and SaaS traffic: deploy the agent to a pilot ring with the VPN still installed, steer internet traffic to the cloud gateway, and keep the VPN only for private applications.
4. Wave 2, private web applications through ZTNA: publish applications individually by hostname and port, starting with internal web apps that have the fewest dependencies.
5. Wave 3, thick clients, SSH, RDP and administrators: move these last among user traffic, and route administrator access through PAM session controls rather than plain ZTNA where possible.
6. Wave 4, branches: move sites to SD-WAN with breakout into the SASE service site by site, keeping MPLS as the fallback until each site passes failover tests.
7. Decommission: close VPN access per group, then retire concentrators, central proxies and MPLS circuits once usage is zero for an agreed period.

Why web traffic first: it has the simplest rollback (change the agent profile or PAC file back) and gives the operations team experience with the cloud service before private applications depend on it. Why administrators last: their access has the highest impact if a policy is wrong, and it often uses protocols the new service handles differently.

Running old and new paths side by side

Coexistence is where gaps open. NIST notes that zero trust and non-zero trust workflows may coexist indefinitely and that migration typically happens one business process at a time. Make the coexistence rules explicit:

• One path per application per user group: when an application moves to ZTNA for a group, remove that group's VPN route or firewall rule to the application at the same change, so there is no second way in.
• Agent and VPN client conflicts: two clients on one laptop can each try to own DNS and routing. Define precedence (for example, the SASE agent handles internet and published applications, the VPN only the remaining private subnets) and test with each operating system build before the pilot.
• Split DNS: internal names must resolve through the ZTNA path once published; stale entries pointing at VPN-only addresses cause silent fallbacks to the old path.
• Split tunnelling during coexistence: a VPN that already excludes SaaS traffic means that traffic has never been inspected; moving it into the cloud gateway is a gain, but check that the agent is actually capturing it. See the VPN split tunnelling guide.
• Branch dual paths: a branch with both MPLS to the hub and local breakout can send the same traffic two ways depending on route metrics. Keep breakout disabled, or limited to the SASE tunnel, until the branch's policy is live. See the SD-WAN Security Guide.
• Policy parity, not rule copying: translate the intent of central firewall and proxy rules into identity and application policy, and drop rules with no hits in the survey. Copying any-to-any objects carries the old exposure into the new service.

Cutover risks and how to control them

The legacy path matters because attackers use whichever door is still open. In the Change Healthcare breach, attackers used a stolen employee credential on a Citrix remote access portal that did not require MFA. During a migration, older remote access services that "will be retired soon" get less attention; keep them under full controls (T1133 External Remote Services with T1078 Valid Accounts is the pattern to watch) until the day they are switched off.

Rollback per wave

• Web and SaaS: revert the agent forwarding profile or PAC file for the affected group; the central proxy stays live until the wave is signed off.
• Private applications: re-add the group to the VPN route for that application only, with an expiry, rather than restoring full VPN access.
• Branches: keep the MPLS or hub tunnel configured and tested so a site can return to it by route change; do not cancel circuits until the site has run cleanly for the agreed period.

Decision guidance

• Users before branches, or branches first: remote-first organisations gain most from moving users first; branch-heavy retailers and manufacturers often start with SD-WAN and breakout because MPLS renewal dates drive the programme. Either way, security policy must be live before breakout is enabled.
• Big bang or waves: waves by user population and application almost always. A single cutover weekend only suits small organisations with few private applications and a simple network.
• What to leave on VPN: some legacy protocols, OT access and applications that need inbound connections from the server to the client may stay on a scoped VPN for a defined period. Name them, restrict them to specific groups and devices, and give each an end date. See the Secure Remote Access Beyond VPN Guide for alternative patterns.
• Small organisations: an SSE service with agent-based web filtering and ZTNA for a handful of applications can replace the VPN in one quarter; keep the old firewall's VPN disabled but configured for a month as rollback.
• Large organisations: run a programme board with network, security, identity and service desk leads, a weekly wave review, and a migration register listing every application, its owner, wave, status and rollback route.

Where identity fits

SASE moves trust decisions from network location to identity and device, so identity hygiene must lead the migration rather than follow it. Groups used for ZTNA policy need owners and clean membership; device compliance must be reliable before it gates access. The migration also creates new non-human identities: ZTNA connector enrolment tokens, SCIM provisioning tokens, API keys for log export and SD-WAN device certificates. Inventory them, store them in a secrets manager, scope them narrowly and rotate them. See the ZTNA Guide and the Non-Human Identity (NHI) Guide.

Detection and measurement

• Residual VPN use: authentications to the VPN by user group and by application destination; migrated groups should show none.
• Agent health: devices with the agent disabled, not connected or in fail-open state for more than a set time.
• Bypass and exemption usage: volume of traffic matching bypass rules, and new bypass requests per week.
• Direct-to-internet traffic from branches: flows leaving a branch outside the SASE tunnel after the site's cutover.
• Old allow list hits: sign-ins to SaaS tenants from the old data centre egress after a group has moved, which signals a fallback path.

Common failure patterns

• VPN kept "just in case" for everyone: the concentrator remains reachable by all users, so the old attack surface survives the programme.
• Allow lists widened under pressure: a SaaS IP restriction is removed during a wave to stop complaints and never restored.
• Breakout before policy: branches get local internet access on SD-WAN before the SASE tunnel and policy are in place.
• Rules migrated literally: hundreds of firewall objects are copied into the cloud service, including any-to-any rules with no recent hits.
• Logs lost in transition: detections built on proxy and VPN logs stop firing and nobody notices until an incident.
• Silent fail-open: agents fail open when a point of presence is unreachable and no one monitors how often.

Framework mapping

Practitioner checklist

• Survey VPN, proxy and firewall logs to map users, applications, protocols and dependencies before wave 1.
• List every allow list keyed on current egress IPs and update it before each wave.
• Federate identity, provision groups with SCIM and validate device posture before enforcing policy.
• Move web and SaaS first, private web apps next, thick clients and administrators last, branches by site.
• At every wave, remove the migrated group's VPN or firewall path to the moved application in the same change.
• Run each wave in monitor mode first while still enforcing MFA and known-bad blocking.
• Give every bypass and legacy VPN exception an owner and an expiry date.
• Onboard SASE logs and test detections before moving the first pilot user.
• Keep MPLS and central proxies as tested rollback until each wave is signed off.
• Retire VPN concentrators, accounts, rules and circuits once residual use reaches zero.

Standards and references

• NIST: SP 800-207, Zero Trust Architecture
• CISA: Modern Approaches to Network Access Security
• CISA: Zero Trust Maturity Model
• NSA: Advancing Zero Trust Maturity Throughout the Network and Environment Pillar
• NCSC: Zero trust architecture design principles
• MITRE ATT&CK: T1133 External Remote Services

Related NHI Mgmt Group resources: SASE and SSE Guide · Secure Remote Access Beyond VPN Guide · ZTNA Guide · SD-WAN Security Guide