SASE architecture explained: components, data flow and deployment models

What is SASE architecture?

SASE (Secure Access Service Edge) is a cloud-native architecture that converges networking and security into a single platform. Instead of routing traffic through a central data centre for inspection, SASE moves policy enforcement to distributed cloud nodes close to users and applications. The result: faster connections, consistent security regardless of location, and one console instead of a dozen. Gartner defined the framework in 2019. By 2026, it has become the default architecture for organisations that need secure connectivity across offices, remote workers, cloud applications and connected devices.

SASE architecture combines five core security and networking functions, enforces policy at distributed Points of Presence, and separates the control plane from the data plane so that rules are defined once but applied everywhere. For mid-market organisations running 50 to 400 users across multiple sites, it replaces the complexity of managing separate firewalls, VPN concentrators, web gateways and SD-WAN appliances with a unified, cloud-managed service.

This guide explains how the architecture works from the ground up. You will learn what each component does, how data actually flows through the system, which deployment models exist, where Points of Presence fit in, how SASE differs from SSE, and what European organisations need to consider around data sovereignty and NIS2 compliance.

The core components of SASE architecture

SASE combines networking and security functions that were traditionally delivered by separate appliances and vendors. Gartner’s original 2019 definition identified five core components. The 2025-2026 landscape has expanded that set, but these five remain the foundation.

SD-WAN: the networking layer

Software-Defined Wide Area Networking handles connectivity between branch offices, data centres, cloud environments and remote locations. SD-WAN abstracts routing intelligence into software, replacing static MPLS configurations with dynamic path selection across broadband, MPLS, 4G/5G or any combination. A central controller pushes policies to lightweight edge devices at each site. Those devices build encrypted overlay tunnels, measure link quality in real time, and route traffic based on application priority and network conditions. The practical difference for IT teams: faster site deployments, lower transport costs, and a single place to manage connectivity across all locations. For a deeper look at how SD-WAN works, see the complete SD-WAN guide for 2026.

ZTNA: identity-based access

Zero Trust Network Access replaces VPN tunnels with granular, per-application access. Users authenticate, their device posture is checked, and they receive access only to the specific applications their role requires. A finance team member reaches the billing system. A clinician reaches the electronic health record. Neither can see the other’s applications, and neither joins a broad network segment. This is the core difference from VPN: ZTNA never grants network-level access, only application-level access. Lateral movement becomes structurally impossible. In Jimber’s platform, ZTNA is the default access method. Zero Trust is built in, not bolted on as an optional module.

SWG: web security at the edge

The Secure Web Gateway inspects and filters all web-bound traffic. It enforces acceptable use policies through URL categorisation, blocks known malicious domains, and performs TLS inspection where policy allows. In a SASE architecture, SWG policies follow users regardless of location. An employee browsing from a hotel room in Barcelona gets the same protection as someone at the office in Brussels. For organisations moving beyond simple block lists, SWG metrics that actually indicate security posture matter more than headline block rates.

FWaaS: cloud-delivered firewall

Firewall-as-a-Service moves firewall capabilities from on-premises appliances to the cloud. It provides deep packet inspection, intrusion prevention, application control and port/protocol filtering, all delivered as a managed service. FWaaS eliminates the need to deploy, patch and manage physical firewall hardware at every location. Policies are defined centrally and enforced at the nearest Point of Presence. For mid-market organisations with multiple sites, this alone can cut weeks of deployment time and significant hardware costs from every new location.

CASB: cloud application control

The Cloud Access Security Broker discovers and controls the use of SaaS applications. It operates in two modes. Inline mode inspects traffic in real time as users access cloud services, enforcing DLP policies, blocking unauthorised file sharing, and detecting anomalous behaviour. API mode connects directly to SaaS platforms like Microsoft 365 or Salesforce to scan data at rest, check sharing permissions, and enforce compliance rules. CASB is the component that makes shadow IT visible. Without it, IT teams have no reliable way of knowing which cloud services employees actually use.

Expanded components in 2025-2026

