What breaks when organisations assume SASE automatically delivers Zero Trust?

Why This Matters for Security Teams

SASE improves inspection, routing, and policy enforcement at the network edge, but zero trust is broader than where traffic passes. It depends on identity, device, workload, privilege, and continuous verification. NHI Management Group’s Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which is a reminder that network controls alone do not close entitlement gaps. The issue is especially visible with service accounts, API keys, and machine tokens that keep working long after the network has approved the session.

NIST SP 800-207 Zero Trust Architecture defines Zero Trust as a strategy based on explicit verification and least privilege, not a perimeter product category. That distinction matters because SASE can be part of the enforcement path while still leaving standing access, weak revocation, and overbroad entitlements untouched. In practice, many security teams discover this only after a leaked credential is still valid and still authorised, rather than through intentional Zero Trust design.

How It Works in Practice

The practical failure mode is simple: SASE may allow, inspect, or block traffic, but it does not inherently know whether a human user, workload, or agent should retain privilege. Zero Trust requires policy decisions tied to identity and context, not just network location. For non-human identities, that means the control plane must answer questions such as: Is this workload expected to call this API? Is the token still valid for this task? Has the privilege been revoked after completion?

That is why leading guidance increasingly separates transport security from identity governance. The Guide to SPIFFE and SPIRE is useful here because it frames workload identity as a cryptographic primitive for what the workload is, while SASE remains focused on where the traffic travels. In mature deployments, teams combine:

• workload identity issuance using SPIFFE, OIDC, or similar attestation-backed methods
• JIT, short-lived credentials with automatic revocation at task completion
• policy-as-code for runtime authorisation decisions, often with OPA or Cedar
• privilege boundaries enforced in PAM, secrets managers, and downstream services
• continuous revocation for service accounts, API keys, and certificates

This is especially important because NHI risk is often hidden in plain sight. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which means many teams are trying to layer Zero Trust over identities they cannot fully enumerate. SASE can reduce exposure paths, but it cannot replace lifecycle control, entitlement review, or secret rotation. These controls tend to break down in legacy app estates and hybrid integrations because the identity state is distributed across code, CI/CD, secrets stores, and third-party services.

Common Variations and Edge Cases

Tighter network enforcement often increases operational overhead, requiring organisations to balance traffic inspection against identity governance effort. That tradeoff becomes sharper in environments with east-west traffic, SaaS-to-SaaS integrations, and autonomous agents, where static allowlists are brittle and context changes per request. The guidance here is evolving, but current best practice suggests treating SASE as one enforcement layer inside a broader Zero Trust model, not the model itself.

There is also a common edge case where teams assume device trust can stand in for workload trust. That works poorly for cloud services, CI/CD jobs, and AI agents because the entity making the call is not a stable endpoint with a fixed human operator. In those cases, intent-based or context-aware authorisation is more appropriate than a network-centric decision. Standards such as NIST SP 800-207 Zero Trust Architecture support that direction, but there is no universal standard for every implementation pattern yet.

For security teams, the key question is not whether SASE is deployed, but whether access can be revoked, reduced, and re-evaluated independent of the network path. If the answer is no, then Zero Trust has been simulated at the edge while privilege remains intact underneath.

Related resources from NHI Mgmt Group

• What breaks when certificate management stays manual in a Zero Trust programme?
• Should organisations treat MCP server collaboration as a Zero Trust problem?
• Should organisations prioritise Zero Trust for machine identities before broader IAM changes?
• Should organisations align PAM and zero trust policy design?