NIST SP 800-207: Zero Trust Architecture · Zscaler SASE Overview · Netskope SASE Overview

Enterprise networks were traditionally built around a relatively simple assumption: users, applications, and data were located inside a trusted corporate perimeter.

Employees worked from offices. Applications ran in company-owned data centers. Internet traffic exited through centralized firewalls and proxy servers. Remote users connected back to the corporate network through a virtual private network, or VPN.

That architecture is increasingly mismatched with how modern organizations operate.

Users connect from homes, hotels, mobile networks, branch offices, and third-party locations. Applications may be distributed across Microsoft 365, Salesforce, AWS, Azure, private data centers, and hundreds of other SaaS platforms. Sensitive data moves between endpoints and cloud applications without necessarily passing through a traditional corporate network.

Secure Access Service Edge, commonly called SASE, is an architectural response to this change.

SASE combines cloud-delivered security services with software-defined networking capabilities. Its goal is to provide secure and reliable access between users, devices, branches, workloads, applications, and data regardless of where those resources are located.

Platforms such as Zscaler and Netskope are commonly associated with SASE because they provide globally distributed cloud enforcement platforms that can inspect traffic, apply identity-aware security policy, protect data, and broker access to private applications.

However, SASE is not simply a cloud proxy, a new VPN product, or a collection of security licenses.

It represents a larger architectural shift:

Security policy moves away from a small number of centralized corporate perimeters and toward distributed, identity-aware enforcement points located closer to users, applications, and data.

This article explains that architecture from a network and security engineering perspective.

The Problem SASE Is Trying to Solve

Consider a traditional enterprise internet access path:

Remote User
    |
    v
VPN Gateway
    |
    v
Corporate Data Center
    |
    +--> Firewall
    |
    +--> Web Proxy
    |
    +--> Intrusion Prevention
    |
    +--> Data Loss Prevention
    |
    v
Internet or SaaS Application

This design may provide centralized control, but it creates several challenges.

Traffic Backhauling

A user in another state or country may connect to a corporate VPN gateway, send traffic through a centralized data center, and then access a SaaS application hosted near the user's original location.

The traffic path may look like this:

User in California
    |
    v
VPN Gateway in Virginia
    |
    v
Security Stack in Virginia
    |
    v
SaaS Application in California

This adds unnecessary latency and makes the corporate data center a performance bottleneck.

Excessive Network-Level Trust

Traditional VPNs frequently assign remote users an IP address on, or routed access to, the corporate network.

Even when access control lists are applied, the security model is still largely based on network connectivity. Once a device is connected, it may be able to discover internal DNS records, scan accessible subnets, communicate with multiple systems, or move laterally if the endpoint becomes compromised.

Appliance Sprawl

An organization may operate separate products for:

Remote-access VPN
Secure web gateway
URL filtering
Intrusion prevention
Cloud access security broker
Data loss prevention
Malware sandboxing
DNS security
Branch firewalls
WAN optimization
SD-WAN
Remote browser isolation
Private application access

Each product may have a separate management interface, logging format, policy engine, upgrade lifecycle, and support contract.

Inconsistent Security Policy

A user in an office may be protected by an on-premises firewall and proxy.

The same user at home may use a VPN.

A mobile device may connect directly to SaaS applications.

A contractor may use an unmanaged endpoint.

A branch office may have another firewall configuration entirely.

This creates policy gaps and makes it difficult to answer a basic security question:

Is the same data protection and threat policy being applied to the user regardless of location?

Cloud and SaaS Visibility

Traditional firewalls can often identify destinations and protocols, but SaaS applications require more detailed context.

For example, security teams may need to distinguish between:

A corporate Microsoft 365 tenant and a personal Microsoft account
Uploading versus downloading a file
A sanctioned cloud storage service and an unsanctioned one
Viewing a document and sharing it publicly
Entering source code into a generative AI platform
Accessing Salesforce through an approved account versus a personal account

SASE platforms attempt to combine network, identity, application, device, threat, and data context into a unified policy decision.

SASE, SSE, SD-WAN, and Zero Trust

These terms are closely related, but they are not interchangeable.

Secure Access Service Edge

SASE combines networking and security functions into a cloud-delivered architecture.

A simplified model is:

SASE = Security Service Edge + Software-Defined WAN

This is not a complete product definition, but it is a useful way to understand the architecture.

The networking side provides connectivity, path selection, branch integration, WAN optimization, and routing.

The security side inspects traffic, evaluates identity and device context, protects data, blocks threats, and controls access to applications.

Security Service Edge

Security Service Edge, or SSE, is the security-focused portion of SASE.

SSE commonly includes:

Secure Web Gateway
Cloud Access Security Broker
Zero Trust Network Access
Firewall as a Service
Data Loss Prevention
Threat protection
Remote Browser Isolation
DNS security
SaaS and cloud application controls

An organization can adopt SSE without replacing its existing SD-WAN platform.

For example, a company might continue using Cisco, Fortinet, Palo Alto, Juniper, Aruba, or another WAN platform while forwarding internet traffic to Zscaler or Netskope.

Software-Defined WAN

SD-WAN provides policy-based connectivity across multiple WAN transports.

These transports may include:

Broadband internet
MPLS
Dedicated internet access
LTE or 5G
Satellite
Private circuits
Cloud interconnects

An SD-WAN platform can select paths based on application, latency, jitter, packet loss, link availability, or business priority.

In a SASE architecture, SD-WAN can steer branch traffic toward cloud security enforcement points instead of backhauling everything through a central data center.