Modern SASE platforms have grown beyond the original five. Common additions include Remote Browser Isolation (RBI), which executes website code in a cloud container so no active content reaches the endpoint. Data Loss Prevention (DLP) scans for sensitive data patterns across all traffic. Digital Experience Monitoring (DEM) measures end-to-end performance from user device to application. DNS security filters malicious domains before connections are established. Some vendors also integrate endpoint detection capabilities, though this varies significantly by platform.

How data flows through a SASE architecture

This is the part most vendor content skips. Understanding what actually happens to a packet as it moves through the system makes the difference between evaluating marketing claims and evaluating architecture.

SASE separates the control plane from the data plane. The control plane is where policies live. A centralised, cloud-hosted controller holds the complete picture of your network topology, user identities, device posture rules and security policies. When you define a rule that says “grant the finance team access to the ERP system only from managed devices with disk encryption enabled”, that instruction lives in the control plane and gets pushed to every enforcement point. The data plane is where packets actually move. Distributed Points of Presence handle the physical work of receiving traffic, inspecting it, and forwarding it to its destination.

Step 1: connection establishment

The user’s device, running a lightweight SASE agent, connects to the nearest Point of Presence via an encrypted tunnel. For branch offices, an SD-WAN appliance establishes this tunnel. For agentless devices like printers, sensors or industrial equipment, a dedicated inline isolation appliance such as Jimber’s NIAC forwards traffic on their behalf.

Step 2: identity and device verification

The PoP verifies the user’s identity through SSO/IdP integration using SAML or OIDC protocols. Device posture is checked simultaneously: is the OS current? Is disk encryption active? Is endpoint protection running? Is the device managed or registered? Context is gathered: location, time of day, network type. All of these signals feed into the access decision.

Step 3: Zero Trust policy evaluation

The ZTNA engine evaluates whether this specific identity, on this specific device, in this specific context, has permission to access the requested resource. Access is granted per application using least-privilege principles. The user never joins a network segment. They reach only the application the policy permits.

Step 4: single-pass security inspection

This is where SASE architecture differs most from legacy approaches. Traffic is decrypted once, then inspected simultaneously by all security engines: NGFW/FWaaS for port, protocol and application rules. SWG for URL categorisation and web threats. IPS for known attack signatures. Anti-malware for file scanning. DLP for sensitive data patterns. CASB for cloud application policies. DNS security for domain reputation. After inspection, traffic is re-encrypted once.

Legacy architectures “service-chained” these functions, decrypting and re-encrypting traffic at each step. Five tools in sequence meant five decrypt-inspect-encrypt cycles, each adding latency. Single-pass inspection eliminates this overhead entirely.

Step 5: optimised routing

Inspected traffic routes to its destination via the most efficient path. SaaS application traffic exits at the PoP closest to the provider’s region, avoiding the backhaul that makes legacy VPN architectures slow. Data centre traffic routes over the vendor’s backbone. Internet traffic breaks out directly from the PoP.

Step 6: logging and analytics

Every session generates a log entry: user identity, device posture result, application accessed, security verdict, data transferred, session duration. All of this feeds into a unified data lake. For organisations operating under NIS2, this centralised logging is not optional. It is the audit trail that proves proportionate access controls and incident containment capability.

How data flow varies by traffic type

Not all traffic follows the same path. The architecture handles three fundamentally different scenarios.

Remote user to SaaS application. An employee in Brussels opens a CRM hosted in Frankfurt. Their SASE agent connects to the nearest PoP. Identity and device posture are verified. SWG, CASB and DLP inspect the traffic in a single pass. Traffic exits at the PoP closest to the SaaS provider. Total latency: roughly 12ms. The same connection through a legacy VPN architecture, backhauled through a central data centre, would add 80-120ms.

Branch office to data centre. An SD-WAN appliance at a branch site routes traffic through an encrypted tunnel to the nearest PoP. The SASE platform applies application-aware QoS classification, giving priority to real-time traffic like voice and video over background tasks. Full security inspection happens at the PoP. Traffic then routes over the vendor’s backbone to the PoP nearest the data centre, and exits to the destination.

Agentless device to cloud. A connected printer, IoT sensor or industrial PLC cannot run a SASE agent. It connects to the local network, where a dedicated network isolation appliance forwards its traffic. Jimber uses NIAC hardware for this purpose, placing each device behind an inline isolation layer that controls exactly which upstream systems it can reach. The device is identified through AI-driven fingerprinting based on MAC address, traffic patterns and DPI signatures. Microsegmentation policy restricts the device to communicating only with its designated upstream systems. Behavioural baselining monitors for anomalies. If the device starts attempting connections outside its permitted flows, access is restricted immediately.

