Zero Trust Model in SASE

Identity Is the New Perimeter

Traditional network security operated on a castle-and-moat model: if you were inside the corporate network, you were trusted. If you were outside, you were not. This model collapsed when employees started working from home, using personal devices, and accessing applications hosted outside the corporate network entirely.

Zero Trust is the principle that no user, device, or network location is inherently trusted. Every access request must be verified based on who is asking, what they are asking for, from what device, and in what context — every single time.

In SASE, Zero Trust is implemented through ZTNA (Zero Trust Network Access), which replaces the traditional VPN. A VPN grants network-level access — once connected, a user can reach any system on the network. ZTNA grants application-level access — a user can reach only the specific applications they are authorized for, and nothing else.

How SASE Evaluates an Access Request:

Step 1: Identity Resolution

The SASE platform integrates with your Identity Provider (IdP) — typically Okta, Azure Active Directory, or Google Workspace. When a user's traffic arrives at the SASE POP, the platform resolves the source not as "IP address 10.1.1.5" but as "User: [email protected], Groups: [Marketing, EMEA]."

This identity context is attached to every subsequent policy evaluation.

Step 2: Device Posture Assessment

Before granting access, the SASE platform checks the device's security posture via an endpoint agent:

• Is the device encrypted? (BitLocker/FileVault enabled)
• Is the OS patched? (No critical CVEs outstanding)
• Is endpoint protection running? (CrowdStrike/Defender active)
• Is the device managed by the corporate MDM? (Enrolled in Intune/Jamf)

A device that fails posture checks can be denied access entirely, or granted reduced access (e.g., read-only, no file downloads).

Step 3: Contextual Risk Scoring

The SASE platform evaluates additional context signals:

• Geolocation: Is Alice logging in from London (normal) or from a country she has never accessed from before?
• Time of day: Is this access at 2 AM on a Sunday?
• Behavioral baseline: Is Alice downloading 10x her normal data volume?

These signals feed into a risk score that can trigger step-up authentication (MFA challenge) or block access.

Step 4: Granular Policy Enforcement

Policies in SASE are written at the application-activity level, not the network level. A traditional Layer 4 firewall can allow or block traffic to an IP and port. A SASE platform can allow or block specific actions within a specific application for a specific user group:

Policy: Marketing-Facebook-Upload-Block
  Source:      Group = "Marketing"
  Destination: Application = "Facebook"
  Activity:    Upload (file attachment, photo post)
  Action:      BLOCK, Log, Alert

Policy: Marketing-Facebook-Browse-Allow
  Source:      Group = "Marketing"
  Destination: Application = "Facebook"
  Activity:    Browse, Chat, View
  Action:      ALLOW

This level of granularity — blocking uploads to Facebook while allowing browsing — is impossible with a traditional firewall that only sees TCP port 443 to a Facebook IP address. SASE achieves it through SSL inspection (decrypting HTTPS traffic at the POP) combined with application-layer DPI.

Key Point: Zero Trust in SASE shifts the security boundary from the network perimeter to the identity and device. The practical implication for platform engineers is that access control policies must be maintained in the IdP and SASE platform, not in firewall ACLs. When an employee leaves, revoking their IdP account immediately revokes all access — no firewall rules to hunt down and delete.