Yes, if VPN-era access paths still provide standing entry into sensitive systems. A SASE programme only reduces risk when old access routes are retired, third-party access is re-governed, and identity context is enforced consistently rather than layered on top of legacy pathways.
Why SASE migration should retire legacy VPN paths
SASE is not a simple overlay that makes old remote access safer by itself. If users, vendors, or admins can still reach sensitive systems through legacy VPN entry points, the environment keeps the same standing-access problem SASE is meant to reduce. The practical goal is to remove duplicate trust paths, not just add a newer control plane on top of the old one.
That matters because VPN-era access often grants broad network reach once a session is established. Remote Access Identity Guide is relevant here because it treats remote access as an identity and trust problem, including dormant VPN accounts, MFA at every entry point, ZTNA, and third-party access.
In a clean SASE design, access should be evaluated at the point of request, with identity, device posture, and policy context deciding what can be reached. If the old VPN route still exists, that decision is often bypassed or weakened, because the legacy path may still expose broader internal connectivity than the SASE path was designed to replace.
What needs to change in access architecture, not just tooling
The hardest part of SASE adoption is usually migration discipline. Traffic steering, PoPs, and policy engines matter, but the security outcome depends on whether the old entry points are actually removed, whether exceptions are time-bound, and whether third-party connections are reworked rather than left as permanent tunnels into the network.
SASE and SSE Guide is useful because it frames SASE as an architecture with ZTNA, traffic steering, identity integration, and migration choices, not just a product swap. That is the right lens for deciding what to decommission and what must be re-authenticated through the new path.
The architectural question is whether the organisation is replacing network reach with policy-enforced access, or simply adding a second way in. If both exist indefinitely, monitoring becomes harder, user experience becomes inconsistent, and attackers inherit multiple footholds to target.
Why legacy access paths remain a threat after the move
VPN-era paths are attractive to attackers because they are often stable, well-known, and granted high trust once credentials succeed. In practice, the risk is not only password theft. Session hijack, token theft, and overbroad connectivity can turn an old remote access channel into a fast route to internal systems even after SASE is deployed.
SonicWall SSL VPN account compromises 2025 shows why valid credentials against a VPN remain dangerous when the access path itself still exists. CitrixBleed 2 2025 reinforces the same lesson for session-token abuse, where a legacy edge can let attackers bypass MFA and reuse trust already established on the old path.
The practical implication is that migration must include exposure reduction, not only policy uplift. If the legacy route is still operational, assume it remains part of the attack surface and can be used to sidestep the tighter intent of the SASE design.
Risk and Threat Considerations
Leaving VPN-era access paths active after SASE migration creates dual-control exposure. Defenders may believe identity context and least-privilege policy are enforced uniformly, while attackers or users can still traverse a broader legacy route that preserves standing access into sensitive systems.
Failure mechanism: Legacy VPN routes continue to authenticate users or third parties directly into internal reach, so the SASE policy layer does not become the single enforcement point. That preserves broad connectivity, weakens visibility, and can leave dormant accounts, unmanaged exceptions, or stolen sessions exploitable.
Impact: Organisations can lose the main security benefit of SASE, with greater blast radius, inconsistent policy enforcement, harder incident investigation, and a higher chance that compromised credentials or session material will still provide useful access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-17 — Remote Access | Controls remote access paths that SASE should replace or constrain. |
| IA-2 — Identification and Authentication (Organizational Users) | SASE access decisions depend on strong user authentication at entry points. | |
| IA-9 — Service Authentication | Third-party and machine-mediated access paths must be re-governed during migration. | |
| Recommendation — Retire or tightly restrict legacy remote access routes to enforce a single approved access model. Require strong authentication at every approved remote access entry point. Apply dedicated authentication controls to non-human and service-mediated access paths. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | SASE migration should replace implicit trust from network location with per-request verification. |
| Recommendation — Use continuous verification and least privilege to retire implicit VPN trust. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Legacy VPN paths are an access-control issue that requires pruning and review. |
| Recommendation — Remove unused access paths and regularly review exceptions to the approved access model. | ||
Practitioner Guidance
What to prioritise: Treat route retirement as a migration deliverable, not a nice-to-have cleanup task. The first question is whether any legacy VPN, remote desktop, or third-party tunnel still reaches production or sensitive administrative systems without going through the new access policy.
What to verify: Confirm that each exception has an owner, an expiry date, and a compensating control. If a legacy path remains, verify that it is constrained to a narrow business case and that its users are monitored as an exception set rather than as normal remote access.
Decision rule: If the old path can still provide standing access to a sensitive asset, prioritise decommissioning or re-brokering that access before considering the migration complete. If you cannot retire it yet, reduce its privilege, shorten its lifetime, and make it visible as a temporary residual risk.
Practitioner takeaway: SASE only changes the security posture when it becomes the primary access path. If the VPN-era path still works, the organisation has not replaced the model, it has only added another one.
Related resources from NHI Mgmt Group
- What should organisations do first when moving remote workers off legacy VPN access?
- How should organisations replace VPN-based access for private cloud applications without weakening security?
- How should organisations replace VPN access for mobile workers without creating new security gaps?
- When should organisations replace VPN access with identity-aware access for Kubernetes tools?