Notifications
Clear all
Topic starter
12/06/2026 1:02 am
TL;DR: SaaS-heavy environments need continuous verification, least privilege, RBAC, and full offboarding across connected apps rather than trust inside the perimeter, according to Zluri. The practical message is that identity governance now has to follow the application and the credential, not just the user, because SaaS access outlives the old network boundary.
NHIMG editorial — based on content published by Zluri: Security & Compliance Implementing Zero Trust - A SaaS Management Perspective
By the numbers:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: What breaks when zero trust stops at SSO in SaaS environments?
A: Access removal becomes incomplete because SaaS applications often retain direct grants, delegated connections, and local admin roles after the directory account is disabled.
Q: Why do SaaS environments make least privilege harder to enforce?
A: SaaS access spreads across many applications, vendors, and shared roles, so privilege scope is easy to overstate at provisioning time and hard to correct later.
Q: How can security teams tell whether deprovisioning is actually working?
A: They should check whether access disappears from the directory, the application, and any linked vendor or token path.
Practitioner guidance
- Map all SaaS access paths beyond SSO Inventory direct app grants, delegated vendor access, API-linked entitlements, and admin roles that remain active after directory changes.
- Separate role design from privilege scope Review RBAC structures and least-privilege settings as two different controls.
- Validate deprovisioning in the application layer Require offboarding checks that confirm retrieval, revocation, and reassignment across every critical SaaS app.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Centralised SaaS inventory discovery methods and how the platform claims to map applications and access paths
- One-click deprovisioning workflow details, including retrieval, revocation, and reassignment steps
- Examples of how sign-in logs, audit logs, and access logs are used to confirm offboarding
- Practical description of how RBAC and least privilege are positioned inside the SaaS management workflow
👉 Read Zluri's zero trust guidance for SaaS identity and access control →
Zero trust for SaaS identities - what governance gap are teams missing?
Explore further
12/06/2026 10:40 am
Zero trust for SaaS is really an access lifecycle problem, not just a network model. The article focuses on verification and least privilege, but the underlying governance issue is that SaaS access persists across app layers that SSO alone does not control. Once access is fragmented across vendors, direct entitlements, and shared admin roles, the real boundary is the identity lifecycle. Practitioners should treat SaaS zero trust as a control-plane question, not a perimeter replacement.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a former user still has SaaS access?
A: Accountability sits with the identity and application owners who approved, maintained, and verified the offboarding workflow. In practice, this is an access governance failure, not just a help desk issue, because the control expected to remove access did not cover the full application estate.
👉 Read our full editorial: Zero trust for SaaS identities: what IAM teams need to know