Zero Trust

Zero trust is a security strategy based on removing implicit trust from access decisions.

Network location alone should not determine whether a user or device is trusted.

A zero-trust decision may consider:

User identity
Authentication strength
Device ownership
Endpoint security posture
Operating system health
Encryption status
EDR status
User risk
Device risk
Application sensitivity
Data classification
Geographic location
Time of access
Previous behavior
Threat intelligence
Session behavior

SASE can provide a platform for implementing zero-trust principles, but SASE and zero trust are not the same thing.

A useful distinction is:

Zero trust describes how access decisions should be made. SASE describes an architecture through which networking and security services can be delivered.

Core Components of a SASE Architecture

A mature SASE deployment normally contains several security and networking functions.

Secure Web Gateway

A Secure Web Gateway, or SWG, controls user access to websites and internet-based applications.

Typical capabilities include:

URL filtering
Domain categorization
Reputation analysis
Malware scanning
File-type controls
Browser controls
Download restrictions
Upload restrictions
Phishing protection
DNS security
Sandbox analysis
TLS inspection
Application identification
User activity logging

A traditional SWG might run as a physical or virtual proxy in a data center.

A SASE-based SWG runs within the provider's distributed cloud infrastructure.

Cloud Access Security Broker

A Cloud Access Security Broker, or CASB, adds visibility and policy enforcement for cloud applications.

CASB is commonly implemented in two major modes.

Inline CASB

Inline CASB inspects traffic while the user interacts with a cloud application.

It can control actions such as:

Login
Upload
Download
Share
Post
Delete
Copy
Paste
Print
Sync
Create
Edit

Inline controls are useful for real-time enforcement.

For example:

User: Member of Engineering
Device: Corporate managed
Application: GitHub Enterprise
Action: Upload source code
Result: Allow

A different session may produce another result:

User: Member of Engineering
Device: Personal unmanaged laptop
Application: Personal cloud storage
Action: Upload source code
Result: Block

API-Based CASB

API-based CASB connects directly to a SaaS provider using an authorized API integration.

It may scan:

Existing files
Stored data
Sharing permissions
Public links
User configuration
Application configuration
Malware already present in cloud storage
Data that did not pass through an inline proxy

API-based CASB provides valuable visibility into data at rest, but it is not a complete replacement for inline inspection.

Zero Trust Network Access

Zero Trust Network Access, or ZTNA, provides identity- and policy-based access to private applications.

Private applications may be located in:

Corporate data centers
AWS VPCs
Azure virtual networks
Google Cloud VPCs
Kubernetes clusters
Private SaaS environments
Development networks
Acquired company environments

Traditional remote access often connects the endpoint to a network.

ZTNA attempts to connect the endpoint only to an authorized application.

Instead of granting access to an entire subnet such as:

10.20.0.0/16

ZTNA policy may grant access only to:

payroll.internal.example.com:443

or:

git.internal.example.com:22

This can reduce network discovery and lateral movement.

Firewall as a Service

Firewall as a Service, or FWaaS, applies network security policy from the SASE provider's cloud.

It can provide controls across ports and protocols rather than only HTTP and HTTPS.

Typical functions include:

Source and destination policy
Port and protocol controls
Application-aware filtering
Intrusion prevention
DNS controls
Egress filtering
Threat intelligence
Network logging
User-aware rules
Branch and roaming-user enforcement

FWaaS does not automatically eliminate every on-premises firewall.

Local firewalls may still be required for:

East-west segmentation
Data center boundaries
Industrial and operational technology
Inbound application publishing
Regulatory boundaries
Local survivability
Cloud workload segmentation
Network address translation
Specialized routing

Data Loss Prevention

Data Loss Prevention, or DLP, detects and controls sensitive information.

DLP policies may identify:

Credit card numbers
Social Security numbers
Customer records
Health information
Financial data
Source code
Intellectual property
Authentication credentials
Secrets and API keys
Documents with sensitivity labels
Exact database records
Fingerprinted documents
Images containing sensitive text

A SASE platform can apply DLP policy to web, SaaS, private application, and sometimes endpoint activity.

Possible policy actions include:

Allow
Block
Alert
Coach the user
Require justification
Encrypt
Quarantine
Place the session in read-only mode
Redirect the user
Isolate the browser session

Remote Browser Isolation

Remote Browser Isolation, or RBI, executes web content in an isolated environment rather than directly on the endpoint.

The user receives a visual or rendered representation of the website.

RBI can be useful for:

Uncategorized websites
Newly registered domains
High-risk destinations
Contractor access
Unmanaged devices
Potential phishing sites
Researching malicious infrastructure

It provides an alternative to simply allowing or blocking a website.

Digital Experience Monitoring

Digital experience monitoring measures the quality of a user's connection to applications.

It may track:

Endpoint health
Wi-Fi quality
DNS resolution time
Tunnel latency
Packet loss
Network path
Cloud enforcement-point latency
SaaS response time
Application response time
Authentication delay

This becomes important because SASE inserts a cloud service into the traffic path.

Security teams must verify that the platform is not only enforcing policy but also delivering an acceptable user experience.

A High-Level SASE Architecture

A common SASE traffic flow looks like this:

                        +----------------------+
                        | Identity Provider    |
                        | Entra ID / Okta / AD |
                        +----------+-----------+
                                   |
                                   v
+-------------+          +---------+----------+          +----------------+
| User Device |--------->| SASE Cloud Edge    |--------->| Internet / SaaS|
| Agent       |          |                    |          +----------------+
+-------------+          | Identity           |
                         | Device Posture      |          +----------------+
