Zero trust for SaaS security exposes the real IAM control gaps

At a glance

What this is: A Zero Trust-based view of SaaS security that ties app sprawl, least privilege, SSO, and SSPM to identity control gaps.

Why it matters: It matters because IAM, IGA, and PAM teams need a way to govern SaaS access, third-party exposure, and offboarding across both human and non-human identity surfaces.

By the numbers:

• On average, large enterprises utilize more than 1,000 SaaS tools, constantly increasing as new applications are introduced.

👉 Read Zluri's analysis of Zero Trust for SaaS security and access control

Context

SaaS security breaks down when organisations lose track of which applications, identities, and permissions exist across the environment. In large estates with more than 1,000 SaaS tools, the control problem is no longer just authentication, it is governance over inventory, access scope, and third-party exposure.

Zero Trust helps here because it assumes no request is trusted by default and every access decision must be verified in context. For IAM, IGA, and PAM teams, the practical question is whether that model can still hold when SaaS sprawl, shadow IT, and outsourced application control make identity and entitlement data incomplete.

Key questions

Q: How should security teams govern SaaS access under a Zero Trust model?

A: They should base access on verified identity, current context, and least privilege, then continuously re-check those conditions as the environment changes. The critical step is connecting identity governance to application inventory so policy decisions reflect the apps and permissions that actually exist, not the ones teams assume exist.

Q: Why do SaaS environments make least privilege harder to enforce?

A: Because access is spread across many applications, integrations, and ownership models, often outside a single directory. As the environment grows, permissions become harder to see, review, and remove, which increases the chance of standing privilege and orphaned access across business-critical tools.

Q: What breaks when offboarding only removes SSO access?

A: Users can still retain direct access, delegated tokens, or app-specific permissions inside individual SaaS products. That leaves a former identity partially active even after the main account is disabled, which creates residual exposure and weakens audit confidence.

Q: Who is accountable for SaaS security when third-party apps are involved?

A: Accountability usually sits with the enterprise that approved the app and its access, even if a vendor hosts the service. Security, IAM, and application owners need shared ownership for discovery, review, and revocation, because outsourced control does not remove governance responsibility.

Technical breakdown

Zero Trust for SaaS access decisions

Zero Trust in SaaS is a policy model that evaluates each request using identity, device, location, and context before allowing access. Rather than trusting the network boundary, it treats every application request as potentially hostile until verified. In SaaS environments this matters because users, devices, and apps are distributed across third-party services that the enterprise does not fully control. The model works only if identity data is current enough to support the decision and if policy enforcement is consistent across applications.

Practical implication: centralize identity signals and enforce contextual access checks before approving SaaS access.

Least privilege and service account exposure

Least privilege in SaaS means granting only the minimum access needed for a role or workload, then narrowing that access as the use case changes. The article correctly links this to service accounts, which often accumulate broad permissions because they are set up once and then left alone. In practice, this becomes a standing privilege problem. If those accounts can reach more apps or data than required, a compromised credential can move laterally far beyond its intended purpose.

Practical implication: review service account scopes separately from human roles and remove excess access that no workflow actually needs.

SSPM, inventory, and offboarding gaps

SSPM is the control layer that discovers SaaS configurations, flags weak settings, and helps teams correct exposure. Its value depends on knowing what apps exist in the first place, because shadow IT and unmanaged subscriptions often bypass central governance. The article also ties this to offboarding, where access must be removed across every connected application, not just the primary directory. Without complete inventory and de-provisioning, former access can persist long after employment ends.

Practical implication: pair SaaS discovery with de-provisioning that reaches every connected application, not just the core directory.

Threat narrative

Attacker objective: The attacker wants durable access to SaaS applications and the data or actions those applications expose.

1. Entry occurs through unmanaged SaaS adoption, shadow IT, or third-party access paths that sit outside central review.
2. Escalation happens when overprivileged accounts, weak verification, or incomplete offboarding leave access broader than the business need.
3. Impact follows as stolen or stale access can reach regulated data, increase breach blast radius, and complicate audit evidence.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 is really a SaaS identity governance test, not just a network model. The article frames Zero Trust as a way to control SaaS risk, but the deeper issue is whether identity, entitlement, and application data stay aligned when the application estate is fragmented. That is an IGA problem as much as a security architecture problem. If you cannot inventory the apps, you cannot verify the access context.

