Zero trust SaaS needs visibility before access control can work

At a glance

What this is: This analysis argues that Zero Trust SaaS fails when organisations cannot continuously see every app, identity, token, and integration in scope.

Why it matters: For IAM and NHI teams, visibility is the prerequisite for enforcing least privilege, spotting shadow integrations, and reducing SaaS-driven blast radius.

By the numbers:

• According to the 2025 Verizon Data Breach Investigations Report, 30% of all breaches involved third-party relationships, up from 15% the previous year.
• According to the 2024 Microsoft Digital Defense Report, 22% of organizations had an attack path identified in the cloud.
• According to the 2024 Microsoft Digital Defense Report, 40% of attack paths include lateral movement based on non-interactive remote code execution.

👉 Read Wing Security's analysis of Zero Trust SaaS visibility and control

Context

Zero Trust SaaS is the application of zero trust architecture to cloud application estates, where every access request, token, and integration must be continuously verified. The governance problem is not the principle itself, but the operational gap between policy and visibility across human identities, service accounts, OAuth grants, API keys, and machine-to-machine workflows.

That gap is familiar to IAM and NHI practitioners because SaaS environments do not behave like a single directory. They behave like an ecosystem of apps, identities, and delegated permissions, which means access control only works when discovery, entitlement review, and session telemetry are aligned. For background on the control model, see the Ultimate Guide to NHIs , Key Challenges and Risks and the Ultimate Guide to NHIs , Standards.

Key questions

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: Why do SaaS environments create NHI governance problems?

A: SaaS environments create NHI governance problems because delegated access spreads across OAuth apps, API keys, service accounts, and automation that often sit outside human-centric IAM reviews. Each of those credentials is a non-human identity with its own lifecycle and blast radius. If they are not inventoried and reviewed, privilege accumulates quietly.

Q: What is the difference between RBAC and ABAC in SaaS access control?

A: RBAC assigns access based on job role, while ABAC applies context such as device posture, location, time, or risk signals. In SaaS, RBAC is useful for baseline assignment, but ABAC is better for step-up decisions and sensitive actions. Most mature programmes need both, because static role mapping alone cannot handle dynamic SaaS risk.

Q: When does Zero Trust SaaS fail to reduce risk?

A: Zero Trust SaaS fails when organisations focus on policy language but leave discovery, token governance, and integration monitoring incomplete. In that case, the model becomes a checklist rather than a control. Risk remains high whenever shadow apps, stale OAuth grants, or unmanaged service identities can bypass the intended review process.

Technical breakdown

Why SaaS visibility is the control plane for Zero Trust

Zero trust architecture assumes every request can be verified continuously, but SaaS estates fragment identity across app-specific stores, delegated OAuth consent, API tokens, and service accounts. In practice, the control plane is not a network boundary but the combination of discovery, entitlement mapping, and telemetry. If a security team cannot see connected applications and active non-human identities, it cannot distinguish sanctioned automation from unmanaged access. That is why visibility is not an adjacent function. It is the mechanism that makes policy enforceable across SaaS.

Practical implication: Build a complete inventory of SaaS apps, tokens, and machine identities before treating zero trust as operational.

How tokenized access and app-to-app integrations expand the NHI surface

Modern SaaS workflows rely on delegated access, where one application acts on behalf of a user or another system. OAuth scopes, API keys, webhooks, and service credentials can persist long after the original business need has changed. That creates NHI sprawl inside collaboration, finance, and development tools, often outside the visibility of traditional IAM reviews. The technical risk is scope drift, where the credentials retain more privilege than the workflow actually requires. Once that happens, the integration itself becomes an access path.

Practical implication: Review delegated scopes and machine credentials as first-class identities, not as incidental application settings.

Why SIEM and EDR miss SaaS-native identity abuse

Security tools built around endpoints and infrastructure often miss the behavior that matters most in SaaS. A mass file export, a new OAuth grant, or an unusual admin action can look benign when stripped of identity and context. SaaS-native detection depends on permission change histories, login metadata, API activity, and identity-provider correlation. Without those signals, lateral movement may occur inside the application layer without tripping traditional alerts. The mechanism of abuse is legitimacy, not malware, which is why detection must understand how a trusted session behaves over time.

Practical implication: Correlate SaaS audit logs with identity telemetry and revoke sessions when behavior departs from expected access patterns.

Threat narrative

Attacker objective: The attacker aims to abuse legitimate SaaS trust relationships to reach sensitive data without triggering conventional perimeter controls.