+-------------+          | SWG / CASB / DLP   |--------->| Private Apps   |
| Branch      |--------->| FWaaS / Threat     |          +----------------+
| GRE/IPsec   |          | ZTNA Broker        |
+-------------+          +---------+----------+
                                   |
                                   v
                         +---------+----------+
                         | SIEM / SOAR / SOC   |
                         +--------------------+

The cloud enforcement point acts as a policy enforcement location.

It receives traffic, associates it with an identity and device, determines the destination and application, evaluates policy, inspects permitted content, and forwards approved traffic.

Control Plane and Data Plane

Understanding the separation between control and data planes is important when troubleshooting SASE.

Control Plane

The control plane manages policy and configuration.

It may include:

Administrator portal
Policy database
Identity integrations
Certificate configuration
Application definitions
Device-posture configuration
Tenant settings
Logging configuration
Connector registration
Tunnel provisioning
SD-WAN orchestration

The control plane tells the platform what should happen.

Data Plane

The data plane handles actual user, branch, and application traffic.

It may include:

Cloud enforcement nodes
Proxy infrastructure
Tunnel gateways
ZTNA brokers
Private access connectors
SD-WAN gateways
Content inspection engines
Threat detection engines

The data plane performs the actual forwarding and inspection.

A user may be able to authenticate successfully against the control plane while still experiencing a data-plane failure.

For example:

The endpoint receives policy but cannot reach an enforcement point.
The user authenticates but the private connector cannot reach the application.
The branch tunnel is established but policy-based routing does not steer traffic into it.
The tunnel is healthy, but DNS resolves the application incorrectly.
The user reaches the cloud service, but TLS inspection fails because the endpoint does not trust the inspection certificate.

How Traffic Reaches the SASE Cloud

Before a SASE platform can inspect traffic, the organization must steer traffic into the provider's infrastructure.

This is one of the most important implementation decisions.

Endpoint Agent

An endpoint agent is commonly installed on managed laptops and mobile devices.

Examples include:

Zscaler Client Connector
Netskope One Client

The agent can:

Authenticate the user
Identify the device
Collect posture information
Receive policy
Select an enforcement point
Create an encrypted tunnel
Steer internet traffic
Steer private application traffic
Apply bypass rules
Report endpoint telemetry
Continue protection when the user leaves the office

The primary advantage is policy consistency for roaming users.

Potential challenges include:

Conflicts with VPN software
Conflicts with endpoint security products
DNS interception issues
Certificate deployment
Operating system compatibility
User switching
Captive portals
Local development environments
Performance complaints
Agent upgrade management

GRE Tunnel

A branch router or firewall can forward traffic to a SASE cloud using Generic Routing Encapsulation.

GRE is simple and efficient, but GRE itself does not encrypt traffic.

A common topology is:

Branch LAN
    |
    v
Router or Firewall
    |
    +== GRE Tunnel 1 ==> Primary SASE PoP
    |
    +== GRE Tunnel 2 ==> Secondary SASE PoP

Policy-based routing may direct web traffic toward the tunnels.

When using GRE, engineers should consider:

Public source IP registration
Redundant tunnels
Tunnel keepalives
Route failover
Source-IP preservation
MTU and fragmentation
TCP MSS adjustment
Asymmetric routing
NAT placement
IPv6 handling

Performing source NAT before traffic enters the tunnel may cause the SASE platform to see many users behind the same address, reducing reporting and policy granularity unless identity is provided through another mechanism.

IPsec Tunnel

IPsec provides encrypted connectivity between the branch device and the SASE provider.

A typical topology is:

Branch Firewall
    |
    +== IPsec Tunnel 1 ==> Primary SASE PoP
    |
    +== IPsec Tunnel 2 ==> Secondary SASE PoP

Important considerations include:

IKE version
Encryption proposals
Authentication method
NAT traversal
Rekey timers
Tunnel health monitoring
Dead-peer detection
Policy-based routing
Failover
MTU overhead
Route preference
Source identity
Traffic selectors

IPsec is useful when traffic must be encrypted before crossing the public internet.

PAC File or Explicit Proxy

A Proxy Auto-Configuration, or PAC, file tells supported applications when to use a proxy.

A simplified PAC decision might look like:

function FindProxyForURL(url, host) {
    if (isPlainHostName(host) || dnsDomainIs(host, ".internal.example.com")) {
        return "DIRECT";
    }

    return "PROXY proxy.example-sase.com:8080";
}

PAC files can be useful for browser-based traffic or environments where an endpoint agent cannot be deployed.

However, PAC designs can become difficult to manage because of:

Complex bypass lists
Application-specific proxy behavior
DNS dependencies
Browser caching
Unsupported non-browser protocols
Authentication behavior
Different operating-system proxy stacks

PAC files generally do not provide the same all-port visibility as an endpoint tunnel or FWaaS deployment.

SD-WAN Integration

An SD-WAN appliance can classify applications and steer traffic into SASE tunnels.

For example:

Microsoft 365
    -> Direct internet through SASE inspection

Private ERP
    -> ZTNA or private application tunnel

Voice traffic
    -> Direct internet with QoS

Untrusted web traffic
    -> Full SWG inspection

Data center replication
    -> Private WAN path

SD-WAN and SASE policy must be designed together.

A conflict between SD-WAN path selection and SASE steering can produce:

