Zero trust for SaaS security exposes the real IAM control gaps

At a glance

What this is: This analysis argues that zero trust can reduce SaaS risk, but only when identity inventory, access policy, and offboarding keep pace with sprawling app estates.

Why it matters: It matters because IAM teams are being asked to govern SaaS access across shadow IT, third-party apps, and fast-changing roles without losing control of entitlement scope.

By the numbers:

• Large enterprises use more than 1,000 SaaS tools, and that scale makes monitoring and access governance materially harder.

Context

SaaS security becomes a governance problem once the application estate outgrows manual review and the organisation can no longer see every app, connection, and entitlement in one place. In that environment, zero trust is not just a network design pattern, it is a control model for deciding whether identity, device, and context are trustworthy enough for access.

The article's core message is that shadow IT, remote access, overprivileged service accounts, and offboarding gaps all become more dangerous when SaaS sprawl accelerates. For identity teams, the question is not whether zero trust is a useful idea, but whether identity inventory, access policy, and deprovisioning are actually aligned across the full SaaS estate.

Key questions

Q: Where do SaaS zero trust programmes usually fail in practice?

A: They usually fail at inventory and entitlement alignment. Organisations may authenticate users centrally, but if shadow IT, unmanaged integrations, and stale app permissions remain outside governance, zero trust cannot prove that access is still justified. The failure is not the policy concept itself, but the inability to keep the app estate, identity state, and authorization scope synchronised.

Q: Why does SaaS sprawl create security risk as well as cost pressure?

A: SaaS sprawl increases the number of accounts, roles, permissions, and integrations that must be governed. Each additional application adds another place where access review, approval, and offboarding can fail. The result is not just wasteful spend but a larger, harder-to-audit identity surface across business systems.

Q: What are the signs that SaaS access settings are being misused or drifting out of policy?

A: Warning signs include unexpected permission changes, too many teams with administrative access, unapproved sharing links, new external users appearing in sensitive workspaces, and configuration changes that are not tied to a documented change request. Organisations should also watch for unusual access to collaboration tools outside normal hours, because attackers often exploit settings changes before data is removed.

Q: How should teams compare zero trust and SSPM for SaaS security?

A: They are complementary, not interchangeable. Zero trust governs whether a request should be allowed based on identity and context, while SSPM checks whether the SaaS tenant itself is configured safely enough for those decisions to be reliable. Teams need both when access risk comes from app posture as well as user entitlement.

Technical breakdown

Why SaaS sprawl breaks traditional access assumptions

Traditional access governance assumes the application inventory is stable enough to review and the access path is visible enough to certify. SaaS estates break both assumptions because new applications are added constantly, often outside central IT control, and each one can introduce its own identity store, integrations, and delegated access paths. That makes inventory a security control, not just an administrative record. When discovery lags behind adoption, organisations lose the ability to tell which identities can reach which data or services. In practice, the first failure is not authentication, it is incomplete visibility into the thing being authenticated.

Practical implication: treat SaaS discovery and inventory as the prerequisite control for access governance, not a reporting afterthought.

How zero trust changes SaaS authentication and authorization

Zero trust shifts the decision point from network location to identity and context. Instead of trusting a user or device because it is inside the perimeter, the model revalidates each request against identity signals, role, device posture, and access policy. In SaaS environments, that matters because users, contractors, and service accounts all reach the same apps from outside the corporate network. SSO centralises the authentication path, but it does not by itself solve authorisation scope or entitlement drift. The control value comes from pairing federated access with least privilege and ongoing context checks.

Practical implication: use zero trust to centralise authentication, then verify that authorisation decisions still reflect the actual SaaS role and context.

Why SSPM is the posture layer for SaaS governance

SaaS Security Posture Management exists because SaaS platforms often expose security flaws through configuration, excessive permissions, and weak default settings rather than through traditional perimeter attacks. SSPM evaluates those settings continuously and can identify where an application grants more access than a role requires or where a tenant configuration weakens the trust model. That makes it complementary to zero trust rather than redundant with it. Zero trust controls access requests; SSPM checks whether the SaaS environment itself is configured in a way that makes those requests safe to begin with.

Practical implication: pair SSPM with identity controls so misconfiguration and overprivilege are detected before access policy is asked to compensate.

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 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 alignment, not policy language, is the real SaaS zero trust test. The article correctly points to zero trust, SSO, least privilege, and SSPM, but the underlying issue is whether identity, inventory, and entitlement state stay in sync across a SaaS estate that keeps changing. A framework can be fully defined and still fail operationally if the organisation cannot prove what it owns, who can reach it, and which apps were never brought under governance. The practitioner conclusion is that alignment is the control, not the slogan.

