Zero trust for SaaS security is now an identity governance problem

At a glance

What this is: This analysis argues that zero trust in SaaS security is mostly an identity, workload, and data governance problem rather than a network problem.

Why it matters: For IAM and NHI practitioners, the implication is that SaaS sprawl, over-privileged access, and unmanaged integrations must be governed continuously, not reviewed occasionally.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Valence Security's analysis of zero trust for SaaS security

Context

Zero trust in SaaS security starts with a simple problem: modern SaaS platforms make access easy to grant, but hard to govern at scale. When identities, connectors, workflows, and data shares proliferate across applications, least privilege becomes a continuous control problem rather than a one-time architecture choice. That is why the primary keyword here is zero trust, and why the discussion quickly becomes an IAM and NHI governance issue.

The article uses CISA’s Zero Trust Maturity Model to frame SaaS around identity, applications and workloads, and data, with visibility, automation, and governance as shared capabilities across those pillars. That framing is useful because SaaS environments now include service accounts, API-driven workflows, and delegated connectors that behave like NHIs even when the platform is marketed as a user-centric tool. The starting position is typical for enterprises adopting SaaS quickly and governing it slowly.

Key questions

Q: How should security teams apply zero trust to SaaS environments?

A: Start with identity and entitlement governance, not network controls. Map every user, service account, token, workflow, and integration that can touch SaaS data, then enforce least privilege, continuous review, and revocation when the business purpose ends. Zero trust fails in SaaS when access is treated as static instead of lifecycle-managed.

Q: Why do SaaS platforms create extra risk for NHI governance?

A: SaaS platforms create extra risk because they multiply non-human identities through connectors, APIs, automation, and delegated access. Those identities often receive broad scopes by default and are rarely reviewed at the same cadence as human accounts. The result is hidden standing privilege that expands blast radius and complicates incident response.

Q: What is the difference between zero trust and least privilege in SaaS security?

A: Least privilege is the access principle, while zero trust is the broader operating model that enforces continual verification, control, and governance. In SaaS, least privilege limits what an identity can do, and zero trust adds discovery, analytics, and automated revocation so that access stays justified over time.

Q: When should organisations automate SaaS access revocation?

A: Organisations should automate SaaS access revocation whenever access is tied to a task, workflow, vendor relationship, or temporary project. If a connector, share, or account no longer has a business purpose, waiting for a manual review leaves unnecessary exposure in place. Automation is most valuable where permissions change faster than humans can track them.

Technical breakdown

Zero trust in SaaS: why identity is the control plane

In SaaS environments, identity often becomes the real control plane because access is mediated through logins, SSO, delegated permissions, and API-based integrations. That changes the security problem from perimeter enforcement to per-request authorisation and entitlement hygiene. Users, admins, low-code workflows, and connector accounts can all accumulate access that outlives the business need. In practice, SaaS zero trust depends on the same core mechanisms used for NHIs: least privilege, continuous review, and lifecycle governance for every identity that can act on data or systems.

Practical implication: Treat SaaS identities, including non-human ones, as governed assets with owner, scope, and expiry.

Visibility, analytics, and the hidden SaaS blast radius

Zero trust cannot mature without visibility because organisations cannot reduce what they cannot see. In SaaS, visibility has to extend beyond named users to dormant accounts, external shares, over-privileged connectors, and unattended workflows that silently expand blast radius. The operational issue is that many of these permissions are created through application defaults or delegated admin paths, not deliberate risk decisions. That makes analytics a discovery function, but also a governance function, because it exposes where access is broader than policy intends.

Practical implication: Build reporting that surfaces dormant access, broad sharing, and unused integrations before they become standing risk.

Automation and orchestration for SaaS least privilege

Automation in SaaS security is not about speed for its own sake. It is about making revocation, access reduction, and lifecycle hygiene repeatable enough to keep pace with change. If a workflow connector only needs read access, or a data share no longer has a business purpose, policy should remove that access without waiting for manual review. This is where zero trust converges with NHI lifecycle management: access must be provisioned, checked, and removed on a defined schedule, not left to drift until the next audit.

Practical implication: Automate entitlement reduction and revocation for SaaS connectors, shares, and workflow accounts.

Threat narrative

Attacker objective: The objective is to turn broad SaaS delegation into durable access to data and workflows without needing to break the underlying platform.

1. Entry occurs through SaaS sign-up, delegated SSO, or a low-code connector that receives broader access than the business task requires.
2. Escalation follows when over-privileged roles, unused integrations, or data-sharing settings allow the identity to reach additional applications or datasets.
3. Impact is achieved when the attacker or rogue workflow exfiltrates data, maintains persistence through dormant permissions, or abuses SaaS-to-SaaS trust.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• 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