Traffic loops
Asymmetric paths
Incorrect source identity
Intermittent bypass
Unexpected backhauling
Tunnel flapping
Session resets

What Happens During an Internet or SaaS Request

Consider a managed employee opening a SaaS application.

Step 1: DNS Resolution

The endpoint resolves the application's hostname.

DNS may be handled by:

A public DNS resolver
Corporate DNS
The SASE client
A DNS security service
A split-DNS configuration
An internal resolver through ZTNA

DNS design matters because routing and security decisions may depend on the resolved destination.

Step 2: Traffic Steering

The endpoint agent, branch tunnel, PAC file, or SD-WAN device determines that the traffic should be sent to the SASE platform.

The traffic is encapsulated or proxied to an enforcement point.

Step 3: User and Device Association

The platform associates the connection with context such as:

User identity
Directory group
Device ID
Device ownership
Operating system
Endpoint posture
Source location
Branch
Public IP address
Authentication state

Step 4: Application Identification

The service determines whether the destination represents:

A website
A SaaS application
A cloud storage platform
A generative AI service
A software update
A collaboration application
An unknown destination
A private application

Application identification may use domain names, certificates, IP addresses, protocol behavior, HTTP metadata, and application-specific decoding.

Step 5: Policy Evaluation

The service evaluates relevant security rules.

A conceptual policy might look like:

IF user.group == "Finance"
AND device.managed == true
AND device.edr_status == "healthy"
AND application == "Workday"
THEN allow

A DLP policy might look like:

IF application.category == "Generative AI"
AND action == "upload"
AND content contains "Customer PII"
THEN block
AND notify user
AND create SOC event

Step 6: TLS Inspection

If inspection is enabled, the SASE platform decrypts the TLS session, examines the content, and then establishes a separate encrypted session to the destination.

This creates two TLS sessions:

Endpoint
   |
   | TLS Session 1
   v
SASE Inspection Service
   |
   | TLS Session 2
   v
Destination Server

Step 7: Security Inspection

The platform may perform:

URL filtering
Malware analysis
File inspection
Threat-signature matching
Sandbox submission
DLP scanning
SaaS activity control
Tenant restriction
Credential protection
Header analysis
Content classification

Step 8: Forwarding

If policy permits the request, the service forwards it to the destination.

The destination may see the public egress address of the SASE provider rather than the user's local public IP.

Step 9: Logging

The transaction may generate telemetry containing:

Timestamp
Username
Device
Source location
Destination
Application
URL category
Action
Policy name
File name
File hash
Threat result
DLP result
Bytes sent and received
Enforcement location
Session duration
Latency

This data can be exported to a SIEM, data lake, or security operations platform.

TLS Inspection in Detail

Most modern web and SaaS traffic is encrypted.

Without TLS inspection, a security platform may see the destination domain and connection metadata but not the full request, file, message, or data being transferred.

TLS inspection allows deeper security controls, but it is also one of the most operationally sensitive parts of a SASE deployment.

Certificate Trust

The endpoint must trust a certificate authority used by the SASE platform.

When the user connects to:

https://example.com

the SASE service dynamically presents a certificate for example.com signed by the organization's inspection CA.

The endpoint accepts that certificate only if the inspection CA is trusted.

Certificates are commonly distributed using:

Microsoft Group Policy
Microsoft Intune
Jamf Pro
Mobile device management
Endpoint-management software
Golden images
Configuration-management systems

Certificate Pinning

Some applications do not trust certificates solely through the operating-system trust store.

They expect a specific certificate, public key, or issuing chain.

When a SASE platform substitutes an inspection certificate, a certificate-pinned application may reject the connection.

The organization may need to bypass TLS inspection for that application.

A bypass should be as narrow as possible.

A poor bypass policy might exempt an entire large cloud provider.

A better policy might exempt only the specific application hostname or process that requires it.

Privacy and Compliance

Not every category of traffic should necessarily be decrypted.

Organizations often consider bypassing categories such as:

Personal banking
Personal healthcare
Government services
Legal services
Employee benefits
Certain authentication services

The final policy depends on legal, regulatory, security, and employee-privacy requirements.

TLS and Application Compatibility

Engineers must test:

TLS 1.2 and TLS 1.3
HTTP/2
HTTP/3 and QUIC
Mutual TLS
Client certificates
Certificate pinning
WebSockets
Long-lived sessions
Software update services
Developer package managers
API clients
Mobile applications

The goal should not be to create a large permanent bypass list.

The goal should be to identify why an application fails, document the risk, and implement the narrowest safe exception.

How Private Application Access Works

Private application access is one of the most important SASE use cases.

Traditional VPN architecture might look like this:

Remote User
    |
    v
Internet-Facing VPN Gateway
    |
    v
Corporate Network
    |
    v
Multiple Internal Applications

ZTNA changes the design:

User Device
    |
    v
Cloud ZTNA Broker
    ^
    |
Outbound Connector
    |
    v
Specific Private Application

The private application connector is deployed near the application.

It typically requires:

Outbound internet connectivity
DNS resolution
Connectivity to the private application
Registration with the SASE tenant
High availability
Monitoring
Sufficient CPU, memory, and network capacity

Because the connector initiates outbound communication, the organization does not need to expose an inbound VPN listener or directly publish the private application to the internet.

Example Private Application Policy

Assume the organization has an internal payroll application:

payroll.internal.example.com:443

A policy could require:

User group: Payroll-Administrators
Authentication: Phishing-resistant MFA
Device: Corporate managed
Disk encryption: Enabled
EDR: Healthy
Country: United States
Risk score: Low or medium
Application: payroll.internal.example.com
Port: 443

