How SASE Architecture Works in Enterprise Networks
TABLE OF CONTENTS:
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:
- Who is the user?
- Is the device trusted?
- Which application is being accessed?
- Should the session be allowed?
- Where should traffic be inspected?
- What happens if risk changes during the session?
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.
Why Traditional Enterprise Architecture Breaks Down
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.
The Three Layers of SASE Architecture
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.
Connectivity Layer
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.
Security Enforcement Layer
The security enforcement layer applies security controls to traffic and access requests.
This commonly includes:
- ZTNA – Controls access to private applications based on identity, device posture and policy.
- SWG – Inspects and secures internet-bound traffic.
- CASB – Provides visibility and control over SaaS application usage.
- FWaaS – Applies cloud-delivered firewall policies and traffic filtering.
- DNS Security – Blocks access to known malicious or risky domains.
- Data Loss Prevention (DLP) – Helps prevent sensitive information from being shared or transferred inappropriately.
The purpose is not simply to inspect traffic. It is to apply the right security controls based on identity, application, device posture, and risk.
Policy Layer
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.
End-to-End Example: A user accessing a SaaS collaboration platform
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.
Step 1: Identity is verified
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.
Step 2: Multi-factor authentication is applied
If required by policy, the user completes multi-factor authentication. This provides additional verification before access decisions are made.
Step 3: Device posture is evaluated
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.
Step 4: Traffic reaches a SASE Service Edge
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.
Step 5: The policy engine evaluates context
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.
Step 6: Security controls are applied
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
Step 7: Access is granted
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.
Step 8: Monitoring continues throughout the session
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.
Step 9: The session ends
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.
How SASE Components Work Together
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.
Why Points of Presence Matter
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.
Enterprise SASE Architecture Example
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.
SASE Architecture vs Traditional Network Architecture
| 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.
Conclusion
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.
Frequently Asked Questions (FAQs)
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.
