Zero trust for SaaS security is now an identity governance problem

At a glance

What this is: Valence Security argues that zero trust in SaaS becomes an identity governance problem because access, sharing, and SaaS-to-SaaS permissions are where least privilege breaks down.

Why it matters: IAM and governance teams need to treat SaaS permissions, external sharing, and unmanaged integrations as first-class zero trust controls across human, NHI, and automation-driven access.

Context

Zero trust for SaaS security is really a governance problem because SaaS collapses the old boundaries of network and device control while expanding identity, application, and data exposure. In practice, the question is no longer whether access exists, but whether it is visible, least-privileged, and continuously governed across dozens of apps and integrations.

Valence Security frames SaaS through CISA's zero trust maturity model, with identity, applications and workloads, and data carrying most of the operational burden. That matters for IAM teams because SSO, MFA, connector permissions, external sharing, and dormant accounts now define the real attack surface more than the SaaS login screen itself.

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 NHIs complicate zero trust and least privilege efforts?

A: NHIs complicate zero trust because they are numerous, persistent, and often tightly integrated into applications and pipelines. If teams cannot see every identity or keep permissions aligned to actual usage, they cannot consistently prove least privilege. Continuous review and revocation are essential, not optional.

Q: What are the signs that zero trust is not working across the SaaS layer?

A: Common warning signs include shadow SaaS, inconsistent security settings across applications, unsecured integrations, and the absence of a central dashboard for locating and monitoring apps. If teams cannot tell which SaaS tools are sanctioned, who can access them, or how policies are enforced, zero trust is only partial and mostly theoretical.

Q: How do IAM teams keep low-code SaaS automation from widening access?

A: They should separate workflow administration from connector privileges and review each automation account as a distinct access path. If the same identity can build workflows, connect to multiple apps, and move data between them, the blast radius grows faster than the control model. Narrow connector scope is the key boundary.

Technical breakdown

Why SaaS shifts zero trust from the network to identity governance

SaaS removes much of the traditional infrastructure perimeter, so the effective control points move to identity, application permissions, and data sharing. Zero trust in this model is not about blocking the network first. It is about enforcing least privilege on users, admins, connectors, and automated workflows that can all expand access if left ungoverned. The important technical point is that SaaS often authenticates easily through federation, but authorisation remains fragmented across applications, roles, and embedded integrations. That fragmentation is why governance has to follow the identity, not the device or network segment.

Practical implication: map zero trust controls to SaaS identity and permission paths, not to network boundaries that SaaS largely bypasses.

How SaaS automation creates overprivileged workflows

Low-code and no-code platforms behave like application layers with multiple permission planes. A workflow may need rights to create, edit, or delete automation objects, while its connectors need separate access to the SaaS services they touch. If those layers are not separated, the workflow inherits more privilege than the task requires. The same problem applies to API-driven automation in SaaS, where connector credentials can quietly become broad, durable access paths. The control issue is not automation itself. It is whether each automation component has a narrow, auditable permission scope.

Practical implication: separate workflow management permissions from connector permissions and review each connector as an NHI credential path.

Why data sharing and dormant accounts demand governance, not just detection

SaaS makes sharing easy, which is useful for collaboration and dangerous for control. Once a data object is shared broadly, the exposure can persist unless permissions are explicitly revoked. Dormant accounts and abandoned integrations create the same pattern in different forms: access that no longer serves a business purpose remains active because no lifecycle process closed it. In zero trust terms, this is where visibility has to feed governance actions, not just dashboards. A mature programme should treat unused access as risk, even when nothing looks actively malicious.

Practical implication: connect discovery of dormant accounts, open links, and unused integrations to enforced revocation and recertification workflows.

Threat narrative

Attacker objective: The attacker aims to turn routine SaaS convenience into durable access to data, workflows, and downstream services.