A user outside that policy should not receive general network access.

The user should only receive a connection to the authorized application.

Application Segmentation

Private applications are commonly grouped into logical segments such as:

Finance-Applications
Engineering-Applications
Infrastructure-Administration
Production-Servers
Development-Tools
Human-Resources
Acquisition-Environment

Policies can then map identities to application groups.

This is easier to manage than writing individual rules for every user and every server, but groups should not become excessively broad.

DNS Considerations

Private applications frequently depend on internal DNS.

The design must determine:

Whether the endpoint resolves the private name
Whether the SASE client intercepts the query
Whether the connector resolves the name
Which DNS suffixes are considered private
Whether overlapping namespaces exist
Whether split-horizon DNS is used
Whether acquired companies use conflicting domains
Whether IPv4 and IPv6 answers are supported

DNS errors are frequently misdiagnosed as ZTNA tunnel or access-policy failures.

Connector High Availability

Private access connectors should normally be deployed in pairs or larger groups.

A connector failure should not make the application unavailable.

Connectors should be distributed across:

Availability zones
Hypervisor hosts
Data center failure domains
Cloud subnets
Power domains

The connector group should also have sufficient access to every application assigned to it.

Zscaler Architecture

Zscaler organizes its SASE and zero-trust capabilities around the Zscaler Zero Trust Exchange.

Several major components are commonly encountered.

Zscaler Internet Access

Zscaler Internet Access, or ZIA, protects internet and SaaS traffic.

Capabilities may include:

Secure web gateway
URL filtering
Cloud firewall
TLS inspection
Threat protection
Malware sandboxing
CASB
SaaS controls
Data loss prevention
DNS security
Browser isolation
Logging and analytics

Traffic can be forwarded to ZIA through methods such as:

Zscaler Client Connector
GRE tunnels
IPsec tunnels
PAC files
Explicit proxy
Cloud and workload connectors
SD-WAN integrations

Zscaler Private Access

Zscaler Private Access, or ZPA, provides zero-trust access to private applications.

The main components include:

Zscaler Client Connector on the endpoint
ZPA cloud infrastructure
App Connectors deployed near private applications
Application segments
Server groups
Segment groups
Access policies
Posture profiles
Identity provider integration

App Connectors initiate outbound TLS connections to the ZPA cloud and do not need to accept inbound internet connections.

The platform brokers access between an authorized user and an authorized private application.

Zscaler Client Connector

Zscaler Client Connector is the endpoint software used to steer traffic and provide device context.

It can support services such as:

ZIA
ZPA
Zscaler Digital Experience
Posture assessment
Traffic forwarding
Trusted-network detection
Authentication
Policy retrieval

Forwarding profiles determine how traffic should be handled in different network environments.

For example:

On corporate network:
    Internet traffic -> Branch GRE tunnel
    Private apps -> ZPA
    Local printers -> Bypass

Off corporate network:
    Internet traffic -> Client Connector tunnel
    Private apps -> ZPA
    Local LAN -> Limited bypass

Zscaler App Connectors

App Connectors are deployed in the data center, cloud, or application environment.

Their purpose is to provide the private side of a ZPA connection.

An App Connector must be able to:

Reach the ZPA cloud using outbound connectivity
Resolve required DNS names
Reach the private applications assigned to it
Receive configuration from the ZPA service

App Connectors should be deployed redundantly.

Zscaler Digital Experience

Zscaler Digital Experience, or ZDX, adds experience monitoring.

It can help determine whether a performance problem is associated with:

The endpoint
Wi-Fi
DNS
The internet provider
The Zscaler path
A SaaS provider
A private application
An application connector
The application's backend

Zscaler Branch and SD-WAN Capabilities

Zscaler also provides branch and SD-WAN capabilities intended to extend its zero-trust model to offices, campuses, devices, and workloads.

The architecture emphasizes connecting users and devices to authorized applications rather than creating broad routed connectivity between every site.

Netskope Architecture

Netskope delivers SASE and SSE capabilities through the Netskope One platform and its NewEdge network.

Netskope One Client

The Netskope One Client can steer endpoint traffic for:

Internet access
SaaS access
Private application access
Cloud firewall inspection
Data protection
Endpoint-related controls
User coaching
Endpoint SD-WAN use cases

Steering configuration determines what traffic is sent to the Netskope cloud and what traffic is bypassed.

Netskope One Next Gen Secure Web Gateway

The Next Gen Secure Web Gateway provides inline protection for web and cloud traffic.

It combines traditional web controls with detailed cloud application awareness.

Capabilities may include:

URL filtering
Threat protection
File inspection
Application discovery
SaaS activity recognition
Instance awareness
Tenant restrictions
DLP
User coaching
Risk-based controls

Netskope One CASB

Netskope's CASB capabilities provide visibility and control for managed and unmanaged cloud applications.

Policy can use context such as:

User
Device
Application
Application instance
Activity
Data
Risk
Destination
Device classification

This makes it possible to distinguish between similar-looking transactions.

For example:

Allow:
Corporate user uploads a file to the corporate OneDrive tenant.

Block:
The same user uploads the same file to a personal OneDrive tenant.

Netskope One Firewall

Netskope One Firewall provides cloud-delivered firewall controls for outbound traffic across ports and protocols.

This extends enforcement beyond browser traffic.

Netskope Private Access

Netskope Private Access provides access to private applications without exposing the broader private network.

