TL;DR: Zero trust can reduce exposure in SaaS-heavy environments, but it still depends on visibility, enforceable controls, and identity governance across users, devices, and permissions, according to Axiad. The real challenge is not adopting the label, but removing the trust assumptions that let access drift beyond what teams can actually govern.
At a glance
What this is: This article argues that zero trust in SaaS environments runs into a visibility and enforcement gap when identity, device, and permission data are fragmented across applications.
Why it matters: IAM teams need to treat SaaS zero trust as a governance problem, because access decisions are only as reliable as the visibility behind them.
Context
Zero trust is an access model that assumes no user or device is trusted by default and requires explicit verification before access is granted. In SaaS environments, that promise depends on being able to see who is accessing what, from where, and under which permissions.
The governance problem is not the concept of zero trust itself. The problem is that SaaS sprawl, shared applications, and rapidly changing permissions make enforcement difficult when identity data is siloed or incomplete. That is why zero trust for SaaS becomes an identity visibility issue as much as an architecture choice.
Axiad’s article presents the practical tension clearly: organisations want tighter access control, but employees still need frictionless access to do their jobs. That makes the identity layer, not the application label, the real control point.
Key questions
Q: What breaks when zero trust stops at SSO in SaaS environments?
A: Access removal becomes incomplete because SaaS applications often retain direct grants, delegated connections, and local admin roles after the directory account is disabled. That leaves hidden privilege behind even when the primary login path looks closed. Teams need application-level verification before they can claim the identity is fully offboarded.
Q: Why do passwordless logins not solve SaaS zero-trust governance on their own?
A: Passwordless login removes password risk, but it does not decide who should have access, which privileges should remain, or when access should be revoked. Zero trust still depends on entitlement governance, device context, and policy enforcement across applications. Authentication hardening without authorization control leaves the access model incomplete.
Q: How should security teams implement Zero Trust SaaS in practice?
A: Start with discovery, because Zero Trust SaaS cannot be enforced without knowing which apps, identities, tokens, and integrations exist. Then apply least privilege to each connected identity, monitor sessions continuously, and revoke access when scopes exceed business need. The goal is to make access decisions continuously verifiable, not merely approved at onboarding.
Q: What should IAM teams prioritise before expanding zero trust across SaaS?
A: IAM teams should prioritise visibility into who and what can access each application, then align entitlement governance to that view. If the programme cannot inventory users, devices, permissions, and application ownership, the zero-trust model will remain difficult to enforce consistently across the estate.
Technical breakdown
Why SaaS creates a visibility problem for zero trust
SaaS access is distributed across internet-facing services, shared accounts, and frequently changing entitlements. Zero trust assumes policy decisions can be made with current context, but that requires accurate identity, device, and application data at the point of access. When data lives in separate SaaS consoles or identity stores, enforcement becomes partial rather than continuous. The result is not a failed zero-trust model, but a model whose inputs are too fragmented to support reliable decisions.
Practical implication: map where identity and entitlement data is fragmented before treating zero trust as operationally enforceable.
Passwordless authentication is not the same as zero-trust governance
Passwordless authentication reduces password risk by removing shared secrets from the user login flow, but it does not solve who should have access, which permissions should persist, or how access should be constrained across SaaS apps. Zero trust is a broader control model, while authentication is only one of its inputs. If governance does not govern privilege, session scope, and application access, authentication improvements can still leave overexposure intact.
Practical implication: separate authentication hardening from entitlement governance so passwordless does not become a substitute for access control.
Why SaaS permissions drift breaks enforceable policy
SaaS environments change frequently, and that creates policy drift when access is requested informally, inherited through groups, or left in place after role changes. Zero trust depends on conditions being checked every time access is evaluated, but stale permissions undermine that discipline by leaving excess access available before any decision is made. In practice, the control failure is not just lack of trust. It is lack of authoritative entitlement state.
Practical implication: continuously reconcile SaaS entitlements so access decisions are made against current, not historical, privilege state.
Breaches seen in the wild
- Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity visibility is the real zero-trust prerequisite in SaaS. The article’s core point is not that zero trust fails in SaaS, but that it cannot be enforced without accurate knowledge of users, devices, and permissions across a fragmented application estate. Zero trust becomes an aspiration rather than an operating model when the programme cannot see the identities it is supposed to govern. The practitioner conclusion is straightforward: visibility is not a reporting feature, it is the control substrate.
Zero-trust SaaS exposes a governance gap, not just an authentication gap. Passwordless authentication may reduce credential risk, but the article makes clear that access control still depends on knowing which permissions should exist and where they apply. That is an identity governance problem, not a login problem. The implication for IAM teams is that stronger sign-in does not compensate for weak entitlement control.
SaaS sprawl turns policy enforcement into an integration problem. When access decisions depend on data scattered across multiple applications, the programme is forced to reconcile policy intent with inconsistent source records. That is why zero trust in SaaS cannot be measured only by adoption rates or authentication strength. Practitioners should treat cross-application visibility and entitlement reconciliation as first-order governance requirements.
Zero trust changes the burden of proof for access decisions. In a SaaS environment, no access should be assumed safe simply because it is convenient or historically normal. The burden shifts to proving that current identity state, current device context, and current permission scope all align. That is a material change for IAM operating models, and it is why zero-trust initiatives fail when teams optimise for user experience without equivalent enforcement depth.
Identity attack surface is the right concept for SaaS zero trust. The article points to a structural reality: every unmanaged user, device, permission, and shared application increases the number of places where policy can be bypassed or weakened. That is the practical measure of zero-trust maturity in SaaS. Practitioners should evaluate not whether zero trust exists in name, but whether the identity attack surface is shrinking in practice.
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 Identity Guide
What this signals
Identity visibility is the gating control for SaaS zero trust. Organisations cannot enforce least-access decisions across SaaS if they do not know which identities, devices, and entitlements are active at any given moment. That makes visibility a control dependency, not a reporting afterthought.
Zero trust for SaaS should be measured by entitlement state, not policy language. If access continues through stale group membership, informal approvals, or inconsistent app-by-app controls, the programme is still relying on trust leakage rather than continuous verification.
Access review cadences alone are not enough when SaaS permissions change faster than the review cycle. Practitioners should push governance earlier in the lifecycle so entitlement state is validated before access is granted, not only after drift appears.
For practitioners
- Inventory SaaS identity touchpoints Map every SaaS application, user population, device context, and entitlement source that influences access decisions so gaps are visible before policy work begins.
- Separate authentication from authorization Treat passwordless and other sign-in improvements as only one layer of the zero-trust model, and keep entitlement governance distinct from login controls.
- Reconcile stale permissions continuously Review group membership, direct grants, and role-based access in SaaS platforms on a recurring basis so historical access does not outlive current job need.
- Reduce friction on approved access paths Standardise approved request and approval paths so employees are less likely to work around zero-trust controls by informally borrowing access from others.
Key takeaways
- Zero trust in SaaS fails when identity, device, and entitlement data are too fragmented to support consistent enforcement.
- Passwordless login improves authentication, but it does not solve authorization drift or cross-application governance.
- The practical test is whether teams can prove current access state across SaaS apps, not whether the zero-trust label has been adopted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 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 | The article centres on enforcing access across fragmented SaaS identity data. |
| Recommendation — Use PR.AA-05 to validate SaaS entitlements against current access need and remove stale permissions. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement Point — Policy Enforcement Point | Zero trust depends on enforcement at the point of access across distributed SaaS services. |
| Recommendation — Place enforcement where SaaS access is decided, not where exceptions are discovered later. | ||
| NIST SP 800-63 | SP 800-63C — Federation | The article discusses federated SaaS access patterns and identity assertion across services. |
| Recommendation — Review federation trust paths so SaaS access decisions reflect the right identity source and context. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle and access management are central to the article's SaaS governance gap. |
| Recommendation — Standardise account ownership and lifecycle controls so SaaS access stays aligned to current need. | ||
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.
- Identity Visibility: Identity visibility is the ability to see which identities exist, what they can access, and how those access paths relate across systems. In NHI programmes, it means correlating service accounts, tokens, certificates, and agents into one operational view so governance decisions are based on evidence, not assumptions.
- Entitlement Drift: Entitlement drift is the slow accumulation of permissions that no longer match the original purpose, role, or workload. In cloud-native and NHI-heavy environments, it usually happens because access changes faster than review cycles, leaving organizations with more privilege than they intended.
- Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org