A modern enterprise user may start the day in a branch office, move to a home network, connect through a mobile hotspot and access applications running across SaaS platforms, public cloud environments and private infrastructure, often without noticing any change in connectivity.
For IT and security teams, however, every one of those connections raises important questions:
The SASE architecture was designed to answer these questions through a single operating model.
SASE combines connectivity, security enforcement, and policy control into a unified architecture that follows users, devices and applications wherever they are located.
Understanding the individual components is relatively straightforward. Understanding how those components work together is what explains the real value of SASE architecture.
Traditional enterprise architecture was built around a simple assumption:
Users connect to applications through the corporate network.
That assumption becomes less useful when employees work remotely, applications move to SaaS platforms, and workloads run across multiple cloud environments.
In traditional architectures, traffic is often sent to a central data centre before reaching its destination. This approach, known as backhauling, made sense when applications and security controls were located in the data centre.
Today, many applications are delivered through SaaS and cloud platforms. Sending traffic to the data centre first can create three common challenges.
Higher Latency
Backhauled traffic follows a longer path than necessary. Instead of travelling directly to the application, traffic is first routed through the data centre for inspection before reaching its destination.
Operational Complexity
VPNs, firewalls, web gateways and other security tools often need to be managed separately, making policy management more difficult.
Inconsistent Security
Different tools may apply different policies to the same user, device or application.
SASE changes the control point.
Instead of sending traffic back to a central location for inspection, SASE applies security controls through distributed service edges closer to users and applications. This reduces dependence on backhauling while allowing access decisions to be enforced more consistently.
SASE architecture becomes easier to understand when viewed as three working layers. Together, these layers allow SASE to deliver consistent connectivity, security and access control across users, devices and applications.
The connectivity layer determines how traffic moves between users, branches, applications and cloud platforms.
This is primarily where SD-WAN operates.
Rather than sending all traffic down fixed paths, routing decisions can take application requirements, network conditions and business policies into account.
A real-time collaboration session may require a low-latency path,while a large file transfer may be routed differently.
The security enforcement layer applies security controls to traffic and access requests.
This commonly includes:
The purpose is not simply to inspect traffic. It is to apply the right security controls based on identity, application, device posture, and risk.
The policy layer connects everything together.
It determines:
Who can access what
Under what conditions access is allowed
From which devices access is permitted
At which locations policies apply
With what level of risk, a session can continue
Without a shared policy layer, networking and security tools may still function, but they operate as separate systems rather than a unified architecture.
This is one of the key differences between a SASE architecture and separate security and networking tools.
The easiest way to understand SASE is to follow a complete user session.
Imagine an employee working from home who opens a SaaS collaboration platform to join a meeting, access files, and communicate with colleagues.
The organisation first confirms the user's identity through its identity platform. The purpose is to establish who is requesting access before any application connection is allowed.
If required by policy, the user completes multi-factor authentication. This provides additional verification before access decisions are made.
The architecture checks whether the device meets organisational security requirements.
Examples may include:
Managed device status
Endpoint protection
Operating system compliance
Encryption status
If the device does not meet policy requirements, access may be restricted or denied.
The session is routed to an appropriate SASE Point of Presence (PoP). The goal is to apply security inspection and policy enforcement closer to the user rather than sending traffic back to a central data centre.
The policy engine evaluates
User identity
Authentication status
Device posture
Application requested
Location Risk signal
Based on this information, the architecture determines how the session should be handled.
The appropriate security services are applied before access is granted.
For a SaaS application, this may include:
Web security controls through SWG
SaaS governance controls through CASB
Data protection policies
Access restrictions based on risk or policy requirements
Once identity, device and policy requirements are satisfied, the user is allowed to access the application.
From the user's perspective, the process appears seamless. Behind the scenes, multiple security and policy checks have already taken place.
Access is not automatically trusted for the entire session.
The architecture can continue evaluating:
Device compliance
User behaviour
Location changes
Data movement
Emerging risks
If conditions change, the session may be challenged, restricted, or terminated based on policy.
This continuous evaluation is an important part of a Zero Trust approach.
When the user signs out, the session expires, or policy terminates access, the session ends.
The next session goes through the same evaluation process again.
This example demonstrates how connectivity, security enforcement and policy layers work together during a single user session. Rather than relying on a central network perimeter, SASE applies identity verification, security controls and policy decisions throughout the access process.
A SASE architecture is not defined by the individual technologies it contains. It is defined by how those technologies work together during an access request.
| Component | Role in the architecture |
| Identity Provider | Verifies who the user is |
| MFA | Provides additional user verification when required |
| Device Posture | Checks whether the device meets security requirements |
| Policy Layer | Determines access, routing and security decisions |
| SD-WAN | Selects the most appropriate path for traffic |
| ZTNA | Controls access to private applications |
| SWG | Inspects internet-bound traffic |
| CASB | Governs SaaS application usage and activity |
| FWaaS | Applies firewall policies from the cloud |
| DNS Security | Blocks access to known malicious domains |
| DLP | Helps protect sensitive data from unauthorised sharing or transfer |
| PoPs | Apply security inspection and policy enforcement closer to users and applications |
During a typical session, identity, authentication and device posture provide context for the policy layer. The policy layer determines how traffic should be handled. SD-WAN selects the traffic path, while security services such as ZTNA, SWG, CASB and FWaaS apply the appropriate controls before access is allowed.
This interaction between connectivity, security enforcement and policy is what makes SASE an architecture rather than a collection of individual technologies.
Points of Presence (PoPs) are the locations where SASE services inspect traffic and enforce security policies.
Their importance comes down to one factor: distance.
If traffic must travel a long distance before security inspection takes place, users may experience higher latency and slower application performance. This becomes more noticeable for real-time services such as voice, video and cloud collaboration applications.
Traditional architectures often route traffic through a central data centre for inspection. A SASE architecture uses distributed PoPs to apply security controls closer to users and applications, reducing dependence on traffic backhauling.
When evaluating a SASE provider, organisations should focus on whether the provider's PoP locations align with:
User locations
Branch locations
Cloud regions
SaaS usage patterns
Data residency requirements
The number of PoPs is less important than their location. A provider may operate hundreds of PoPs globally, but if they are not close to where users, applications and cloud workloads operate, the potential benefits can be reduced.
For this reason, PoP placement should be considered an architectural requirement rather than a coverage statistic.
Consider an organisation with headquarters, regional branches, remote employees, contractors and applications distributed across SaaS platforms, public cloud environments and private infrastructure.
In a traditional architecture, most user traffic is routed through the data centre before reaching its destination. Branch offices depend on centralised security controls, remote users rely on VPN access, and SaaS traffic often follows indirect paths.
In a SASE architecture, access decisions are made closer to users and applications.
Branch offices use SD-WAN to connect to business applications across multiple locations.
Remote employees access SaaS and cloud services through distributed service edges.
Contractors receive application-specific access through ZTNA rather than broad network access.
Security policies are applied consistently regardless of whether the user is in a branch office, at home or travelling.
Access decisions are based on identity, device posture and risk rather than network location alone.
The same policy framework applies across users, devices and applications. Whether a user accesses a SaaS platform, a cloud-hosted workload or a private application, connectivity, security enforcement and policy remain aligned. This allows organisations to apply consistent access and security policies across distributed environments without relying on a central data centre as the primary control point.
| Dimension | Traditional Architecture | SASE Architecture |
| Traffic Flow | Often backhauled to a central data centre | Inspected and enforced through distributed service edges |
| Security Model | Perimeter and location-based | Identity, context and policy-based |
| Remote Access | VPN-centric | ZTNA-based access to private applications |
| SaaS Access | Traffic often routed through the data centre | Direct access with cloud-delivered security controls |
| Branch Security | Relies on branch and data centre appliances | Delivered through distributed PoPs and cloud security services |
| Policy Management | Multiple tools with separate policies | Centralised or closely integrated policy enforcement |
| Scaling | Dependent on physical infrastructure | Cloud-delivered and easier to scale across locations |
| User Trust | Based largely on network location | Based on identity, device posture and risk |
Most legacy architectures were designed around a central network perimeter. SASE shifts the focus to identity, policy and distributed enforcement. Instead of relying on where a user is connected from, access decisions are based on who the user is, what device they are using and the context of the session.
SASE is often described as a combination of SD-WAN and cloud-delivered security services. In practice, the architecture is defined less by the technologies it contains and more by how those technologies work together.
Throughout a user session, connectivity, security enforcement and policy operate as a single system. Identity is verified, device posture is evaluated, traffic is routed through the appropriate path, security controls are applied, and access decisions are continuously enforced based on context and risk.
When evaluating SASE, the most important question is not whether a provider offers SD-WAN, ZTNA, SWG, CASB or FWaaS. The more important question is whether those capabilities operate through a consistent architecture with unified policy enforcement across users, devices and applications.
That distinction separates a true SASE architecture from a set of networking and security tools operating independently.
Q1. How do enterprises handle data residency and compliance with SASE?
Organisations should evaluate where traffic is inspected, where logs are stored and whether provider PoPs align with regulatory and data residency requirements.
Q2. What are the biggest SASE rollout pitfalls in enterprises?
Common challenges include poor identity management, incomplete application discovery, inconsistent policies and attempting to migrate all users and applications at once.
Q3. Can organisations use SASE alongside existing network infrastructure?
Yes. Many organisations adopt SASE gradually while continuing to operate existing WAN, security and data centre infrastructure during the transition.
Q4. Does SASE require all traffic to pass through the cloud?
No. Traffic handling depends on architecture, policy and application requirements. Organisations can apply different routing and inspection policies to different traffic types.
Q5. How does SASE support application-specific access?
SASE uses identity, device posture and policy to determine which users can access specific applications, rather than relying solely on network location.