This third scenario is the one most vendor content ignores. But for organisations running manufacturing equipment, building management systems, medical devices or any environment with agentless hardware, it is the most important data flow to understand. It is also where Jimber’s architecture differs most from competitors: NIAC is a purpose-built component, not an afterthought layered onto an agent-first design.

The role of Points of Presence in SASE

Points of Presence are the distributed cloud nodes where the SASE stack runs. Each PoP typically contains multiple compute nodes for redundancy, the full security inspection stack, SD-WAN routing intelligence, connections to tier-1 ISPs and internet exchange points, and peering arrangements with major cloud providers.

PoP count is the metric vendors highlight most. Large US vendors claim anywhere from 85 to 330+ PoPs globally. But raw PoP count is misleading. Research from major SASE vendors themselves shows that PoP proximity accounts for roughly 5% of end-to-end latency. Application-side latency and middle-mile routing contribute far more. Independent reviews have also found that some vendors’ claimed PoP counts do not reflect the number actually usable per customer. What matters is not how many PoPs a vendor operates globally, but whether they have dense coverage in the regions where your users and applications live, and whether those PoPs process traffic under the right legal jurisdiction.

For European organisations, this means asking specific questions. Where are the PoPs in the Benelux, DACH and Nordics regions? Are security inspections, including TLS decryption, performed within EU borders? Where are logs stored? Who operates the infrastructure, and under which jurisdiction’s laws? A European-headquartered provider like Jimber answers these questions by default: traffic stays within EU jurisdiction because the company and its infrastructure operate under EU law.

SASE deployment models

There is no single way to deploy SASE. The architecture supports several models, each with trade-offs that matter depending on organisational size, existing investments, and compliance requirements.

Single-vendor SASE

One vendor delivers both the networking (SD-WAN) and security (SSE) components as a unified platform. Benefits include a single management plane, a single data model, consistent policy enforcement, and no integration complexity between vendors. The trade-off is vendor lock-in risk and the reality that no single vendor leads in every capability.

Gartner projects that 50% of new SASE deployments will be single-vendor by 2028, up from roughly 30% in 2025. However, current adoption data shows only about 17% of enterprises use a single vendor today, with 58% still relying on three or more vendors. The gap between aspiration and reality is wide.

For mid-market organisations, single-vendor SASE has a distinct advantage: simplicity. With two to five IT staff managing the entire environment, the operational overhead of coordinating multiple vendors is proportionally much higher than it is for enterprise teams with dedicated networking and security groups. Single-vendor platforms also tend to deploy faster, which matters when the alternative is a multi-month integration project. Jimber’s platform is built around this principle: ZTNA, SWG, FWaaS, SD-WAN and device posture in one console, with deployment timelines measured in weeks rather than quarters.

Dual-vendor SASE

SD-WAN from one vendor plus SSE from another, integrated via APIs and tunnels. This is common among organisations that already invested in SD-WAN and want to add cloud security without ripping out existing infrastructure. The approach offers flexibility and best-of-breed capability selection. The trade-off is separate management planes, more complex troubleshooting, and the risk of inconsistent policy enforcement between the two platforms.

Managed SASE via service partners

A service partner designs, deploys and operates the SASE architecture on behalf of the customer. Industry data shows that over 80% of organisations rely on external partners for SASE implementation. For mid-market organisations with limited internal capacity, this model delivers faster time-to-value and reduces the staff burden of operating the platform day to day.

The trade-off is reduced direct control and dependency on the partner’s expertise. Choosing a platform built for multi-tenant operations, with transparent pricing and clear partner tooling, mitigates this risk significantly. Jimber’s architecture is partner-first by design: multi-tenant management, API-first automation, and a pricing model that gives service partners predictable margins across their entire customer base.

Hybrid SASE

Combines cloud-delivered SASE with on-premises appliances for specific use cases. This is the fastest-growing segment, driven by organisations that need local enforcement for OT environments, data sovereignty requirements, or air-gapped networks. Hybrid deployments are increasingly common in manufacturing, healthcare and critical infrastructure, where certain traffic cannot leave a facility.

