What Does SASE Replace? The Honest List (And What It Doesn't)

SASE replaces six categories of legacy infrastructure: VPN concentrators, on-prem SWG/proxy appliances, standalone CASB point products, hardware firewalls for north-south traffic, MPLS circuits (via the SD-WAN component), and jump hosts/bastion servers. But the marketing pitch oversells it. SASE does NOT replace data center firewalls for east-west traffic, specialized OT security, endpoint protection, SIEM/SOAR, or email security gateways. The real answer depends on which SASE components you actually deploy and how mature the vendor's implementation is.

"So does SASE replace our firewalls or not?" This is the question that comes up in every architecture review meeting when someone suggests a SASE migration. The marketing answer is "yes, SASE consolidates your entire security stack into the cloud." The engineering answer is considerably more nuanced. SASE replaces some legacy infrastructure completely, some partially, and some not at all. The distinction matters because getting it wrong means either paying for redundant systems you no longer need or, worse, decommissioning something you still need and creating a security gap.

This guide provides a structured, honest assessment of what SASE actually replaces in a typical enterprise network. We cover six categories of infrastructure that SASE can replace, the caveats for each, and then the equally important list of what SASE does NOT replace. If you are building the business case for SASE or defending your architecture proposal against skeptics, this is the reference you need.

What SASE replaces

SASE is an architecture that converges networking (SD-WAN) and security (SSE) into a single cloud-delivered service. The security side includes ZTNA, SWG, CASB, FWaaS, and DLP. Each of these components maps to a specific category of legacy infrastructure it can replace. The key word is "can" because the replacement is not automatic. You have to actually deploy and configure the relevant SASE component, validate it handles your specific use cases, and then decommission the legacy system. Vendors who tell you this happens in weeks are either lying or talking about a trivially simple environment.

1. VPN concentrators and remote access gateways

SASE replacement confidence: High. This is the most straightforward replacement in the SASE portfolio. ZTNA (Zero Trust Network AccessZero Trust Network Access) replaces traditional VPN concentrators by providing application-level access instead of network-level access. Instead of tunneling a remote user onto the corporate network where they can reach anything, ZTNA brokers connections to specific applications based on identity, device posture, and context. The user never touches the network. There are no inbound firewall rules to manage, no concentrator appliances to patch, and no split-tunnel versus full-tunnel debates.

The caveat: VPN replacement is not a day-one flip. Nearly half of organizations report significant difficulty running VPN and ZTNA in parallel during migration, according to the Xalient 2026 survey of 700 IT leaders. The typical migration pattern is 3-6 months: start with a pilot group of 50-100 users on ZTNA for web-based applications, expand to include legacy thick-client applications that need agent-based access, and only decommission the VPN concentrators once you have confirmed 100% application coverage. Some applications, particularly legacy client-server apps that use non-HTTP protocols like ICMP or specific UDP ports, may need VPN fallback indefinitely. Cisco is the only vendor that explicitly supports a unified ZTNA plus VPN fallback client, which is pragmatic for enterprises with mixed application portfolios.

2. On-prem SWG and web proxy appliances

SASE replacement confidence: High. On-premises Secure Web Gateways, web proxy appliances like Blue Coat (now Symantec/Broadcom), McAfee Web Gateway, or Forcepoint, and explicit proxy servers are replaced by the cloud-delivered SWG component of SASE. Cloud SWG handles URL filtering, TLS inspection, malware scanning, and content categorization from the cloud rather than from an appliance sitting in your data center or DMZ. Traffic no longer needs to hairpin back to headquarters for inspection, which eliminates the latency penalty that killed user experience with centralized proxies.

The replacement is straightforward for standard web traffic. But there are two gotchas that catch teams by surprise. First, TLS inspection at scale breaks things. Applications with certificate pinning, like Git, Docker, npm, and various mobile apps, will fail when a cloud SWG inserts its inspection certificate. You will spend weeks building bypass lists. Second, some organizations have invested years in custom proxy PAC files, URL category overrides, and exception lists. Migrating that policy logic to a cloud SWG is not a technical challenge but an operational one because nobody documented why half those exceptions exist. Budget 4-8 weeks just for policy migration and testing on a 5,000-user deployment.

3. Standalone CASB point products

SASE replacement confidence: High. Standalone Cloud Access Security Brokers, the products that were deployed as separate appliances or cloud services to monitor SaaS application usage, are subsumed into the CASB component within the SSE stack. Modern SASE platforms provide both inline CASB, inspecting traffic to cloud apps in real time, and API-based CASB, scanning data at rest in sanctioned SaaS applications like Microsoft 365 and Google Workspace. Shadow IT discovery, SaaS risk scoring, and granular activity controls like allowing Dropbox viewing but blocking downloads are all standard CASB features within SASE.

The caveat is that CASB depth varies dramatically by vendor. Netskope's Cloud Confidence Index catalogs 49,000+ cloud applications with detailed risk scoring. Palo Alto has 80+ SaaS API integrations for out-of-band inspection. Cato Networks and Cloudflare have functional but less mature CASB implementations with fewer API connectors and less granular activity controls. If your standalone CASB is a sophisticated Netskope or Symantec deployment with hundreds of custom policies, replacing it with a less mature SASE vendor's CASB means losing capability. Evaluate the CASB component specifically, not just the SASE label.

4. Hardware firewalls for internet-edge and north-south traffic

SASE replacement confidence: Partial. This is where the nuance matters most. FWaaS (Firewall as a Service) within SASE replaces hardware firewalls for a specific traffic pattern: north-south traffic flowing between users or branch offices and the internet or cloud applications. When a remote worker connects to a SaaS app, or a branch office accesses the internet, FWaaS provides the L3-L7 inspection, IPS, application control, and threat prevention that a branch firewall would have handled.

What FWaaS does NOT replace is east-west traffic inspection inside your data center. Traffic flowing between servers within a data center, between VMs in the same VPC, or between microservices on a Kubernetes cluster does not traverse the SASE cloud. That traffic needs local segmentation and firewall controls. If you decommission your data center firewalls because your SASE vendor said FWaaS replaces them, you have created a massive lateral movement gap. An attacker who compromises one workload can move freely to every other workload. This is the most dangerous misconception in SASE marketing.

5. MPLS circuits and private WAN

SASE replacement confidence: High (with the SD-WAN component). The SD-WAN component of SASE replaces expensive MPLS circuits by routing site-to-site traffic over multiple broadband internet links with application-aware path selection, automatic failover, and quality-of-service policies. Organizations typically see 50-70% cost reduction when migrating from MPLS to SD-WAN. Cato Networks specifically built their private backbone as an MPLS alternative, delivering SLA-backed WAN performance across 85+ PoPs that provides measurable 20-40% latency improvements on intercontinental paths versus public internet routing.

Two important caveats. First, SD-WAN is a component of full SASE but not of SSE (Security Service Edge). If you are deploying SSE-only, meaning Zscaler or Netskope without a separate SD-WAN solution, you are not replacing MPLS. Zscaler launched their SD-WAN product in 2024 and it is still maturing. Netskope's Borderless SD-WAN shipped even more recently. If MPLS replacement is a primary driver, evaluate vendors with mature SD-WAN: Fortinet, Cisco, Cato Networks, or Palo Alto. Second, some regulated environments require private circuits for compliance reasons, and SD-WAN over internet may not satisfy those requirements even with encryption.

6. Jump hosts and bastion servers

SASE replacement confidence: High. Jump hosts and bastion servers, the hardened intermediate systems that administrators SSH or RDP through to reach internal servers, are replaced by ZTNA. With ZTNA, administrators authenticate directly to a specific application or server through the SASE broker without needing an intermediate jump box. The ZTNA agent or clientless browser access handles the connectivity, identity verification, and session recording that the bastion server was providing. This eliminates the bastion server as an attack target and reduces the blast radius of a compromised credential because ZTNA provides per-application access rather than the broad network access a bastion typically grants.

The caveat: some compliance frameworks explicitly require bastion hosts with session recording and keystroke logging for privileged access management. ZTNA handles some of this, but Privileged Access Management (PAM) solutions like CyberArk or BeyondTrust provide deeper session recording, credential vaulting, and just-in-time access elevation that ZTNA alone does not cover. ZTNA replaces the network connectivity function of a bastion. It does not replace a full PAM solution.

What SASE replaces: summary table

What SASE does NOT replace

This section is arguably more important than the replacement list above. SASE vendors have a financial incentive to maximize the scope of what their platform replaces. But SASE is not a universal security platform and it does not eliminate the need for several critical security capabilities. Getting this wrong creates real security gaps.

1. Data center firewalls for east-west traffic

SASE handles north-south traffic: users to internet, users to cloud apps, branch to internet. It does not handle east-west traffic between workloads inside your data center, between VMs in a cloud VPC, or between containers in a Kubernetes cluster. Microsegmentation platforms like Illumio, Guardicore (now part of Akamai), or VMware NSX, along with data center firewalls, are still required for lateral movement prevention. If anything, SASE makes east-west security more important because moving the perimeter to the cloud means the data center perimeter is no longer where traffic gets inspected.

2. Specialized OT and IoT security

Operational Technology environments, including SCADA systems, industrial control systems, and manufacturing floor networks, have unique security requirements that SASE was not designed to address. OT devices often cannot run agents, use proprietary protocols that SASE cannot inspect, require air-gapped or semi-isolated network segments, and operate on lifecycle timelines measured in decades rather than years. While some SASE vendors are adding IoT discovery capabilities, such as Cato Networks launching IoT/OT security in 2024 and Palo Alto's IoT Security module, these are visibility tools, not replacements for dedicated OT security platforms like Claroty, Nozomi Networks, or Dragos. If you have an OT environment, you still need specialized OT security.

3. Endpoint protection (EPP/EDR)

SASE inspects network traffic. Endpoint protection inspects processes, files, memory, and behaviors on the device itself. These are complementary, not overlapping, capabilities. CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, or Carbon Black are not replaced by SASE. Your endpoints still need malware protection, behavioral analysis, and incident response capabilities that operate even when the device is offline or when threats enter through USB drives, local file transfers, or other non-network vectors. Cato Networks recently added EPP/EDR to their platform as a converged option, but this is additive to their SASE offering, not a claim that SASE eliminates endpoint protection.

4. SIEM and SOAR platforms

SASE generates telemetry. SIEM aggregates, correlates, and analyzes telemetry from every source in your environment: SASE, endpoints, servers, applications, cloud platforms, identity systems, and physical security. Splunk, Microsoft Sentinel, Google Chronicle, or Elastic are not replaced by SASE. Some SASE vendors, notably Cato Networks, include native XDR capabilities that correlate events within the SASE data lake. But XDR within a SASE platform only sees what the SASE platform sees. It does not replace the need for cross-domain correlation that a SIEM provides. Your security operations center still needs a SIEM.

5. Email security gateways

SASE inspects web traffic and cloud application traffic. It does not inspect email at the transport layer. Email security gateways like Proofpoint, Mimecast, Microsoft Defender for Office 365, or Abnormal Security handle phishing detection, attachment sandboxing, BEC protection, DMARC enforcement, and email DLP. Some SASE vendors offer DLP policies that cover email-adjacent scenarios, like blocking file uploads from webmail interfaces, but this is not a replacement for transport-level email security. Phishing remains the number one initial access vector in breaches, and SASE does nothing to stop a phishing email from reaching an inbox.

6. Identity providers and access management

SASE consumes identity signals from your identity provider. It does not replace the identity provider itself. Microsoft Entra ID, Okta, Ping Identity, or Google Workspace identity services provide authentication, MFA, directory services, lifecycle management, and SSO that SASE relies on as inputs. ZTNA makes access decisions based on identity but does not manage identity. Your IAM platform is a dependency for SASE, not something SASE replaces.

What SASE does NOT replace: summary table

The real-world replacement timeline

Knowing what SASE can replace is step one. Understanding the timeline for actually doing it is step two. Based on community data from the Xalient 2026 survey and practitioner reports, here is what real deployments look like.

Phase 1 (months 1-3): Deploy ZTNA for a pilot group. Replace VPN access for web-based applications first. Run VPN and ZTNA in parallel. This is the least disruptive starting point and delivers the fastest ROI because VPN concentrators are expensive to maintain and have a large attack surface.

Phase 2 (months 3-6): Deploy cloud SWG. Migrate web proxy policies from on-prem appliances. This is where the TLS inspection headaches start. Build bypass lists for certificate-pinned applications. Decommission on-prem proxy appliances once traffic migration is complete.

Phase 3 (months 6-12): Activate CASB and DLP policies. Start with shadow IT discovery in monitor mode. Enable DLP for high-risk data categories first, like credentials and PCI data, and expand gradually to avoid false-positive fatigue. Decommission standalone CASB if the SASE vendor's CASB meets your requirements.

Phase 4 (months 6-18): Deploy SD-WAN and migrate MPLS circuits. This is typically the longest phase because it involves circuit procurement, hardware installation at branch sites, and circuit decommissioning with lead times. Start with low-risk sites and expand once you have validated performance meets SLA requirements.

Cost implications of replacement

The business case for SASE is strongest when you can quantify the infrastructure it replaces. VPN concentrator licensing for a 5,000-user organization runs $50,000-150,000 per year depending on vendor and throughput. On-prem SWG appliances cost $30,000-100,000 in hardware plus annual subscription fees. MPLS circuits for 20 sites can cost $200,000-500,000 per year, and SD-WAN replacement typically delivers 50-70% savings on WAN spend. Standalone CASB licenses add another $30,000-80,000 per year for mid-size deployments.

Against those costs, full SASE pricing typically lands at $15-50 per user per month depending on vendor and feature tier. For a 5,000-user organization, that is $900,000-3,000,000 per year. The math works when you are replacing three or more categories of legacy infrastructure. It may not work if you are only replacing VPN, in which case SSE-only or standalone ZTNA might be more cost-effective.

How to decide what to replace first

Not every organization should replace the same thing first. The decision depends on your biggest pain point and where the legacy infrastructure is most expensive to maintain.

• If remote access is your biggest headache: Start with VPN replacement via ZTNA. This is the fastest win with the most measurable ROI. VPN concentrators are expensive, difficult to scale, and present a large attack surface.
• If web security appliances are aging out: Start with cloud SWG to replace on-prem proxies. The hardware refresh cycle is the natural migration trigger. Cloud SWG eliminates the backhaul latency penalty that made on-prem proxies painful for remote workers.
• If WAN costs are crushing you: Start with SD-WAN to replace MPLS. The 50-70% cost reduction on circuits pays for the rest of the SASE deployment. But this requires a full SASE vendor with mature SD-WAN, not an SSE-only vendor.
• If shadow IT and SaaS sprawl are the concern: Start with CASB for visibility, then layer on DLP. Understanding what SaaS apps your employees are using is the prerequisite for any governance policy.
• If you are replacing everything: The recommended sequence is ZTNA first, SWG second, CASB/DLP third, and SD-WAN/MPLS migration last. This follows the principle of least disruption: each phase builds on the previous one and the most disruptive change (WAN migration) comes last when you have the most operational experience with the platform.

The bottom line

SASE replaces a significant portion of your legacy security and networking infrastructure, but it is not a magic box that eliminates everything. The honest answer to "does SASE replace our firewalls" is: it replaces your branch and internet-edge firewalls but not your data center firewalls. The honest answer to "does SASE replace our VPN" is: yes, for most use cases, with a 3-6 month migration period and potential VPN fallback for legacy apps. The honest answer to "can we get rid of MPLS" is: yes, if you deploy full SASE with SD-WAN, not SSE-only.

The vendors who tell you SASE replaces everything are selling you something. The engineers who tell you SASE replaces nothing are being cynical. The truth is in the middle, and the table at the top of this guide gives you the structured answer to bring to your next architecture review.

Related on sase.cloud

One email per publish. Unsubscribe anytime.