Zero trust for SaaS: the identity controls teams still miss

At a glance

What this is: This is a zero-trust SaaS analysis that argues implicit trust no longer works well for cloud-delivered applications and that visibility, control, and enforcement gaps are the main blockers.

Why it matters: It matters because IAM teams need to apply zero-trust thinking consistently across NHI, human access, and device-driven access paths, not only at the network edge.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Axiad's article on zero trust for SaaS and identity controls

Context

Zero trust for SaaS means access is granted only after the identity, device, and request context are verified, rather than assuming trust because a user is on the internal network. That matters because SaaS environments change quickly, users collaborate across boundaries, and access paths are often broader than the security team realises.

For IAM teams, the practical problem is not the theory of zero trust but the operational gap between policy and enforcement. Visibility into who or what is accessing a SaaS application, what data it can reach, and whether access is still appropriate is often incomplete, which makes the model difficult to sustain across human identities and NHIs alike.

Key questions

Q: How should security teams implement zero trust for SaaS applications?

A: Start with an inventory of every identity and access path, then enforce least privilege through conditional access, entitlement review, and session-based controls. Zero trust for SaaS works only when authentication, authorization, and lifecycle governance are aligned across both human users and non-human access such as tokens and service accounts.

Q: Why do SaaS environments make zero trust harder to enforce?

A: SaaS makes zero trust harder because access is distributed across many apps, identities, and integrations, while the data needed to govern that access is often fragmented. When teams cannot see all active permissions and delegated connections, they cannot confidently certify, reduce, or revoke access in time.

Q: What breaks when organisations only strengthen sign-in and ignore authorization?

A: They improve the front door while leaving the inside of the building unsecured. Strong authentication can stop some account takeover, but excessive roles, stale entitlements, and shared access still let compromised identities reach more systems and data than the business intended.

Q: What is the difference between passwordless authentication and zero trust?

A: Passwordless authentication is a sign-in method. Zero trust is an operating model that decides whether an identity should continue to have access based on context, privilege, and policy. Passwordless can support zero trust, but it does not replace access governance or lifecycle control.

Technical breakdown

Zero trust in SaaS depends on continuous access evaluation

In SaaS environments, zero trust is not a one-time login check. It relies on continuous evaluation of identity, device posture, and session context so that access decisions can be adjusted as conditions change. That is harder than perimeter-based security because SaaS apps are internet-facing, frequently updated, and often federated across multiple identity systems. If the access decision is static, the model reverts to implicit trust, which is exactly what zero trust is meant to avoid.

Practical implication: teams need access enforcement that can reassess sessions as context changes, not just authenticate once at sign-in.

Visibility gaps turn SaaS sprawl into identity risk

SaaS sprawl creates an identity problem as much as a data problem. When users, service accounts, and tokens are spread across many applications, it becomes difficult to answer basic governance questions such as who has access, which permissions are active, and whether access is still required. Without that inventory, least privilege cannot be maintained and recertification becomes slow, incomplete, or speculative.

Practical implication: build a complete inventory of human and non-human access paths before expecting zero-trust policy to hold.

Passwordless authentication supports zero trust, but does not replace governance

Passwordless authentication reduces password theft and improves user experience, but it only solves the authentication step. Zero trust still needs policy, authorization, and lifecycle control to decide what the identity can do after login. In SaaS, that means the strongest sign-in method still fails if roles are excessive, shared, or never reviewed. Authentication strength and access governance have to work together.

Practical implication: pair passwordless adoption with entitlement review and role cleanup, especially for shared SaaS access.

Threat narrative

Attacker objective: The attacker aims to use one compromised identity or session to reach multiple SaaS applications and sensitive data with minimal resistance.

1. Entry occurs through SaaS access paths that depend on overly broad trust assumptions, making stolen or misused credentials more useful than they should be.
2. Escalation follows when shared applications, incomplete visibility, and weak entitlement governance let an identity reach more data or functions than intended.
3. Impact lands as unauthorized access, difficult-to-trace lateral movement across SaaS tools, and a larger blast radius when credentials or sessions are compromised.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero trust in SaaS fails first as a visibility problem, not a policy problem. Organisations often talk about zero trust as if the main issue is choosing the right control set. In practice, the harder failure is knowing what identities, sessions, and application permissions exist across a SaaS estate that changes daily. If the security team cannot see the access graph, it cannot govern it, certify it, or contain it with confidence.

