SASE (Secure Access Service Edge) merges the WAN and the network security stack into one cloud-delivered service, and applies policy based on who and what is connecting instead of which network they are a part of. SASE includes multiple components: SD-WAN, secure web gateways, CASB, ZTNA and cloud firewalls. These are all existing technologies, but they are now delivered differently, with dynamic access policies based on user identity instead of source IP.
The idea behind it is deperimeterization: as the network edge became less useful as a security boundary, security controls had to move closer to the user and the data.
The Perimeter Trust Issue
Traditional network security was built around a clear boundary. The office and data centre were considered trusted, and anything outside them was treated as untrusted. Firewalls, proxies, IPS and other security controls protected that boundary and inspected traffic crossing it.
Branches were connected to the corporate network through MPLS or site-to-site VPNs. Remote users connected through a corporate VPN. Once connected, they were effectively on the internal network.
The traditional model made sense when applications were only hosted in the data centre and most users worked from corporate offices. While on-premise applications still exist, most organisations now run applications across SaaS platforms and public cloud environments. Users connect from home, mobile networks and third-party networks. But just being on the corporate network should not mean a user automatically has access to everything within the network.
The network is no longer a useful proxy for trust. Security decisions need to be made based on the user, device, application and data being accessed.
Traditional Model Failure Points
The problems can become more obvious as the number of sites and remote users grows.
- Traffic often has to travel through a central data centre even when the application is somewhere else. A user in Edinburgh accessing Microsoft 365 might send their traffic to London, through the corporate security stack, and then back out to the internet. This backhauling adds latency for no real reason and can add up to noticeable delays.
- Split tunnel can help with this and route non-corporate traffic over WAN, but it creates another issue. Traffic that goes directly to the internet may bypass the security controls in the data centre. The alternative is to deploy and manage those controls at every site, which creates a much larger operational burden.
- The same problem appears with VPN tunnels. A full mesh between sites requires n(n-1)/2 tunnels, so 10 sites means 45 tunnels and 50 sites means 1,225. Most organisations understandably want to avoid that complexity by using hub-and-spoke designs, which brings the traffic back through a central point.
- Centralised security also creates policy management problems. Each site can have its own firewall and rule set, leading to configuration drift with little to no visibility.
- Remote access introduces another bottleneck: VPN concentrators have to handle authentication, encryption and traffic for every remote user. They are also internet-facing systems, which makes vulnerabilities in the appliance itself pretty serious. Recent vulnerabilities in Ivanti Connect Secure, FortiOS, Citrix NetScaler and Palo Alto GlobalProtect have all shown the risk of placing so much trust in a single internet-facing gateway.
- There is also a fundamental difference in how access is granted. A traditional VPN establishes a connection to the network, usually giving the device an internal IP address. From there, access is largely determined by network ACLs and firewall rules. If a user's credentials are stolen or their device is compromised, the attacker has gained a position inside the network.
Always-on VPN improves some of this. If the device remains on a managed connection, it can establish a pre-logon tunnel for domain authentication. But the underlying model remains the same. The VPN still provides access to the network, and the network remains the basis for deciding what the device can reach.
How does SASE consolidate this?
SASE has two halves; network and security:
- SD-WAN: A software-defined overlay across whatever transport each site uses (broadband, 5G, MPLS). A central controller manages routing policy, the edge device selects paths per application and steers around brownouts. With SASE, the branch builds tunnels to the provider's nearest points of presence (PoPs) and not to your DC.
- SWG (Secure Web Gateway): This is the outbound web proxy, responsible for URL filtering, TLS inspection and malware scanning.
- CASB: Provides visibility and control over SaaS. In inline mode, it inspects traffic as it passes through the security service. In API mode, it connects directly to the SaaS platform and can inspect data at rest, sharing permissions and other activity. With API access, it can also see data on unmanaged devices that never pass through the corporate proxy.
- ZTNA: Replaces network-level VPN access with access to specific applications. This is covered in more detail below.
- FWaaS: Provides firewall (layers 3-7) and IPS functions in the cloud, covering traffic that does not go through a web gateway.
- Additional controls: DLP, DNS filtering and remote browser isolation are usually included as part of the same service.
ZTNA (Zero Trust Network Access) is the main shift in this model compared to traditional perimeterisation. Instead of exposing an application to the internet, it uses a connector to make an outbound connection to the ZTNA provider. There is no inbound listener on the network edge for the application, so the application is not directly exposed.
The user's device connects to the nearest point of presence. The provider verifies the user's identity through the IdP, checks the device posture and evaluates the surrounding context. If the request meets the policy, the provider establishes a connection between that user and the specific application they are authorised to use. The user does not get an IP address on the internal network.
In NIST SP 800-207 terminology, the provider's control plane acts as the policy decision point, while the points of presence and application connectors act as policy enforcement points. Access does not have to remain valid for the entire session. If the device is later flagged by EDR, or the context changes significantly, the session can be re-evaluated. Depending on the policy, access can be revoked or the user can be required to authenticate again.
The real consolidation happens at the policy layer. Instead of maintaining separate rules across different appliances and locations, access is defined once around the user, device and application. For example, a specific group using a managed and compliant device can access a particular application, subject to the relevant DLP controls. The same policy applies whether that user is in a branch, working from home or sitting in an airport lounge. The security functions can then be applied within the same service instead of sending traffic through a chain of separate appliances. Traffic is inspected once and the results and activity are collected into a log stream for the SIEM.
The remaining problems
- The perimeter moved but didn't disappear: Identity is now the main control point, which makes the IdP a prime target. Adversary-in-the-middle attacks can steal session tokens after MFA has succeeded. Phishing-resistant authentication like passkeys is increasingly important.
- Concentration risk: Every user, every branch and every application now depends on one provider. If they have an outage, the impact can be organisation-wide unless you have another path. This is a third-party risk and availability decision for BIA.
- TLS inspection has a cost: Break-and-inspect requires a root CA on managed devices and exceptions for certificate-pinned applications. There are also legal and privacy concerns around inspecting banking, healthcare and other sensitive traffic. Some platforms block QUIC to force traffic through protocols they can inspect.
- "Single vendor" may not be the only vendor: Some products are several acquired technologies running under one brand. You may still have multiple agents, consoles and policy models.
- PoP geography: Your latency now depends partly on the provider's routing and peering. The location where traffic is decrypted can also matter for data residency and sovereignty.
- Does not apply to all devices: POS terminals, printers, IoT and OT cannot run an agent. VoIP, server-initiated traffic and legacy applications can also be awkward at best over ZTNA. These systems may end up behind the SD-WAN edge with conventional firewall rules.
- East-west is still with you: SASE governs user-to-app and branch-to-internet, but does not solve server-to-server traffic inside a data centre or VPC. Microsegmentation is still a separate project.
- Posture is self-reported: The agent can report that the disk is encrypted and EDR is running, but a compromised endpoint may be able to interfere with those checks. Hardware-backed attestation provides stronger assurance.
- Vendor lock-in: Your policies are built around the provider's platform and licensing is usually recurring. Moving away or switching vendors means having to rebuild policies, replace agents and change how applications are published.
Approaching SASE
- Start with the VPN: Pick one internal application, publish it through ZTNA and move one team across. It lets you test the policy model without committing the whole org.
- Fix identity: MFA everywhere, phishing-resistant authentication for admins and conditional access already working. SASE is built on top of the IdP, so it inherits its weaknesses.
- Build the asset inventory: Policies based on managed and compliant devices are only useful if you know which devices you actually manage.
- Keep local breakout: Do not replace DC backhaul with a PoP in the wrong location. Check where the provider's PoPs are relative to your users.
- Plan the break-glass path: Decide what happens when the provider is down, who can invoke the fallback and how it is logged.
- Keep segmenting inside: Use secure zones and microsegmentation for servers, with separate VLANs for any endpoint that cannot run an agent.
SASE is based on the idea that network location is no longer a useful trust signal. It removes the VPN concentrator, much of the backhaul and the collection of firewall rules spread across different sites, and replaces them with policies based on the user, device and application.
SASE does not mean trust has gone away. You are still relying on the identity provider to authenticate users and the SASE provider to enforce your policies. The impact can be significant if either one is compromised or unavailable.