SASE vs SSE: the architectural difference

SSE (Security Service Edge) is the security-only subset of SASE. It includes SWG, CASB, ZTNA and FWaaS, but does not include SD-WAN. Gartner introduced the SSE category in 2021 and publishes separate Magic Quadrants for SSE and for SASE Platforms.

The distinction matters for one practical reason. SSE secures traffic but does not manage how that traffic reaches the security stack. If your organisation already has a functioning SD-WAN deployment and simply needs to add cloud-delivered security, SSE may be sufficient. If you are replacing aging MPLS infrastructure, starting fresh, or want a single management plane across both remote users and branch offices, full SASE is the more complete answer.

Gartner’s long-term direction favours full convergence. The rationale: networking decisions and security decisions are increasingly the same decision. Routing traffic efficiently and inspecting it consistently require the same context about users, devices and applications. Separating these functions into different platforms reintroduces the integration complexity that SASE was designed to eliminate. For a detailed breakdown of how SASE, SSE and SD-WAN relate, see the SASE vs SSE vs SD-WAN comparison.

European considerations: data sovereignty and NIS2

European organisations evaluating SASE architecture face two questions that most vendor content does not address. Both have architectural implications, not just compliance implications.

Where does TLS inspection happen?

SASE platforms terminate TLS connections at their Points of Presence. That means traffic is decrypted, inspected, and re-encrypted on vendor-operated infrastructure. If those PoPs are operated by a US-headquartered company, that data may be subject to the US CLOUD Act regardless of where the PoP is physically located. A PoP in Frankfurt operated by an American vendor does not automatically provide European data sovereignty.

This is not a theoretical concern. GDPR Article 32 requires appropriate security measures, and inspecting encrypted traffic for threats is a legitimate and arguably necessary security measure. But the same regulation requires that personal data is processed lawfully and protected from unauthorised access. Running TLS inspection through infrastructure subject to foreign intelligence laws creates a tension that boards and DPOs increasingly want resolved.

Architecturally, the answer is SASE platforms operated by European-headquartered vendors, where traffic is processed, inspected and logged entirely within EU jurisdiction. This eliminates the CLOUD Act exposure while still enabling the security inspection that GDPR requires. Jimber, as a Belgian company, provides this by default. Traffic inspection, logging and policy enforcement happen within EU borders because the company itself operates under EU law. There is no secondary jurisdiction to worry about.

The broader market is catching up to this reality. Gartner projects that Europe will surpass North America in sovereign cloud spending by 2027. Several US-headquartered vendors have responded by launching “sovereign” product lines, but these are add-ons to architectures that were not designed with European data sovereignty as a starting point. For organisations where jurisdiction matters, the distinction between sovereignty-by-design and sovereignty-by-add-on is significant.

What does NIS2 require from your architecture?

NIS2 applies to organisations with 50 or more employees or over EUR 10 million in annual revenue operating in essential or important sectors. That directly overlaps with the mid-market segment where SASE adoption is growing fastest. Over 160,000 organisations across the EU are expected to fall within scope.

NIS2 Preamble 89 specifically references Zero Trust principles, making ZTNA a direct architectural response to a regulatory requirement, not just a security improvement. Beyond Zero Trust, NIS2 requires incident reporting within 24 hours (centralised SASE logging supports this), continuous security monitoring (DEM and analytics provide this), risk management with documented controls (unified policy management demonstrates this), supply chain security (SASE extends consistent policy to third-party access), and network segmentation (microsegmentation through ZTNA and inline isolation deliver this).

Jimber’s single-console approach makes NIS2 evidence collection practical for lean IT teams. Policy versions, access logs, device posture records and incident timelines all live in one platform, ready for export when the auditor calls. For a practical walkthrough of audit preparation, see the NIS2 compliance checklist for IT managers.

How Jimber approaches SASE architecture

Jimber delivers Real SASE in a single cloud-managed platform built for European mid-market organisations and the service partners that support them. The platform unifies ZTNA, SWG, FWaaS, SD-WAN, and device posture verification in one console. Policies are defined once and enforced consistently across remote users, branch offices, cloud applications and agentless devices.