Major components include:

Netskope One Client
Netskope cloud private-access infrastructure
Private Access Publishers
Private application definitions
Identity and device policy
Encrypted client-to-publisher communication

Publishers are deployed near private applications and require outbound access to Netskope services and network access to the applications they serve.

Netskope NewEdge

NewEdge is Netskope's globally distributed security network.

It provides the infrastructure through which traffic inspection, application access, and security policy are delivered.

From an engineering perspective, important validation points include:

Distance to the selected enforcement point
Network peering
Round-trip latency
Packet loss
Regional availability
Failover behavior
Egress IP requirements
Application performance

Netskope GRE and IPsec Steering

Branches can steer traffic through GRE or IPsec tunnels.

GRE is useful for efficient forwarding but does not provide native encryption.

IPsec provides encrypted forwarding.

For both methods, engineers should validate:

Primary and backup tunnels
Policy-based routing
Source IP preservation
Tunnel monitoring
MTU
Failover
Certificate deployment
Identity association
Cloud firewall licensing and behavior
Traffic types being forwarded

Zscaler and Netskope: Architectural Comparison

Both platforms implement the major concepts associated with SASE and SSE, but they use different terminology and place emphasis on different parts of the architecture.

Architecture Area	Zscaler	Netskope
Primary platform	Zero Trust Exchange	Netskope One
Internet and SaaS security	Zscaler Internet Access	Netskope One Next Gen Secure Web Gateway
Private application access	Zscaler Private Access	Netskope Private Access
Endpoint software	Zscaler Client Connector	Netskope One Client
Private-side connector	App Connector	Private Access Publisher
Cloud network	Zscaler service edges and Zero Trust Exchange	NewEdge
Data protection	ZIA data protection and CASB capabilities	Netskope One CASB and data security
Cloud firewall	Zscaler cloud-delivered firewall capabilities	Netskope One Firewall
Experience monitoring	Zscaler Digital Experience	Netskope digital experience and analytics capabilities
Branch connectivity	GRE, IPsec, integrations, Zero Trust SD-WAN and Branch	GRE, IPsec, Netskope One SD-WAN
Architectural emphasis	Direct-to-application zero trust and reduced routed access	Application and data context with unified SASE policy

This table is not intended to declare one platform universally better than the other.

A proper evaluation should test the capabilities that matter to the organization.

How to Evaluate a SASE Provider

Product selection should involve technical testing rather than relying only on feature checklists.

Enforcement-Point Proximity

Measure latency from:

Corporate offices
Remote users
Cloud regions
International sites
Major internet providers
Mobile networks

The geographically closest location is not always the location with the best network path.

Peering quality can be more important than physical distance.

Traffic Coverage

Determine which traffic types can be inspected:

HTTP
HTTPS
DNS
TCP
UDP
ICMP
Non-standard ports
QUIC
Private applications
Server-initiated traffic
Client-initiated traffic
IPv6

Do not assume that a web proxy automatically provides complete all-port security.

Application Identification

Test whether the platform can distinguish:

Corporate versus personal SaaS tenants
Upload versus download
Browser versus sync client
Managed versus unmanaged applications
Generative AI prompts and uploads
Collaboration messages
Public sharing
API activity
Encrypted application traffic

Data Protection

Validate:

Structured data detection
Exact data matching
Document fingerprinting
Source-code detection
Sensitivity-label integration
OCR
Archive inspection
Maximum file sizes
Supported file types
Encrypted file handling
Endpoint DLP integration
Incident workflow

Private Application Support

Test:

Web applications
SSH
RDP
Database protocols
File shares
Thick-client applications
Voice and real-time traffic
Legacy protocols
Server-initiated connections
Applications using embedded IP addresses
Applications requiring broadcast or multicast
Applications with complex port ranges

ZTNA is highly effective for many endpoint-initiated applications, but it may not replace every network-level use case without redesign.

Identity and Device Posture

Evaluate integrations with:

Microsoft Entra ID
Okta
Active Directory
LDAP
SAML
SCIM
Intune
Jamf
CrowdStrike
Microsoft Defender
Other EDR and MDM platforms

Test what happens when:

MFA fails
A device becomes noncompliant
EDR stops running
A certificate expires
A user is disabled
A user changes groups
A device is lost
A user changes networks during a session

Logging and APIs

Determine whether logs contain enough context for investigation.

Important fields include:

User
Device
Source
Destination
Application
Application instance
Activity
Policy
File
Hash
Threat
DLP result
Enforcement point
Session ID
Bytes
Latency
Connector
Tunnel
Branch

Also validate:

SIEM export
API rate limits
Log delay
Log retention
Webhooks
SOAR integration
Case management
Automated response

A Practical SASE Migration Strategy

Attempting to migrate every user, branch, application, and security policy at once creates unnecessary risk.

A phased deployment is safer.

Phase 1: Discovery and Inventory

Document:

Users
User groups
Device types
Operating systems
Offices
WAN circuits
Existing proxies
VPNs
Private applications
SaaS applications
Firewall policies
DLP policies
Certificate requirements
Existing bypasses
Authentication flows
Logging destinations

Do not copy every legacy proxy and firewall rule into the new platform without reviewing why it exists.

Phase 2: Identity Integration

Integrate the identity provider and provisioning systems.

Validate:

User synchronization
Group synchronization
Authentication
MFA
Deprovisioning
Service accounts
Contractors
Privileged users
Break-glass access

Identity is the foundation of most SASE policy.

Phase 3: Endpoint Pilot