1. Entry occurs through SaaS adoption, single sign-on, or low-friction sign-up paths that expand the identity surface without equivalent governance.
2. Privilege escalation follows when admins, connectors, or workflow accounts receive broader access than the business task requires.
3. Impact emerges through over-shared data, abused SaaS-to-SaaS integrations, and dormant access paths that remain available long after their business value has ended.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

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 an identity governance discipline, not a network design exercise. SaaS moves control away from perimeter enforcement and into the quality of identity, application, and data entitlements. That means the operational question is whether access can be continuously governed across users, admins, connectors, and sharing paths. Practitioners should treat SaaS zero trust as an entitlement management problem first and a visibility problem second.

Automated SaaS workflows create an identity blast radius that most IAM programmes under-model. Low-code tools, connectors, and SaaS-to-SaaS integrations can chain permissions in ways that are easy to stand up and hard to bound. Once the workflow credential can act across multiple services, the privilege scope is no longer confined to the originating app. The implication is that entitlement review has to include automation accounts and connector permissions, not just end users.

Least privilege fails in SaaS when sharing and delegation outrun lifecycle governance. The article's core pattern is not that SaaS lacks controls, but that convenience creates standing access faster than teams can recertify it. That is why dormant accounts, unmanaged identities, and open data shares matter as governance failures rather than isolated misconfigurations. Practitioners should expect zero trust maturity to rise only when access removal becomes as operationalized as access creation.

Visibility without enforcement is not zero trust maturity. CISA's pillars make the sequence clear: discover exposure, automate control, then govern consistently. In SaaS, teams often stop at discovery because the environment is easy to observe and hard to standardise. The real maturity test is whether overprivileged roles, external sharing, and abandoned integrations are reduced through repeatable policy actions. Practitioners should measure zero trust progress by revoked access, not by dashboards alone.

Identity governance for SaaS should be measured by permission decay. When access persists after the business need ends, the organisation accumulates exposure that zero trust is meant to shrink. That decay is visible in dormant accounts, unused integrations, and broad sharing settings that stay active by default. The practical conclusion is straightforward: if permissions are not being retired, the zero trust programme is only partially functioning.

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.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs

What this signals

Permission decay is the SaaS zero trust problem teams underestimate. Access in SaaS environments often survives longer than the business need, especially when sharing links, connector tokens, and dormant accounts are treated as low-priority exceptions. Security teams should measure progress by how quickly they remove standing access, not by how many applications they can observe.

Zero Trust Architecture only works in SaaS when governance is operationalised at the entitlement layer. That means identity reviews, connector scope, and data-sharing controls must be tied to enforcement, not left as periodic reporting. Teams that cannot close the loop from discovery to revocation are describing maturity, not achieving it.

For practitioners

• Enforce identity-first zero trust in SaaS Anchor zero trust reviews on SaaS identities, roles, and sharing paths rather than network location or device trust. Include human users, admins, service connectors, and workflow accounts in the same entitlement review cycle.
• Separate workflow and connector privileges Give low-code and no-code platforms distinct permissions for workflow administration and connector access, then limit each connector credential to the specific SaaS actions it needs.
• Automate revocation of dormant access Use policy to remove abandoned accounts, inactive integrations, and open data shares when business justification no longer exists, and tie those removals to recertification evidence.
• Treat SaaS discovery as governance input Feed visibility data on overprivileged users, unmanaged identities, and external sharing into automated governance actions so discovery leads to entitlement reduction.
• Review SaaS zero trust against CISA's pillars Test whether identity, applications and workloads, and data controls are being enforced consistently, then track reductions in standing access as the success metric.

Key takeaways

• Zero trust for SaaS is mostly a governance problem because identity, sharing, and integration paths now carry the largest access risks.
• SaaS convenience amplifies overprivileged roles, dormant accounts, and connector sprawl, which makes visibility alone insufficient.
• Teams should measure success by how much standing access they remove and how consistently they enforce least privilege across users, workflows, and data.

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 Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
• Connector Credential: A non-human identity credential used by an integration, automation, or workflow to access another service. In SaaS programmes, connector credentials need explicit scope, inventory, and lifecycle control because they often become durable access paths across multiple applications.
• Ownership Decay: A governance failure where an AI identity remains active but no one can clearly own its access decisions or retirement. It often appears after team changes, project closure, or platform sprawl, and it breaks accountability before it breaks technical access.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.