Notifications
Clear all
Topic starter
12/06/2026 9:06 pm
TL;DR: SaaS estates now span more than 1,000 applications in large enterprises, and Zluri argues that Zero Trust, least privilege, SSO, and SSPM are the main controls needed to reduce exposure from shadow IT, overprivileged access, and weak offboarding, according to Zluri. The harder problem is not policy design but proving that identity, access, and application inventory stay aligned as SaaS sprawl grows.
NHIMG editorial — based on content published by Zluri: Security & Compliance Use Zero Trust Security to Address SaaS Security Concerns
By the numbers:
- On average, large enterprises utilize more than 1,000 SaaS tools, constantly increasing as new applications are introduced.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- How Zluri applies discovery methods to build a centralized SaaS inventory across the environment.
- How its approach maps RBAC, least privilege, and one-click de-provisioning into day-to-day administration.
- How the article frames SSPM as an operational control for finding and fixing weak SaaS configurations.
- How the source connects HR-driven lifecycle changes to SSO and app-level permission decisions.
👉 Read Zluri's analysis of Zero Trust for SaaS security and access control →
SaaS security and zero trust: what IAM teams still miss?
Explore further
12/06/2026 10:58 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Zero trust for SaaS security exposes the real IAM control gaps