Zero trust in SaaS is really entitlement governance with better branding. The article is correct to treat identity, workloads, and data as the active control planes, but practitioners should recognize that these are also NHI surfaces. Every SaaS connector, workflow account, and delegated token behaves like an identity that can accumulate access. The discipline is not simply adopting zero trust language, it is enforcing ownership, scope, and revocation across every non-human access path.

Visibility is the prerequisite for any believable zero trust programme. A SaaS environment with hidden shares, dormant accounts, and unmanaged connectors is not zero trust ready, regardless of policy language. The governance gap is usually not a missing architecture diagram, but a missing inventory of who and what can still act. Teams should treat discovery as a control, because without discovery they are managing assumptions, not access.

Automation changes the economics of least privilege, but only if it is tied to lifecycle events. Manual cleanup does not scale across SaaS estates where permissions are created by users, apps, and integrations at machine speed. The better framing is lifecycle enforcement: provision narrowly, monitor continuously, and remove access as soon as the business purpose ends. That is the only way zero trust becomes operational rather than aspirational.

Identity blast radius is the right concept for SaaS risk. Once a single token, admin role, or connector can fan out across multiple applications, the attack surface is no longer the application itself but the trust chain behind it. That concept helps security teams prioritise where to reduce standing privilege first. The practitioner takeaway is to focus on the identities that can reach the most data, not just the identities with the most privileges on paper.

Zero trust for SaaS will keep failing wherever governance is treated as a reporting exercise. Reporting matters, but only when it drives action on access reduction, integration removal, and owner assignment. Organisations that stop at dashboards will preserve the same excess access under a more modern label. Teams should use governance to force lifecycle decisions, not just to document them.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• SaaS zero trust becomes operational when teams connect identity governance to lifecycle control, which is why NHI Lifecycle Management Guide is a useful next reference for revocation and ownership discipline.

What this signals

Identity blast radius is the best shorthand for what SaaS zero trust teams are actually managing. Once a connector, token, or admin role can fan out across multiple apps, the question becomes how quickly security can reduce the damage radius when access is mis-scoped. That is why control design should prioritise ownership, expiry, and revocation over static permission reviews.

With only 5.7% of organisations having full visibility into their service accounts, according to the Ultimate Guide to NHIs, SaaS zero trust programmes will keep underperforming unless they inventory machine identities with the same seriousness as user accounts. The reader takeaway is simple: if you cannot see the identity, you cannot govern the access.

The programme signal is clear for teams aligning to NIST SP 800-207 Zero Trust Architecture: discovery and policy enforcement must extend to SaaS connectors, workflow accounts, and delegated tokens. That means feeding identity inventory into access decisions, then using automation to remove access when trust is no longer justified.

For practitioners

• Implement SaaS identity inventories Map human and non-human identities across SaaS apps, including service accounts, connector tokens, and delegated admin roles. Assign an owner and a review cadence for every identity that can read, write, or share data.
• Automate entitlement reduction Use policy to remove unused permissions, stale shares, and abandoned integrations on a scheduled basis. Prioritise accounts that can create workflows, edit connectors, or access sensitive data sets.
• Tie revocation to lifecycle events Trigger access review and revocation when employment changes, app ownership changes, or workflows are retired. SaaS permissions should expire with the business need, not remain active until the next audit.

Key takeaways

• SaaS zero trust is primarily an identity governance problem because access now flows through users, workflows, connectors, and tokens.
• Hidden permissions matter more than architectural slogans, and unmanaged SaaS integrations can expand blast radius faster than manual reviews can catch up.
• Teams should pair discovery with automated revocation so that least privilege survives the full identity lifecycle.

Key terms

• Zero Trust Architecture: Zero Trust Architecture is a security model that assumes no implicit trust between users, devices, services, or workloads. In practice, it requires continuous verification, least privilege, and policy-driven access decisions based on context rather than network location.
• Non-Human Identity: A non-human identity is any digital identity used by software, systems, or automation rather than a person. That includes service accounts, API keys, tokens, certificates, and AI agents. These identities need ownership, scope, and lifecycle governance because they can access sensitive systems at machine speed.
• Identity Blast Radius: Identity blast radius is the amount of access and downstream impact an identity can create if it is misused or compromised. The larger the entitlement set and application reach, the harder it becomes to contain abuse. This is a practical way to prioritise NHI and SaaS access reduction.

Deepen your knowledge

Zero trust in SaaS security and NHI lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance across SaaS identities, connectors, and delegated access, it is worth exploring.

This post draws on content published by Valence Security: What Does Zero Trust Mean for SaaS Security? Read the original.