1. Entry occurs through over-permissioned third-party or machine-to-machine access in SaaS, often via OAuth consent or exposed tokens.
2. Escalation follows when the compromised integration retains broad scopes that allow file export, mailbox access, or administrative actions beyond its normal purpose.
3. Impact is achieved through data exfiltration, unauthorized sharing, or stealthy lateral movement across connected SaaS applications.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Visibility is the actual control boundary for Zero Trust SaaS. The article is right to treat discovery as foundational, but the deeper lesson is that access policy cannot outrun inventory quality. If teams cannot see apps, tokens, and delegated identities, they are enforcing intent rather than control. Practitioners should treat discovery coverage as a governance metric, not a tooling detail.

OAuth and API credentials are operational identities, not configuration artifacts. Too many programmes still treat connected apps as vendor settings instead of non-human identities with lifecycle, scope, and revocation requirements. That framing mistake is what allows stale privileges to accumulate across SaaS estates. The right control model is lifecycle management, with expiry, review, and owner assignment for every delegated credential.

Identity blast radius is the most useful concept for SaaS governance. Once a token or integration is over-scoped, the damage path is defined by how far that identity can move across applications. That makes entitlement review, session monitoring, and rapid revocation more important than static trust assumptions. Practitioners should measure the blast radius of each SaaS identity, not just its presence.

Traditional IAM maturity does not automatically translate into SaaS resilience. Many organisations have strong directory controls yet weak control over app-to-app access and shadow integrations. That gap is now one of the clearest failure modes in Zero Trust programmes. The practical conclusion is simple: governance must extend from the identity provider into every SaaS connection that can authenticate or move data.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 38% have no or low visibility, according to The State of Non-Human Identity Security.
• The same research found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which shows how weak the operational baseline remains.
• For a wider control framework, see Ultimate Guide to NHIs , Standards for the standards most relevant to SaaS identity governance.

What this signals

Identity governance for SaaS is moving from periodic review to continuous exposure management. The programme implication is that teams can no longer rely on quarterly entitlement checks when apps can be added, consented, and forgotten in minutes. Link discovery to identity-provider telemetry and use NIST SP 800-207 Zero Trust Architecture as the baseline for continuous verification.

Ephemeral access without lifecycle controls creates ephemeral trust debt. Short-lived tokens reduce standing exposure, but they do not solve unmanaged consent, over-scoped integrations, or shadow SaaS. The operational answer is to tie every non-human credential to review, ownership, and revocation triggers, especially in collaboration and development platforms.

With 72% of organisations having experienced or suspected an NHI breach in the 2024 ESG Report: Managing Non-Human Identities, the issue is no longer whether SaaS identities are risky. The issue is whether the control model can see them fast enough to matter.

For practitioners

• Map every SaaS-connected identity Inventory human users, service accounts, OAuth apps, API keys, and automation bots across all approved and shadow SaaS services. Tie each identity to an owner, business purpose, and expiration condition.
• Enforce scope review on delegated access Compare granted scopes with actual usage for third-party apps and internal integrations. Downgrade admin rights where read-only access is sufficient and revoke dormant or unused connections.
• Correlate SaaS telemetry with identity signals Feed audit logs, login history, permission changes, and token activity into detection and response workflows. Use the NIST SP 800-207 Zero Trust Architecture model to verify requests continuously rather than once at login.
• Treat shadow SaaS as an NHI problem Discover unsanctioned apps that hold OAuth consent or API tokens, then classify them as unmanaged non-human identities. For control design, pair discovery with the OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs , Standards.

Key takeaways

• Zero Trust SaaS only works when organisations can continuously see every connected application, token, and machine identity.
• Third-party integrations and OAuth grants are now core NHI governance issues, not side effects of SaaS adoption.
• The practical priority is continuous discovery, scope review, and rapid revocation, because static IAM controls cannot contain dynamic SaaS trust relationships.

Key terms

• Zero Trust SaaS: Zero Trust SaaS is the application of zero trust principles to cloud application estates. Every access request, token use, and integration is continuously verified, with trust granted by evidence rather than by app approval or network location alone.
• Non-Human Identity: A non-human identity is any credentialed entity that acts in an environment without a person directly operating it. That includes service accounts, API keys, OAuth apps, certificates, bots, workloads, and AI agents, each of which needs ownership, scope control, and lifecycle governance.
• Identity blast radius: Identity blast radius is the amount of damage a credential, token, or account can cause if it is misused or compromised. In SaaS, it is shaped by scopes, app connections, data sharing paths, and how quickly the access can be detected and revoked.
• Scope drift: Scope drift is the gradual mismatch between what an integration was meant to do and what its credentials still allow it to do. It happens when permissions are not revalidated as business needs change, creating hidden over-privilege across SaaS and API-connected systems.

Deepen your knowledge

Zero Trust SaaS visibility and control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building policy around SaaS identities, it is worth exploring.

This post draws on content published by Wing Security: Zero Trust starts with SaaS visibility and control. Read the original.