TL;DR: Zero trust is hard to operationalise without SASE because fragmented tools, weak visibility and implicit trust undermine consistent policy enforcement across remote users, devices and cloud applications, according to Todyl. The practical shift is from perimeter thinking to identity-first control, continuous verification and tighter segmentation.
At a glance
What this is: This is a roadmap for using SASE to operationalise zero trust, with the key finding that fragmented security tools and perimeter-based trust break down in distributed environments.
Why it matters: It matters because IAM, NHI and broader security teams all need the same control logic for users, devices, workloads and connections when access is no longer bounded by a network edge.
Context
Zero trust is an access model built on continuous verification rather than implicit trust based on location. In distributed environments, that matters because users, devices, applications and services no longer sit behind a single perimeter, and the control problem shifts from network presence to verified intent and context.
SASE is presented here as the delivery model that can make zero trust operational across remote access, segmentation and inspection. The identity angle is direct: if access decisions are still tied to the network edge instead of the principal, the architecture cannot reliably separate legitimate activity from over-broad access.
Key questions
Q: What breaks when organisations keep relying on perimeter security instead of Zero Trust?
A: Perimeter security breaks down when trust is assumed after initial access. In practice, that can create overexposed networks, easier lateral movement, and weak control over remote workers, cloud workloads, and APIs. It also makes compliance and access governance harder because a single network boundary cannot reliably protect a distributed environment with many identities and machines.
Q: What is the difference between SASE and Zero Trust in practice?
A: In practice, Zero Trust is the governance logic that decides who or what should get access, while SASE is the architecture that helps enforce those decisions across the network. Zero Trust is narrower and identity-led. SASE is broader and combines networking, security, and policy delivery. Teams need both, but they solve different layers of the problem.
Q: What are the signs that a zero trust rollout is failing in practice?
A: Common warning signs include overlapping tools that do not integrate well, inconsistent policy enforcement across environments, weak visibility into asset and transaction flows, and users bypassing controls because processes are too cumbersome. If teams cannot tell who accessed what, when, and why, the program is not delivering the verification and control zero trust is supposed to provide.
Q: How should organisations apply Zero Trust to non-human identities?
A: Start by treating each non-human identity as a controllable access path, not a background system object. Apply least privilege, session scoping, ownership, and continuous revocation to service accounts, API keys, certificates, and automation agents. The goal is to reduce the blast radius of any one identity and ensure access changes when risk changes.
Technical breakdown
Why perimeter trust breaks in distributed environments
Perimeter trust fails because a firewall boundary no longer matches how work happens. Cloud services, SaaS applications, remote users and mobile devices create access paths that bypass the old inside or outside model. Zero trust replaces that assumption with explicit verification for each request, but the control only works when identity, device posture and policy are evaluated at the point of access rather than after a session has already expanded its reach. See the Zero Trust Identity Guide.
Practical implication: Treat network location as an unreliable signal and move access decisions to identity and context checks at request time.
How SASE turns policy into an enforcement layer
SASE combines security and networking functions so policy can follow the user and the connection instead of sitting in disconnected tools. In this model, ZTNA, inspection, filtering and traffic controls are delivered from the cloud and applied consistently across locations. The operational value is less about consolidation for its own sake and more about reducing policy drift, visibility gaps and exceptions that appear when VPNs, firewalls and CASB rules are managed separately. See the SASE and SSE Guide.
Practical implication: Centralise enforcement where access is decided so policy remains consistent across remote and hybrid traffic.
Why identity becomes the control plane for access
Zero trust depends on identity because the decision is no longer 'is this traffic inside the network?' but 'should this principal reach this resource right now?' That means authentication, authorisation and least privilege must be tied to a verified identity provider and to role or context. The same logic matters for non-human identities as well, because service accounts and automation flows also need explicit access boundaries and continuous governance, not inherited trust from the surrounding network. Read Guide to SPIFFE and SPIRE.
Practical implication: Use identity-centric policy for both human and non-human principals so access scope remains explicit and reviewable.
NHI Mgmt Group analysis
Zero trust fails when the organisation treats network location as a substitute for identity assurance. The article is right to emphasise that distributed work and cloud adoption have dissolved the old perimeter, but the deeper governance issue is that many environments still let location, not principal verification, shape access decisions. That is a control design problem, not a tooling problem. Practitioners should re-centre policy on verified identity and contextual access decisions.
Identity-first enforcement is the real test of zero trust maturity. SASE can help, but only if access policy actually follows the identity and not the tunnel, VLAN or office boundary. This is where zero trust identity becomes operational: the programme needs policy that can distinguish user, device, workload and session risk rather than assuming one network control can cover all of them. Practitioners should measure whether access decisions are still being made by legacy network placement.
The hidden risk is not remote access alone but internal lateral movement. The article correctly notes that many teams over-focus on external entry while leaving east-west traffic less governed. That creates a governance gap where the first access decision is hardened, but subsequent movement is still too easy. Practitioners should treat internal segmentation and continuous inspection as part of the same zero-trust control plane, not as a separate networking project.
Zero trust for NHIs is now part of the same control question as zero trust for people. When service accounts, automation, and machine principals inherit broad trust from environment design, the architecture can look mature while remaining weak in practice. The named concept here is trust inheritance drift: access keeps expanding because the policy model was built around human login patterns. Practitioners should align NHI governance with the same explicit verification logic used for human access.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- Read next: Zero Trust for AI Agents
What this signals
Trust inheritance drift: the most dangerous zero-trust gap is not a missing control but a stale assumption that location still implies legitimacy. Once that assumption survives in policy, teams can deploy modern tooling and still preserve legacy access behaviour.
Zero trust programmes will increasingly be judged by whether they can enforce the same decision logic across people, devices and NHIs. That means access policy, segmentation and monitoring need to converge around the principal, not the path, if the architecture is going to hold under real operational pressure.
For practitioners
- Map every access path and trust boundary Inventory users, endpoints, SaaS applications, data locations and east-west traffic flows before writing policy so your zero-trust design reflects reality rather than assumptions.
- Make identity the primary control plane Tie access to a verified identity provider, enforce MFA, and scope entitlements by role so network location does not decide access.
- Segment internal traffic as aggressively as external traffic Apply micro-segmentation and deny-by-default rules to internal connections so lateral movement is constrained even after initial access is granted.
- Govern non-human identities in the same policy model Extend explicit access controls to service accounts, automation and workload identities so machine access does not bypass the zero-trust design.
- Use continuous monitoring to validate policy drift Correlate SASE, SIEM and endpoint telemetry to identify where access decisions no longer match intended policy and where exceptions are accumulating.
Key takeaways
- Zero trust fails when network location still acts as a proxy for trust, because distributed work and cloud services erase the perimeter the model depended on.
- The article's central operational message is that SASE only helps when it enforces explicit identity-centric policy, segmentation and inspection across every access path.
- Practitioners should validate whether their zero-trust programme governs both human and non-human principals, or whether machine access is still escaping the same controls.
Related NHI Mgmt Group resources: Zero Trust Identity Guide · Guide to SPIFFE and SPIRE · Zero Trust for AI Agents · SASE and SSE Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Zero trust here depends on explicit access permissions rather than implicit network trust. |
| Recommendation — Apply PR.AA-05 to enforce identity-based access decisions instead of network-location trust. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture — Zero Trust Architecture | The article is explicitly about operationalising zero trust in a distributed environment. |
| Recommendation — Use zero-trust principles to move policy decisions to the access request and remove implicit trust. | ||
| CIS Controls v8 | CIS-5 — Account Management | Identity-first access control relies on governed account and entitlement management. |
| Recommendation — Tighten account scope and review access paths so account sprawl does not undermine zero trust. | ||
| MITRE ATT&CK | TA0008;TA0040 — Lateral Movement; Impact | The article's control model aims to reduce lateral movement and blast radius after compromise. |
| Recommendation — Map segmentation gaps to TA0008 and harden controls that limit blast radius after initial access. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The piece directly extends zero trust logic to service accounts and automation flows that can be over-privileged. |
| Recommendation — Review machine identities for over-privilege and remove standing access that bypasses zero-trust policy. | ||
Key terms
- Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
- Secure Access Service Edge: SASE is a converged architecture that combines network connectivity with security controls such as zero trust access, secure web gateway, and firewall services. It is useful for consistent enforcement across distributed environments, but it does not replace identity governance or entitlement ownership.
- Zero Trust Network: A Zero Trust Network is a network security approach that does not trust users, devices, or traffic by default. Every connection is continuously verified using identity, device posture, context, and policy before access is granted. It assumes breach, limits lateral movement, and treats network access as conditional rather than implicit.
- Micro-segmentation: Micro-segmentation divides cloud environments into smaller trust zones so that identities cannot move freely between systems. It is a containment strategy rather than a prevention strategy. For NHI governance, it limits lateral movement and reduces the damage caused by compromised machine credentials.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity control to the wider security architecture their programmes depend on.
Published by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org