Shadow IT is an identity governance problem before it is a security problem. When employees can buy and connect SaaS tools outside IT review, access control fragments across unmanaged tenants and delegated apps. That fragmentation weakens joiner-mover-leaver processes because the offboarding event no longer guarantees complete removal. The implication for IAM teams is that application discovery and lifecycle enforcement must be treated as one programme.

Zero trust for SaaS depends on entitlement minimisation at the application layer. Network-based segmentation can reduce exposure, but SaaS risk often sits inside application roles, OAuth grants, and overprovisioned service access. That is why identity-based segmentation and least privilege matter more than perimeter logic in this domain. The practitioner conclusion is that authorisation scope must be continuously tuned at the app layer, not assumed correct after login.

SaaS Security Posture Management is becoming the missing assurance layer for modern IAM. SSO tells you who authenticated, but not whether the SaaS tenant has drifted into excessive access, exposed integrations, or unsafe defaults. That gap is where SSPM belongs, because identity assurance without posture assurance leaves too much of the real risk unobserved. The implication for security leaders is to stop treating IAM and SaaS posture as separate programmes.

One-click deprovisioning is only decisive when it reaches every connected app. The article's offboarding argument is sound because removing access from the central identity provider does not automatically remove access from every SaaS tenant. That is a lifecycle governance issue, not just a tooling issue. The practitioner conclusion is that offboarding completeness must be measured at the application edge, not at the SSO gateway.

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

SaaS security now depends on governing the application estate, not just the login event. When an organisation has more than 1,000 SaaS tools, the access problem shifts from authentication to continuous visibility, entitlement review, and offboarding completeness. Zero trust helps, but only if the programme can prove the current inventory and the current authorisation state are the same thing.

SaaS posture and identity governance are converging. SSPM matters because SaaS misconfiguration and overprivilege often create the conditions that identity controls then inherit. Teams should expect the operational boundary between IAM, IGA, and SaaS security to keep blurring as more business processes move into third-party applications.

Shadow IT should be treated as a governance trigger, not an exception report. Once users can adopt SaaS tools outside central control, the organisation loses lifecycle consistency across onboarding, role change, and offboarding. The practical response is to make discovery, entitlement review, and deprovisioning part of the same control chain.

For practitioners

• Map the full SaaS estate Build an inventory that captures sanctioned apps, shadow IT, and all high-risk integrations so access governance starts from complete visibility.
• Bind offboarding to every connected tenant Verify that deprovisioning revokes access in each SaaS application, not only in the central identity provider or SSO layer.
• Reduce standing entitlement scope Review app roles, service-account permissions, and delegated access grants to remove privileges that exceed day-to-day job needs.
• Pair posture checks with access decisions Use SSPM findings to identify excessive permissions and insecure configurations before they become accepted access paths.

Key takeaways

• SaaS risk grows when application growth outpaces identity governance and the organisation can no longer see every app, integration, and entitlement clearly.
• Zero trust helps reduce exposure, but it only works when identity, device context, and authorization decisions stay aligned across the full SaaS estate.
• The strongest control posture combines centralised discovery, least privilege, SSPM, and complete offboarding at the application edge.

Key terms

• Shadow IT: Shadow IT is the use of applications or services outside formal enterprise approval or visibility. In SaaS environments, it often includes department-purchased tools and unsanctioned integrations that create hidden identity, data, and access paths the security team cannot readily govern.
• Software As A Service Security Posture Management: Software as a Service Security Posture Management is the continuous assessment and control of security settings, access, and data exposure across SaaS applications. It focuses on misconfigurations, excessive permissions, risky integrations, and weak governance. The discipline maps SaaS controls to policy, detects drift, and supports remediation before exposure becomes an incident.
• Identity-centric segmentation: Identity-centric segmentation is the practice of limiting access by identity, device, and authorised resource rather than by network location alone. It is especially relevant to defence environments because it reduces lateral movement and produces a clearer audit trail for compliance review.
• Offboarding Completeness: The extent to which departure handling removes access across every connected system, not just the primary directory or SSO layer. Complete offboarding includes revocation, ownership transfer, licence cleanup, and confirmation that no downstream trust remains active.

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 building or maturing an IAM programme, it is worth exploring.