Deploy the endpoint client to a small technical pilot group.

The pilot should include:

IT
Security
Network engineering
Developers
Remote users
Office users
Users of uncommon applications

Start with visibility and logging before aggressive blocking.

Phase 4: Certificate and TLS Inspection

Deploy the inspection certificate through endpoint management.

Begin with selected categories and applications.

Track:

Inspection success
Certificate errors
Pinned applications
User complaints
Application failures
Bypass growth
Performance impact

Every exception should have:

An owner
A reason
A risk classification
A review date
A narrow destination scope

Phase 5: Internet and SaaS Policy

Implement:

URL categories
Threat blocking
File controls
SaaS application discovery
Personal-instance controls
Upload and download policy
DLP
Generative AI controls
User coaching

Policy should be based on business requirements rather than simply blocking every unknown service.

Phase 6: Private Application Access

Select a small group of internal applications for ZTNA.

Good initial candidates include:

Internal web portals
Administrative dashboards
Source-control platforms
Ticketing systems
Development tools

Deploy redundant connectors and test application-specific access.

Avoid granting broad private subnets when application-level definitions are possible.

Phase 7: Branch Integration

Create redundant GRE or IPsec tunnels, or integrate SD-WAN.

Validate:

Primary and secondary paths
Tunnel monitoring
Policy-based routing
Failover
NAT
Source identity
MTU
DNS
Voice bypass
Critical business applications
Local internet survivability

Phase 8: Legacy Service Reduction

After validation, begin reducing dependency on:

Remote-access VPN
Legacy web proxies
Standalone CASB products
Branch security appliances
Backhaul links
Duplicated DLP systems

Do not remove a legacy service until monitoring proves that the replacement meets security, availability, and performance requirements.

Secure Policy Design

SASE policy should use context rather than relying only on source and destination IP addresses.

Identity Context

Examples:

Employee
Contractor
Administrator
Developer
Finance
Executive
Third-party support

Device Context

Examples:

Corporate managed
BYOD
Unmanaged
Encrypted
EDR healthy
EDR unhealthy
Rooted or jailbroken
Fully patched
Outdated operating system

Application Context

Examples:

Sanctioned SaaS
Unsanctioned SaaS
Personal cloud storage
Generative AI
Source control
Financial application
Privileged administration
Unknown website

Data Context

Examples:

Public
Internal
Confidential
Customer PII
PCI
Health data
Credentials
Source code
Intellectual property

Risk Context

Examples:

Known user and managed device
Impossible travel
High-risk location
Compromised credentials
Suspicious download volume
Malware detection
Newly registered domain
High-risk SaaS application

Example Adaptive Policies

IF user.group == "Engineering"
AND device.managed == true
AND device.edr_status == "healthy"
AND application == "GitHub Enterprise"
THEN allow full access

IF user.group == "Engineering"
AND device.managed == false
AND application == "GitHub Enterprise"
THEN allow browser read-only access
AND block download

IF destination.category == "Generative AI"
AND content.classification == "Source Code"
THEN block upload
AND display coaching message

IF user.risk == "high"
OR device.risk == "high"
THEN deny private application access
AND require incident review

Common SASE Deployment Failures

Treating SASE as Only a Proxy Replacement

SASE affects identity, endpoint management, routing, branch design, private access, logging, and data governance.

Replacing a proxy without addressing those areas produces only a partial implementation.

Migrating Legacy Rules Without Cleanup

Legacy policies often contain years of exceptions.

Blindly copying them preserves technical debt and may weaken the new architecture.

Creating Excessive TLS Bypasses

A large bypass list reduces the platform's ability to detect malware, SaaS activity, and data loss.

Exceptions should be narrow and regularly reviewed.

Ignoring MTU

GRE, IPsec, and endpoint tunnels add encapsulation overhead.

If the effective MTU becomes too large, users may experience:

Slow websites
Failed uploads
Broken applications
Intermittent sessions
Fragmentation
TCP retransmissions

Packet captures and TCP MSS adjustment may be required.

Poor DNS Design

Private DNS resolution, split DNS, local DNS, endpoint DNS interception, and cloud DNS controls must be designed together.

A connection may appear to be blocked when the actual problem is an incorrect DNS answer.

Incomplete High Availability

A second tunnel does not provide real redundancy if it:

Terminates on the same device
Uses the same ISP
Reaches the same failure domain
Has no health monitoring
Cannot receive failed-over routes
Uses a path blocked by upstream policy

No Fail-Open or Fail-Closed Decision

The organization must decide what should happen when the cloud service or endpoint client cannot establish a connection.

Possible approaches include:

Fail closed for private administrative access
Fail open for selected business-critical internet applications
Use direct-access emergency policies
Maintain a restricted backup path
Require local branch firewall enforcement

The decision should be documented by traffic class.

Conflicting Endpoint Agents

Running multiple VPN, proxy, DNS, EDR, and network-filtering agents can create conflicts.

Testing should include the complete endpoint software stack.

Weak Operational Ownership

Network, security, identity, endpoint, cloud, and application teams all influence SASE.

A successful deployment requires clear ownership for:

Traffic steering
Identity
Certificates
Endpoint agents
Security policy
DLP
Private connectors
Branch tunnels
Logging
Incident response
Application exceptions

Troubleshooting SASE Connectivity

A structured troubleshooting process prevents random policy changes.

1. Confirm the Destination

Determine:

Hostname
IP address
Port
Protocol
Application
Whether it is internet, SaaS, or private

2. Confirm DNS

