VPN Is Dead: Why MSPs Are Moving to SASE

For MSPs, VPN replacement has moved from a roadmap item to an urgent operational decision. The architecture that secured remote access for the past two decades is now one of the most actively exploited entry points in the SMB threat landscape.

The core problem is structural. VPNs were built for a world where users sat close to a central data center and remote access was occasional. That world is gone. Clients work from home, hotels, coffee shops, and branch offices spread across multiple time zones. Is VPN still performant or secure enough to handle the load? Traditional infrastructure wasn’t designed to operate at this capacity, enforce modern security controls, nor integrate with a cloud-first application stack.  

Why Legacy Remote Access Security Is Failing SMB Clients

The failure is not subtle. MSPs see it in the ticket queue every week: dropped connections, slow application performance, users who have quietly stopped connecting to the VPN because the experience is too painful to bother with.

A VPN that users bypass is a glaring risk. When employees connect directly from unsecured networks to SaaS applications, cloud storage, or internal systems without the VPN, they operate entirely outside the visibility and enforcement boundary it provides. MSPs lose the ability to monitor, log, or block activity they cannot see.  

Performance issues drive this behavior. VPNs backhaul all traffic through a central chokepoint like a data center, a headquarters appliance, or a hosted server. Every user who connects adds latency. Every mile between the user and that central point compounds the problem. Routing traffic from a remote employee, through a central server, and then back out to a cloud application running in a completely different region is genuinely inefficient. Users feel it immediately, and they adapt by working around the tool.

Split tunneling is the standard workaround. Send corporate traffic through the VPN and let everything else go direct. Performance improves, but visibility drops further and the attack surface expands. Choosing between performance and security doesn’t solve the problem, and in the process, highlights others.

Is VPN Still Secure? What the Threat Record Shows

The vulnerability record on major VPN platforms is consistent and damning. High-severity CVEs targeting appliances from well-known enterprise vendors have been exploited in the wild, often at scale, before organizations had time to apply patches. Ransomware operators and nation-state groups actively scan for unpatched VPN infrastructure because it sits at the network edge and, when compromised, hands over authenticated access with minimal friction.

A few examples illustrate the pattern clearly.

• Ivanti Connect Secure (CVE-2023-46805 and CVE-2024-21887) were chained together by threat actors to bypass authentication and execute arbitrary commands on unpatched appliances. Mass exploitation began before most organizations had applied the available mitigations. CISA issued an emergency directive requiring federal agencies to disconnect affected products. ‍
• Fortinet FortiGate (CVE-2023-27997) was a heap-based buffer overflow in the SSL-VPN pre-authentication component, meaning an attacker could execute code without valid credentials. Fortinet rated it critical. Proof-of-concept exploits circulated within days of disclosure. ‍
• Cisco IOS XE (CVE-2023-20198) allowed unauthenticated remote attackers to create privileged accounts on affected devices. Tens of thousands of internet-facing Cisco devices were compromised within the first week of active exploitation.

For MSPs managing VPN infrastructure across dozens of clients at varying patch levels, that exposure multiplies. Any unpatched appliance on a client network is a viable entry point. Staying ahead of that across an entire client base is an unsustainable operational burden.

The security model compounds the problem further. VPNs authenticate a user once and then grant broad network access. There is no inspection of what moves through the encrypted tunnel, no verification of device health at connection time, and no enforcement of least-privilege access once a session is established. A compromised credential does not just expose one application. It exposes the entire network segment that user could reach, which in a typical SMB flat network is most of it.

Attackers understand this. Credential stuffing attacks, phishing campaigns, and dark web credential markets all target VPN access specifically because the return on a single valid login is high. MSPs need a VPN alternative for the businesses they serve.

VPN vs. ZTNA: A Different Security Model at the Foundation

Zero trust network access (ZTNA) operates from an opposite assumption. Nothing is trusted by default: not the user, not the device, not the network the connection originates from. Access requires verification of identity, validation of device posture, and evaluation of context. Once granted, access is scoped to the specific resource the user needs through the principle of least privilege.

The security difference from a VPN is concrete. A stolen credential in a ZTNA environment does not give an attacker broad network access. Access is limited to only the resources that specific user was authorized to reach, and only if the device also passes posture checks. Lateral movement is constrained at the architectural level before any firewall rule or network policy has a chance to fail.

Device posture verification means unmanaged endpoints, personal devices without endpoint protection, or machines that have not received recent security updates get blocked at the authentication layer. MSPs can enforce consistent endpoint standards across all clients without layering in additional tooling to cover what the access control mechanism should be doing natively.