Three architectural decisions set Jimber apart from the US-headquartered vendors that dominate the SASE market.

European data sovereignty is built into the architecture. As a Belgian SASE provider, Jimber processes, inspects and stores data within EU jurisdiction, eliminating CLOUD Act exposure by design, not by add-on.

Agentless device security is a first-class concern, not an afterthought. NIAC hardware provides inline isolation for printers, IoT sensors, building management systems and industrial equipment. These devices get their own microsegmented policies, behavioural monitoring and controlled communication flows, all managed from the same console as user access policies. For organisations with mixed IT and OT environments, this is the secure bridge between IT and OT that most SASE vendors simply do not address.

Transparent pricing removes the commercial barriers that stall mid-market adoption. Per-user pricing with no bandwidth surcharges, no hidden add-ons, and clear margin structures for service partners. This makes three-year TCO projections straightforward, as demonstrated by a Belgian wealth manager that cut security costs by 58% after replacing a fragmented stack with Jimber’s unified platform.

Ready to see how SASE architecture works in practice for your environment? Book a demo and get a customised walkthrough of the platform.

FAQ

What are the five core components of SASE?

The five components Gartner defined in 2019 are SD-WAN, Zero Trust Network Access (ZTNA), Secure Web Gateway (SWG), Firewall-as-a-Service (FWaaS) and Cloud Access Security Broker (CASB). Modern platforms in 2025-2026 typically add Remote Browser Isolation, Data Loss Prevention, Digital Experience Monitoring and DNS security.

How does SASE differ from SSE?

SSE (Security Service Edge) includes only the security components: SWG, CASB, ZTNA and FWaaS. SASE adds SD-WAN networking on top of SSE. If you need both secure connectivity between sites and cloud-delivered security for users, you need full SASE. If you already have a working SD-WAN and only need cloud security, SSE may suffice.

How does SASE secure devices that cannot run agents?

Devices like printers, IoT sensors and industrial equipment connect through a dedicated inline isolation appliance. Jimber’s NIAC hardware serves this exact purpose: it sits between the agentless device and the rest of the network, identifies devices through AI-driven fingerprinting, applies microsegmentation policies restricting them to only their designated communication flows, and monitors behaviour for anomalies. No software needs to be installed on the device itself. This makes NIAC a practical bridge between IT and OT environments without disrupting production.

Is SASE architecture suitable for mid-market organisations?

Yes. Mid-market adoption is growing faster than enterprise adoption, with industry data showing planned adoption growth of over 120% among SMBs and mid-market firms. Single-vendor SASE is particularly well suited for organisations with 50-400 users and small IT teams, because it eliminates the tool sprawl and integration complexity that consume disproportionate resources at that scale. Jimber’s platform is specifically designed for this segment: one console, transparent pricing, and deployment in weeks rather than the months-long projects typical of enterprise SASE vendors.

How long does SASE deployment take?

It depends on the model. Enterprise-scale dual-vendor deployments can take 12-18 months. Single-vendor SASE for mid-market organisations can go from initial configuration to protecting first users within days to weeks, with full rollout across all sites in 6-12 weeks. Jimber’s phased approach is typical: start with ZTNA for a pilot group, expand application coverage, then add SD-WAN for branch connectivity. A Belgian wealth management firm completed a full migration in eight weeks.

Does SASE replace firewalls?

SASE replaces the need for on-premises firewall hardware at branch locations. FWaaS delivers equivalent protection from the cloud with centralised management. Some organisations retain perimeter firewalls at data centres for specific north-south traffic controls during transition, but the long-term architectural direction is full consolidation into cloud-delivered security.

What should European organisations look for in a SASE provider?

Five criteria matter most. European PoP coverage with in-EU traffic inspection. Vendor headquarters jurisdiction, which determines legal exposure under the US CLOUD Act or similar foreign access laws. NIS2-aligned logging and reporting capabilities. GDPR-compliant TLS inspection with appropriate privacy controls. And transparent pricing that makes procurement straightforward for public sector and regulated industries. Jimber meets all five by design: Belgian-headquartered, EU-only data processing, centralised audit logging, and a predictable per-user pricing model.