TABLE OF CONTENTS:
|
1. Four Design Principles for SASE Architecture 2. Choosing the Right SASE Deployment and Rollout Model |
Building a SASE architecture is not only about adding cloud security tools to an existing network. It requires decisions about users, applications, traffic paths, identity controls, policy enforcement and Points of Presence.
Many organisations begin with separate WAN, VPN, firewall, web security and SaaS controls. This can make access inconsistent, increase operational effort and create performance issues when users and applications are distributed.
Secure Access Service Edge, or SASE, provides a cloud-delivered model for bringing networking and security closer together. This article explains how to build a SASE architecture for modern enterprise networks, from assessment and design decisions to phased implementation.
Four Design Principles for SASE Architecture
Building SASE architecture requires more than placing security tools in the cloud. The design should be based on how networking, identity, policy and visibility work together across users, branches and applications.
- Converged Networking and Security:
SD-WAN routing, access control and traffic inspection should be planned together rather than treated as separate projects. - Identity-Driven Access Control:
Access should be based on identity, device posture, role, application context and policy instead of network location alone. - Cloud-Delivered and Distributed Enforcement: Security inspection and policy enforcement should happen closer to users and applications where routing, performance and compliance requirements allow.
- Consistent Policy and Visibility Across Environments: Policies and visibility should remain consistent across users, branches, SaaS applications, cloud workloads and private applications.
These principles help prevent SASE from becoming another set of disconnected tools with a cloud label. They give the architecture a clearer basis for design, deployment and ongoing optimisation.
Choosing the Right SASE Deployment and Rollout Model
Before organisations build a SASE architecture, they need to separate two decisions: who delivers the architecture and how the architecture is rolled out. These decisions are related, but they are not the same.
A delivery model defines whether the organisation uses a single-vendor SASE platform, a dual-vendor approach that combines SD-WAN and SSE capabilities, or a managed SASE service. A rollout plan should then define two separate choices: whether implementation will be phased or full, and whether the operating model will be primarily cloud-delivered or hybrid with selected legacy infrastructure retained during migration.
Single-Vendor SASE
A single-vendor SASE model uses one provider for SD-WAN and cloud-delivered security services. This can simplify policy management, troubleshooting and vendor accountability because networking and security functions are more closely integrated.
The trade-off is reduced flexibility if the organisation has specialised requirements, existing investments or preferred tools that one provider does not cover.
Dual-Vendor SASE
A dual-vendor SASE model typically uses one provider for SD-WAN and another for Security Service Edge capabilities. This approach can help organisations retain existing investments or select stronger tools for specific networking and security requirements.
The trade-off is higher integration effort. Policy consistency, support ownership and troubleshooting responsibilities must be clearly defined so the architecture does not become another set of disconnected tools.
Managed SASE
A managed SASE model allows a service provider to support design, deployment or ongoing operation. This may suit organisations with limited internal networking or security resources, or teams that need help with migration, monitoring and optimisation.
The trade-off is that governance, visibility and control expectations must be agreed early. A managed service should reduce operational burden without reducing architectural control.
Rollout Plan: Timing and Operating Model
The rollout plan is separate from the delivery model. A SASE deployment can be single-vendor, dual-vendor or managed, and still be introduced in phases.
The first decision is timing: whether to roll out SASE in phases or move more broadly after validation. For most enterprises, a phased rollout is lower risk because users, applications, branches and traffic types can be migrated gradually.
The second decision is operating model: whether the architecture will be primarily cloud-delivered or hybrid during migration. A hybrid approach may retain MPLS, firewalls, VPNs, data centre applications or compliance-driven controls while SASE capabilities are introduced. The plan should define what stays, what moves first and when legacy controls can be retired.
How to Build a SASE Architecture: Key Steps
Building SASE architecture should follow a clear sequence. The goal is not to deploy every capability at once, but to create a controlled path from the existing network and security stack to a more integrated model. Each step should reduce uncertainty before the next stage begins.
Step 1: Assess the Existing Environment
Start with a clear assessment of the current environment. Without this baseline, SASE design decisions can easily be based on assumptions.
Assess:
- Existing WAN connectivity: MPLS, DIA, broadband, LTE, 5G, internet breakout locations and branch connectivity
- Application landscape: SaaS platforms, cloud workloads, private applications, legacy systems and business-critical applications
- Users and devices: office users, branch users, remote users, contractors, third-party users, privileged users and managed or unmanaged devices
- Security controls: VPN, firewalls, identity providers, endpoint protection, DLP, secure web gateways, cloud security tools and logging platforms
- Compliance and operational requirements: data residency, audit requirements, support processes, latency issues, circuit renewal timelines and regional privacy obligations in markets such as the UAE or Saudi Arabia where applicable
This step identifies what must change, what can remain temporarily and where migration risk exists.
Step 2: Define Business, Security and Architecture Objectives
After assessment, define what the architecture needs to achieve.
Common objectives include improving SaaS and cloud access, supporting hybrid and remote work securely, reducing reliance on broad VPN access, standardising security policies, reducing operational complexity, improving network and security visibility, modernising branch connectivity and meeting compliance requirements.
Avoid vague goals such as “improve security”. A stronger objective would be: “reduce broad VPN access by introducing application-specific ZTNA for remote users accessing private applications.”
Also define two separate decisions:
- Delivery model: single-vendor, dual-vendor or managed SASE service
- Rollout plan: whether implementation will be phased or full, and whether the operating model will be primarily cloud-delivered or hybrid with selected legacy components retained during migration
These are different decisions. A phased rollout can still be single-vendor, dual-vendor or managed.
Step 3: Map Access Requirements
Use the Step 1 inventory to define access requirements. Do not re-inventory users and devices here.
Define which users need access to which applications, which applications are SaaS, private, internet-facing or cloud-hosted, which devices should be trusted or restricted, which applications contain sensitive data, which workloads require low latency, which users need temporary or third-party access, which applications should move first and which access paths must remain unchanged during migration.
This turns the inventory into an access model.
Step 4: Design SD-WAN Connectivity and Traffic Routing
Next, design how traffic should move. Decide how headquarters, branch offices and remote locations will connect, where internet traffic should exit the network, what role MPLS, DIA, broadband, LTE or 5G will play, which applications require low latency or stronger resilience, and how traffic should behave during link, PoP or application performance issues.
SD-WAN should support application performance while aligning with inspection and policy enforcement.
Step 5: Select PoPs and Define the Enforcement Model
PoP planning should happen before broad integration of cloud-delivered security services because those services depend on enforcement locations and routing behaviour.
Evaluate user geography, branch locations, SaaS and cloud destinations, private application locations, latency requirements, resilience, data residency and compliance obligations.
The key question is not “how many PoPs does the provider have?” It is whether the PoP footprint aligns with the organisation’s users, applications and compliance requirements.
Step 6: Define Identity, Access and Security Policies
Core access and security policies should be defined before broad deployment of ZTNA, SWG, CASB, FWaaS or DLP.
Identity policies should define MFA, SSO, device posture, user roles, privileged access, third-party access and least privilege rules. Where supported, session risk signals can also be used to adjust access decisions.
Also define which users can access which applications, which applications require ZTNA, which SaaS applications require CASB controls, which applications need stricter inspection, and what web access, firewall, DLP, logging and monitoring policies are required.
This ensures the SASE rollout is driven by policy, not by individual tool configuration.
Step 7: Run a Pilot
Pilot deployment should be part of the main build sequence, not a side activity.
A pilot may involve one branch, one department, a limited remote user group, a selected SaaS application, a selected private application or one geography.
Validate authentication, MFA and SSO, device posture, application access, user experience, traffic routing, security policy enforcement, logs and reporting, rollback process and support workflow.
Fix issues before broader rollout.
Step 8: Roll Out SASE Capabilities in Phases
After the pilot, expand in stages. Rollout may include ZTNA for private application access, SWG for web traffic, CASB for SaaS governance, FWaaS for firewall enforcement, DLP for data protection, SD-WAN expansion and PoP-based policy enforcement.
Rollout can be phased by branch, region, user group, application type, department or traffic category.
During this phase, legacy systems and SASE controls may run in parallel. Some users may remain on VPN while others move to ZTNA. Some branches may stay on MPLS while others use SD-WAN. This reduces disruption.
Step 9: Monitor, Optimise and Refine
SASE should not be treated as a one-time deployment. User behaviour, application usage, policy needs and network conditions should be reviewed regularly.
Monitor application performance, user experience, network latency, security events, policy effectiveness, user activity, device compliance, routing behaviour and PoP performance.
Use these insights to refine routing, access policies, security rules and rollout priorities.
Building an effective SASE architecture requires careful planning around networking, security, and cloud adoption. For a deeper understanding of the core principles and business benefits, explore our comprehensive SASE Guide for Enterprises and Growing Businesses.
Common Mistakes When Building a SASE Architecture
Building a SASE architecture fails most often when organisations treat it as a tool rollout instead of an architectural change.
- Treating SASE as a product: Buying a SASE-branded platform without architecture, policy and rollout planning can create another disconnected stack.
- Designing networking and security separately: SD-WAN, access control and inspection must be planned together, otherwise routing and security decisions can conflict.
- Selecting PoPs too late: PoP location affects latency, routing, inspection and compliance, so it should be reviewed before broad security service integration.
- Defining policies after deployment: ZTNA, SWG, CASB, FWaaS and DLP need a clear policy model before rollout, not after tools are configured.
- Migrating everything at once: A large cutover increases disruption risk. Pilot first, validate the design, then expand by user group, branch, region or application.
- Ignoring identity design: MFA, SSO, device posture, user roles, privileged access and third-party access should be defined early.
- Overlooking legacy applications: Some legacy systems may need specific routing, protocol handling, authentication or temporary VPN access during migration.
Conclusion
Building a SASE architecture should start with assessment, not product selection. Organisations need to understand their users, applications, traffic paths, identity controls, enforcement locations and existing infrastructure before deciding how to deploy SASE.
A strong architecture brings networking and security together through Converged Networking and Security, Identity-Driven Access Control, Cloud-Delivered and Distributed Enforcement, and Consistent Policy and Visibility Across Environments. The rollout should be phased, validated through a pilot and refined as users, applications and risks change.
If your organisation is evaluating SASE architecture, speak with Orixcom’s enterprise networking team to assess your current environment, identify the right deployment approach and plan a SASE solution aligned with your business, technical and security requirements.
Frequently Asked Questions
How is SASE architecture different from traditional network security?
Traditional network security often depends on centralised data centres, VPNs and separate appliances. SASE architecture brings networking and security closer together through cloud-delivered services, identity-driven access, distributed enforcement and consistent policy control across users, devices and applications.
What are the four SASE architectural requirements?
The four commonly cited SASE architectural characteristics are identity-driven access, cloud-native architecture, support for all edges, and global distribution through Points of Presence. In this article, these are translated into practical design principles: converged networking and security, identity-driven access control, cloud-delivered and distributed enforcement, and consistent policy and visibility.
What is the right SASE architecture for our organisation?
The right SASE architecture depends on your users, applications, branch locations, cloud footprint, compliance requirements, existing WAN, identity maturity and operational capacity. Organisations should assess these areas before choosing a single-vendor, dual-vendor or managed SASE model.
Which SASE component should be implemented first?
There is no universal starting point. Some organisations begin with SD-WAN to modernise branch connectivity, while others start with ZTNA to reduce broad VPN-based access. The first component should be based on the most urgent access, performance or security gap identified during assessment.