Identity attack surface is the right named concept for SaaS governance. The attack surface is not just the number of applications, but the number of identities, tokens, roles, and delegated access paths each app creates. That surface expands quickly when users share files, connect integrations, and reuse permissions across services. Practitioners should treat the identity attack surface as a measurable governance object, not a vague architectural concern.

Passwordless authentication helps, but it does not solve SaaS least privilege. Replacing passwords with stronger sign-in methods reduces one class of compromise, yet over-privileged roles and stale entitlements remain intact unless the governance layer is fixed. Zero trust for SaaS is therefore a lifecycle problem as much as an authentication problem. Teams that stop at stronger login controls will still carry the same authorization risk.

Zero trust must cover NHIs inside SaaS, not just human users. Many SaaS environments rely on API keys, tokens, service accounts, and automated integrations that inherit access without the same review rigor as employees. That is where zero trust frequently becomes ceremonial. If NHI access is not inventoried, bounded, and periodically revalidated, the model leaves its largest blind spot untouched.

Cross-domain governance is where mature programmes separate signal from posture. SaaS identity control now spans human users, delegated access, and non-human credentials in one operating model. The organisations that can connect authentication, entitlement governance, and NHI lifecycle controls will have the clearest view of risk. That is the practical direction of travel for identity programmes that want zero trust to survive contact with SaaS reality.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams are governing blind spots rather than complete identity inventories.
• Use the Top 10 NHI Issues to connect SaaS access sprawl to the governance failures that make zero trust difficult to sustain.

What this signals

Identity attack surface is becoming the more useful operating metric for SaaS governance than simple application count. As collaboration tools, integrations, and service accounts multiply, the practical question is whether your programme can still explain who can reach which data, through which identity, and under what condition.

The governance gap will increasingly sit at the intersection of human access, delegated SaaS permissions, and non-human credentials. Teams that keep authentication modern but leave entitlement review, access inventory, and recertification fragmented will keep finding the same risk in a new wrapper.

A useful benchmark from our research is that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage. That is a reminder that SaaS zero trust is not only about login strength, but about the identities and secrets that sit behind the login screen.

For practitioners

• Inventory all SaaS identities and access paths Map users, service accounts, API keys, tokens, and delegated integrations to each SaaS application so the team can see who or what can access what. Without that inventory, zero-trust policy cannot be enforced consistently across the estate.
• Tie passwordless rollout to entitlement cleanup Do not treat passwordless authentication as a standalone fix. Remove excessive roles, shared accounts, and stale access at the same time so stronger authentication does not protect an already over-permissive access model.
• Re-certify high-risk SaaS access on a shorter cycle Prioritise apps with sensitive data, external collaboration, or privileged integrations for more frequent access reviews. Use those reviews to catch entitlements that survive long after the business need has ended.
• Test whether enforcement follows context changes Validate that access can be reduced or removed when device posture, user location, or session context changes. If enforcement only happens at login, the programme is still operating like perimeter security.

Key takeaways

• Zero trust in SaaS fails when teams cannot see the full identity and access graph across users, tokens, and integrations.
• The scale of non-human privilege is already high, and the visibility gap leaves most organisations unable to govern SaaS access precisely.
• Stronger authentication helps, but only entitlement cleanup, lifecycle review, and continuous enforcement make zero trust credible in SaaS.

Key terms

• Zero Trust: A security model that does not assume trust based on network location or prior access. In SaaS environments, it requires continuous verification, least privilege, and context-aware authorization so access can be limited or removed when conditions change.
• Identity Attack Surface: The full set of identities, credentials, roles, tokens, and delegated access paths that can be used to reach systems or data. For SaaS, this surface expands quickly because every application, integration, and shared workflow can add another access path to govern.
• Passwordless Authentication: An authentication method that removes passwords from the login step and uses stronger factors such as device binding, biometrics, or cryptographic proofs. It reduces password theft risk, but it does not replace entitlement governance, certification, or access lifecycle management.
• Non-Human Identity: Any machine or software identity that authenticates and accesses systems, including service accounts, tokens, API keys, and certificates. In SaaS governance, NHIs often create the hardest-to-see access paths because they are embedded in integrations and automation rather than user workflows.

Deepen your knowledge

SaaS zero trust, access inventory, and entitlement governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to apply zero trust across human access and non-human credentials at the same time, it is a relevant place to start.

This post draws on content published by Axiad: Do You Need a Zero-Trust SaaS? Read the original.