Standing SaaS privilege is the failure mode this model is trying to contain. The article’s service account example reflects a broader governance pattern: access is provisioned once, then allowed to persist across changing business needs. That creates an identity blast radius when credentials are reused or never narrowed. Practitioners should read this as a control gap in entitlement lifecycle management, not a feature of SaaS operations.

Shadow IT turns Zero Trust into an assumption problem. Zero Trust depends on reliable identity and asset visibility, yet shadow IT means the organisation may not know which apps exist or which identities can reach them. The result is not only policy failure but decision failure, because the programme cannot verify what it cannot see. The implication is that SaaS governance has to start with discovery before it can mature into enforcement.

SSPM is useful only when it is tied to lifecycle control and not treated as a standalone scanner. The article links posture management, access review, and offboarding, which is the right direction. Weak configuration matters, but so does whether dormant accounts, stale permissions, and orphaned app access are actually removed. Without that linkage, security teams improve visibility without reducing exposure.

Identity containment in SaaS now spans human users, service accounts, and third-party integrations. The article touches all three even when it uses generic Zero Trust language. That is the real governance change: the same control family must cover interactive access, machine access, and delegated app access. Practitioner teams should therefore evaluate SaaS controls across the full identity lifecycle, not only at login.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and 47% have only partial visibility, according to The State of Non-Human Identity Security.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• For a broader lifecycle view, see NHI Lifecycle Management Guide for provisioning, rotation, offboarding, and access review practices.

What this signals

Identity containment is becoming a SaaS baseline, not a specialist control. As SaaS estates expand, teams will need a single view of inventory, entitlements, and offboarding across human accounts, service accounts, and third-party connections. The governance gap is not just posture drift, it is whether the organisation can prove who still has access after business change.

With 85% of organisations lacking full visibility into OAuth-connected vendors, the discovery problem is already a control problem. That level of opacity means Zero Trust cannot be enforced consistently unless application discovery, identity governance, and revocation are tied together. Practitioners should expect SaaS risk reporting to shift from app count to access lineage and lifecycle state.

Least privilege in SaaS will increasingly be measured by blast radius, not by policy intent. If service accounts and delegated integrations remain over-scoped, then a single credential compromise can still spread far beyond its original function. The next maturity step is to treat access scope, not just authentication strength, as the primary control boundary.

For practitioners

• Map your SaaS inventory to a verified identity source Start with a complete application register that includes shadow IT, third-party integrations, and business-owned subscriptions. Tie each app to an owner, an auth method, and a review cadence so access decisions are based on current inventory rather than assumptions.
• Separate service accounts from human role reviews Review machine and service account permissions on their own schedule, with explicit checks for overprivileged access, stale tokens, and unused app reach. Human recertification does not reliably catch workload access that never appears in employee-centric workflows.
• Extend de-provisioning past the primary directory When an employee or contractor leaves, revoke access in every connected SaaS application, not only in SSO or the HR-linked directory. Confirm that licenses, audit trails, and delegated app permissions are also removed or reassigned.
• Use SSPM to enforce, not just observe Treat posture findings as triggers for entitlement correction, configuration hardening, and access removal. If SSPM only reports weak settings without driving remediation, it adds visibility but leaves the risk untouched.

Key takeaways

• Zero Trust helps with SaaS security, but only when identity inventory and entitlement governance are accurate enough to support the model.
• Overprivileged service accounts, shadow IT, and incomplete offboarding are the practical failure modes that turn SaaS sprawl into breach exposure.
• Teams should pair SaaS discovery with lifecycle revocation, posture enforcement, and access reviews that cover both human and non-human identities.

Key terms

• Zero Trust: A security model that assumes no user, device, or application should be trusted by default. Access is granted only after verification and is continuously re-evaluated as context changes, which makes it useful when SaaS estates are distributed and ownership is fragmented.
• SaaS Security Posture Management: A control layer that discovers SaaS applications, checks configurations against policy, and helps teams remediate exposure. It is most effective when paired with inventory and lifecycle management, because posture findings are only useful if the underlying application and identity state is known.
• Service Account: A non-human identity used by software, integrations, or automated processes to access systems and data. These identities often persist longer than human accounts and can become high risk when they accumulate broad permissions, stale credentials, or weak ownership.
• Shadow IT: Software or services adopted outside central IT or security oversight. In SaaS programmes, shadow IT creates visibility gaps that weaken access governance, because the organisation may not know which applications exist, who owns them, or which identities can reach them.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance Use Zero Trust Security to Address SaaS Security Concerns. Read the original.