Session-level logging gives security teams visibility into user activity after authentication. Not just a record that a login succeeded, but a log of what resources were accessed, when, from where, and from what device. That data is the foundation of any real detection and response capability for remote access events.

Enforcing ZTNA through SASE

If ZTNA is the approach that replaces VPNs, Secure Access Service Edge (SASE) is the platform that delivers it.

SASE is a cloud-native architecture that converges network connectivity and security enforcement into a single platform. Through secure web gateway, DNS security, URL and content filtering, threat inspection, and other capabilities, SASE provides a consolidated framework for enforcing ZTNA and replacing VPNs across an entire client base.

Unlike location-bound VPNs, SASE operates from a distributed network of cloud points of presence (PoPs) deployed across multiple regions globally. Rather than routing all user traffic to a single central appliance, each connection is directed to the nearest PoP. The result is that a field technician in Phoenix, a remote accountant in Tampa, and a contractor working overseas all get low-latency connections routed through regional infrastructure, not a single chokepoint in a data center that might be two time zones away.

Security services run inline at those PoPs. Traffic gets inspected and policies get enforced before the connection reaches its destination, regardless of where the user is or what network they are on. Threat inspection, DNS filtering, and web gateway controls are not optional add-ons applied after the fact. They are structural components of every connection.

For MSPs, the multi-tenant operational model is where SASE separates itself from any VPN-based approach. A single control plane manages policies across every client. Adding a new client means configuring access policies, not provisioning and hardening new infrastructure. Responding to a security event means pulling logs from one console. Adjusting access for a new hire, a contractor, or a terminated employee is a policy change applied immediately across the platform, not a manual process across multiple systems.

Why MSPs Are Having the VPN Replacement Conversation with Clients

Three forces have converged to move VPN replacement for small business from a theoretical discussion to an active buying decision.

• Remote and hybrid work made consistent remote access security a daily operational requirement rather than an edge case. Clients who provisioned VPNs for occasional use now depend on them as primary infrastructure. The gaps that were tolerable are now visible every day. ‍
• Cyber insurance underwriters have tightened requirements around access control, multi-factor authentication enforcement, and visibility into remote user activity. A VPN with no device posture checking and no session inspection does not satisfy the questions underwriters are now asking. Clients who cannot demonstrate adequate remote access controls are facing higher premiums, coverage exclusions, or outright denials. ‍
• Compliance frameworks that apply to SMB clients in healthcare, defense contracting, finance, and professional services have provisions that speak directly to how remote access is managed, logged, and audited. SASE architectures are better positioned to meet those requirements than legacy VPN deployments, and MSPs who can demonstrate that alignment have a concrete differentiator in competitive conversations. ‍
  
  • HIPAA requires covered entities and their business associates to implement technical safeguards controlling access to electronic protected health information. A VPN grants access to the network, not to specific systems. Demonstrating that only authorized users accessed specific ePHI systems requires session-level logging that a VPN cannot provide. SASE delivers that granularity natively. ‍
  • CMMC 2.0 requires organizations in the defense industrial base to implement access control, audit logging, and configuration management practices tied directly to how remote users connect. ZTNA-enforced access with device posture validation and session logs maps directly to those control requirements. Contractors still relying on VPNs face a growing gap between their current posture and what Level 2 certification requires. ‍
  • PCI-DSS v4.0 requires that access to cardholder data environments be controlled, logged, and monitored. Broad network access through a VPN creates ambiguity about who accessed what and when. SASE-based ZTNA scopes access to specific resources and logs every session, making audit trails far cleaner and more defensible during an assessment.

MSPs who can demonstrate that SASE addresses compliance requirements across these frameworks have a concrete differentiator when competing for clients in regulated industries.

Moving Clients Off a VPN Without a Cutover Crisis

Migration from VPN to SASE does not require a weekend maintenance window or a single high-risk cutover. A phased approach keeps existing access intact while the new environment is validated.