Use tools such as:

dig application.example.com
nslookup application.example.com

On macOS:

scutil --dns

Verify whether the expected public or private answer is returned.

3. Confirm Traffic Steering

Determine whether the traffic is using:

Endpoint client
GRE
IPsec
PAC file
Explicit proxy
SD-WAN
Direct bypass

On macOS, inspect proxy settings:

scutil --proxy

On Windows:

netsh winhttp show proxy

A route table alone may not reveal agent-based proxy or tunnel steering.

4. Confirm Client and Tunnel Health

Check:

Agent state
Logged-in user
Policy version
Selected enforcement point
Tunnel state
Trusted-network status
Bypass status

For branches, check:

GRE status
IKE and IPsec security associations
Keepalives
Routing policy
Next hop
Interface counters
Packet loss

5. Confirm Identity

Verify that the cloud service sees the correct:

User
Group
Device
Location
Authentication state
Posture result

Shared IP identity or stale directory groups can cause unexpected policy matches.

6. Confirm Policy Match

Locate the transaction log and identify:

Which rule matched
Why it matched
Which action was taken
Whether another policy took precedence

Avoid changing policy until the matched rule is known.

7. Confirm TLS Behavior

Test the certificate chain:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

Check:

Certificate issuer
Trust chain
Hostname
Expiration
Whether inspection is active
Whether the application uses certificate pinning

8. Confirm the Private Connector Path

For ZTNA applications, validate:

Connector or publisher health
Internal DNS resolution
Route to the application
TCP port reachability
Local firewall policy
Load-balancer health
Application response

From a connector network, a basic test might include:

nc -vz payroll.internal.example.com 443
curl -vk https://payroll.internal.example.com/

9. Capture Packets

Capture at the correct point:

sudo tcpdump -ni any host <destination-ip>

Look for:

DNS queries
TCP retransmissions
Reset packets
MTU problems
TLS alerts
Asymmetric traffic
Unexpected direct connections
Missing tunnel encapsulation

10. Compare Direct and Inspected Paths

Where policy allows controlled testing, compare:

Direct internet path
SASE-inspected path
Primary enforcement point
Backup enforcement point
Office network
Mobile hotspot

This helps isolate endpoint, ISP, SASE, or destination issues.

Monitoring and Operational Metrics

A production SASE platform should be monitored like critical network infrastructure.

Availability Metrics

Track:

Endpoint-client connection rate
Branch tunnel state
Tunnel failover
Connector health
Publisher health
Enforcement-point availability
Authentication failures
Policy update failures

Performance Metrics

Track:

Round-trip latency
Packet loss
Jitter
DNS response time
TLS handshake time
Application response time
Tunnel throughput
Connector utilization
File inspection delay
Enforcement-point selection

Security Metrics

Track:

Blocked malware
Phishing attempts
DLP incidents
Unsanctioned SaaS use
Personal cloud uploads
Private access denials
High-risk users
Noncompliant devices
TLS bypass percentage
Policy exception count

Operational Metrics

Track:

Help desk tickets
Client deployment coverage
Failed upgrades
Certificate expiration
Bypass growth
Policy-change frequency
False positive rate
Mean time to diagnose
Mean time to restore
Applications still dependent on legacy VPN

SASE Does Not Eliminate Networking

SASE is sometimes marketed as though routing, DNS, packet analysis, and network engineering become unnecessary.

The opposite is true.

A SASE deployment still depends on:

DNS
BGP
Static routing
Policy-based routing
GRE
IPsec
NAT
MTU
TCP behavior
TLS
Certificates
QoS
WAN path selection
High availability
Cloud routing
Identity
Endpoint management

The architecture changes where some controls are enforced, but it does not remove the need to understand the underlying network.

When a SASE deployment fails, the cause is frequently an interaction between several domains:

Identity
    +
Endpoint
    +
DNS
    +
Routing
    +
TLS
    +
Cloud Policy
    +
Application Behavior

Engineers who understand all of these layers are essential to a successful deployment.

Final Thoughts

SASE is not simply a replacement for a firewall, proxy, or VPN.

It is a distributed architecture for connecting users, devices, branches, workloads, applications, and data through cloud-delivered networking and security controls.

Its major advantages can include:

Consistent policy for office and remote users
Reduced traffic backhauling
Application-level private access
Improved SaaS visibility
Centralized data protection
Reduced exposure of private applications
Consolidated logging
Better support for distributed work
Integration of networking and security policy

However, these benefits depend on implementation quality.

The most important engineering work occurs in:

Identity design
Device-posture integration
Traffic steering
TLS inspection
DNS architecture
Private application segmentation
Tunnel redundancy
Failover
Logging
Performance monitoring
Exception management
Operational ownership

Zscaler and Netskope both provide platforms capable of delivering major SASE and SSE functions.

The correct choice depends on the organization's applications, data, users, network architecture, security requirements, operating model, and performance needs.

The most valuable question is therefore not:

Which vendor has the longest feature list?

It is:

Which architecture can securely connect our users and devices to the exact applications and data they require, with the least unnecessary trust, acceptable performance, reliable operations, and enough visibility to prove that it is working?

Zscaler Zero Trust Exchange — ZIA, ZPA, and the zero-trust model in practice
Meraki MX85 SD-WAN — branch SD-WAN and cloud-managed WAN
Troubleshooting L1 to L7 — systematic debugging when paths fail
Network Observability with New Relic — telemetry for hybrid and cloud paths

Explore the full stack on TechHub Learning.