1. Audit current VPN usage: Identify who is connecting, to what resources, how frequently, and from what devices. Most MSPs find that documented access policies do not match actual usage patterns. That gap informs scoped ZTNA policies from the start. ‍
2. Enroll new users and devices directly into the SASE platform: Do not add new users to the old VPN. Every new enrollment goes through SASE from day one, building a validated baseline of policies and access patterns before the broader migration begins. ‍
3. Migrate high-risk users first: Users with administrative credentials, broad network access, or access to sensitive systems represent the highest blast radius if their credentials are compromised. Moving them to ZTNA-scoped access reduces exposure immediately. ‍
4. Map application access against real usage data: The SASE platform's session logs will show exactly which resources users access. Use that data to right-size access policies. Most clients find users need access to far fewer resources than the VPN was implicitly granting. ‍
5. Transition remaining users in cohorts: Move users in groups organized by role, department, or risk profile. Validate access and collect feedback before moving the next cohort. Refinements to policy are easier to make incrementally than after a full migration. ‍
6. Validate policy coverage and run parallel for a defined period: Keep the VPN available as a fallback while confirming that all required access is available through SASE. Define a cutoff date and communicate it to users and stakeholders. ‍
7. Decommission the VPN infrastructure: Once all users are enrolled and policies are stable, retire the VPN appliance or hosted instance entirely. That device disappears from the attack surface. No more patching cycles, no more CVE monitoring for infrastructure that should have been retired years ago.

The Cost of Waiting

Every client still running a legacy VPN is carrying a known and documented risk. The vulnerabilities are public and the attack patterns well established. Threat actors aren’t sitting around while MSPs finish their evaluation cycles, and if a client is attacked, the ramifications and downstream costs are steep. The time to act is now.

SASE is production-ready, deployed at scale, and available through MSP-focused platforms built specifically for the multi-tenant, multi-client operational model that defines managed services. It’s the business VPN alternative that addresses the security, performance, and operational concerns MSPs are looking to address.

The MSPs winning the remote access security conversation with clients are the ones who can walk in with a clear explanation of why the current tool is failing and a concrete path to something better. That conversation starts with understanding what SASE delivers and why the VPN era is over.

See How SASE Works as a VPN Replacement for MSPs

Ready to move clients off legacy VPN infrastructure? See how a SASE platform built for MSPs delivers zero trust network access, consistent security enforcement, and the multi-tenant management model your team needs to scale.

Read our eBook, SASE Explained, to see how you can use SASE to modernize your network security with ZTNA,

Frequently Asked Questions

Is VPN still secure for remote access?

No, not reliably. The vulnerability record on major VPN platforms shows consistent, high-severity CVEs that ransomware operators and nation-state groups exploit at scale. Beyond the patching problem, the core security model is flawed: a single valid credential grants broad network access with no device posture check and no least-privilege enforcement. Patching addresses individual vulnerabilities. It does not fix the underlying architecture.

What is the difference between VPN and ZTNA?

A VPN authenticates a user once and grants broad access to the network segment behind it. ZTNA verifies identity, validates device posture, and evaluates context before granting access. That access is scoped to the specific resource the user needs, not the entire network. A compromised credential under ZTNA does not hand over the network. Under a VPN, it often does.

What is SASE and how does it replace a VPN?

SASE is a cloud-native platform that converges network connectivity and security enforcement. It replaces VPN infrastructure by routing user traffic to the nearest cloud point of presence rather than backhauling it through a central appliance. Security controls including secure web gateway, DNS security, and ZTNA run inline at those PoPs. The result is faster performance, consistent enforcement, and no hardware to patch or maintain.

How do MSPs migrate clients from VPN to SASE without downtime?

Migration does not require a cutover event. New users enroll directly into the SASE platform first, giving MSPs time to validate and refine policies against real usage before existing users transition. High-risk users with broad access or administrative credentials move first to reduce blast radius early. Once all users are enrolled and policies are stable, the VPN infrastructure decommissions entirely.

Does SASE help meet cyber insurance requirements?

Yes. Cyber insurance underwriters now require documented access controls, MFA enforcement, device posture checking, and session-level logging. A traditional VPN satisfies almost none of those requirements on its own. SASE unifies ZTNA, threat prevention, and secure web gateway into a single platform, making it far easier to demonstrate the consistent policy enforcement and audit-ready logging that underwriters expect.

Can SASE help SMBs meet HIPAA, CMMC, or PCI-DSS requirements?

Yes. SASE capabilities including ZTNA, secure web gateway, DNS security, and session logging map directly to control requirements across HIPAA, CMMC 2.0, and PCI-DSS v4.0. MSPs who can demonstrate that alignment have a concrete differentiator when competing for clients in healthcare, defense contracting, and financial services.

Why are MSPs replacing VPNs for their SMB clients now?

Remote and hybrid work made consistent remote access a daily operational requirement, exposing VPN performance and security gaps that were previously easy to ignore. Cyber insurers have tightened access control requirements that legacy VPNs cannot satisfy. Compliance frameworks in healthcare, finance, and defense now require documented remote access logging and enforcement that VPN deployments were never built to provide.