TL;DR: SaaS management platforms are presented as a way to discover shadow IT, rightsize licenses, and improve onboarding, offboarding, and compliance, according to Zluri. The governance issue is broader than SaaS cost control: unmanaged app access is also an identity lifecycle problem that weakens visibility, accountability, and deprovisioning discipline.
At a glance
What this is: This article argues that SaaS management platforms help uncover shadow IT, reduce license waste, and close offboarding gaps by centralising visibility and control over application access.
Why it matters: It matters because unmanaged SaaS access is an identity governance problem as much as a cost problem, and IAM teams need a reliable way to see, approve, and revoke access across the app estate.
By the numbers:
- More than 30% of the SaaS budget is wasted every year, according to Gartner as cited by Zluri.
Context
SaaS management platforms address a visibility and governance gap that spreadsheets and partial SSO coverage do not close. In practice, organisations often lose track of which applications are approved, which are redundant, and which identities still hold access after role changes or offboarding.
For identity teams, the issue is not only cost control. SaaS sprawl creates unmanaged access paths, weakens deprovisioning discipline, and makes it harder to prove that application access is still aligned to business need and lifecycle state.
Key questions
Q: What breaks when SaaS access reviews rely on spreadsheets?
A: Spreadsheets freeze access data in time, so reviewers work from stale exports while roles, teams, and app usage keep changing. That creates entitlement drift and weak evidence for auditors. A better model is recurring review automation with current usage, department, and risk context, plus direct remediation from the review step.
Q: Why does SSO not solve SaaS access governance on its own?
A: SSO centralises authentication, but it does not eliminate app-local licenses, OAuth tokens, file ownership, or external sharing links. Many SaaS controls still live inside the application, so access can persist after directory deprovisioning. Teams need lifecycle controls that reach beyond the IdP and into the app itself.
Q: What should teams get wrong about offboarding in SaaS environments?
A: They often assume disabling the primary account is enough. In reality, offboarding must also remove app-specific accounts, revoke OAuth tokens, and confirm that shadow IT services do not retain access. If the app estate is only partially known, offboarding is partial by definition and leaves residual access behind.
Q: When should organisations prioritise SaaS management over spreadsheet-based tracking?
A: They should prioritise it once the number of apps or users makes manual tracking unreliable. If the organisation cannot answer which apps are approved, which are redundant, and who still has access, the process has already outgrown spreadsheets and needs governed automation.
Technical breakdown
How SaaS discovery exposes shadow IT and redundant access
A SaaS management platform typically connects to usage sources, application integrations, and admin data to build an inventory of active apps and users. That matters because shadow IT is not just unknown software, it is unknown access, which means approvals, ownership, and review evidence are missing. Discovery also reveals duplicate, unused, and underused applications, which helps distinguish business demand from access drift. In governance terms, the platform is building an application control plane around the SaaS estate rather than depending on manual reporting.
Practical implication: inventory the SaaS estate from system data, not spreadsheets, so approval and ownership can be attached to real usage.
Why offboarding fails when SaaS access is not centrally governed
Offboarding breaks when access removal depends on manual follow-up across many applications. The article’s core example is the ex-employee who may still have access to applications after leaving, often without anyone seeing what happens inside those apps. That is a lifecycle failure, not just an admin inconvenience. The missing control is consistent deprovisioning across the application layer, including license transfer, cancellation, and access revocation tied to identity state changes.
Practical implication: tie offboarding to application-level revocation so departed users do not retain residual SaaS access.
Why SSO alone does not solve SaaS governance
SSO covers authentication into a subset of applications, but it does not equal full application governance. The article notes that many more apps exist than are covered by SSO, and that direct integrations are needed to get accurate usage data from the source of truth. In other words, SSO may authenticate the user, but it does not necessarily inventory the app, govern renewal, or surface orphaned access. Governance requires visibility at the application boundary, not only at sign-in.
Practical implication: use SSO as one input, but not as the control boundary for SaaS inventory, access review, or renewal decisions.
Threat narrative
Attacker objective: The practical risk is persistent, ungoverned access to business applications and the data inside them, not just license waste.
- Entry occurs when users adopt SaaS applications outside sanctioned procurement or governance processes, creating shadow IT that the organisation does not inventory.
- Credential or account persistence occurs when former employees or redundant users retain access because offboarding does not reliably revoke every application entitlement.
- Impact follows when unmanaged access, wasted licenses, and weak audit evidence combine into security exposure, compliance risk, and avoidable SaaS spend.
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
Shadow IT is an identity governance problem before it is a SaaS cost problem. The article frames discovery and cost optimisation as the visible benefits, but the deeper issue is that unmanaged applications also mean unmanaged access relationships. If the application is outside governance, so are approval, ownership, review, and offboarding discipline. Practitioners should treat SaaS discovery as a control map for the identity lifecycle, not as a procurement report.
Spreadsheet-based SaaS control fails because lifecycle evidence disappears as soon as access changes. Manual tracking can record a licence, but it cannot reliably show whether a user still needs the app, whether access was removed everywhere, or whether a departed employee still holds a live entitlement. That is why governance breaks first in the offboarding and recertification phases. The operational conclusion is that access state must be managed at the application boundary, not reconstructed later from spreadsheets.
Direct SaaS integrations create a more accurate governance model than SSO coverage alone. SSO answers a sign-in question, but SaaS governance needs usage, ownership, and deprovisioning data from the app itself. This sharpens a named concept: application-bound identity governance. In practice, the control object is the application and its entitlements, not just the login event. IAM teams should therefore anchor governance to the SaaS estate, not to the authentication layer.
Renewal, approval, and deprovisioning must be governed as one lifecycle, not three separate processes. The article links licence renewal, app approval, and offboarding in the same operational story, which is the right framing. If these processes are separated, redundant apps persist, budgets leak, and access remains after need has ended. The implication for practitioners is to collapse SaaS app review into one lifecycle workflow that spans request, use, renewal, and removal.
Security and compliance evidence now depends on the same inventory that controls spend. The article notes that unmanaged apps can create fines and lawsuits when sensitive information sits in unknown places. That makes the governance problem cross-functional: IT, security, finance, and audit all need the same authoritative application view. Practitioners should stop treating SaaS management as a finance-only optimisation and start treating it as a shared control surface for identity and risk.
What this signals
Application-bound identity governance: SaaS control works only when the control object is the application and its entitlements, not the spreadsheet that describes them. That shift matters because approval, renewal, and offboarding all fail when they are separated from the live app estate.
The practical signal for IAM teams is that SSO coverage is not a sufficient operating model for shadow IT. If direct integrations do not feed inventory and entitlement decisions, the organisation will keep discovering access issues after the fact rather than governing them at issuance time.
For practitioners
- Map the SaaS estate from application data Build an inventory from direct integrations, usage data, and admin sources so approved, redundant, and shadow applications are visible in one place.
- Tie offboarding to application-level revocation Remove access at the application boundary when users leave, then verify that licences are transferred or cancelled rather than left active.
- Use renewal review as an access control checkpoint Treat contract renewal as a governance event that checks whether the application is still needed, who owns it, and whether current users still require access.
- Do not rely on SSO as the SaaS control boundary Use SSO as one signal, but retain direct application visibility for inventory, entitlement review, and deprovisioning decisions.
Key takeaways
- SaaS management platforms address a governance blind spot by revealing apps, users, and entitlements that are invisible in manual tracking.
- The biggest operational risk is not only wasted spend but lingering access after role change or offboarding.
- IAM teams should govern SaaS through direct application visibility, renewal review, and application-level deprovisioning.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article centres on leftover SaaS access after employees leave or apps go unmanaged. |
| NHI-05 — Overprivileged NHI | Redundant and unused app access creates excess entitlement beyond current business need. | |
| Recommendation — Tie offboarding to application-level revocation so departing users do not keep live SaaS entitlements. Review SaaS entitlements against current role need and remove access that no longer serves a business purpose. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing permissions and authorizations across SaaS apps. |
| Recommendation — Maintain authoritative entitlement records for SaaS applications and reconcile them against identity state changes. | ||
| CIS Controls v8 | CIS-5 — Account Management | The lifecycle problem described here is classic account and access management across many apps. |
| Recommendation — Centralise account tracking and revoke stale SaaS access promptly when users change roles or leave. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article discusses credential and access persistence across application lifecycles. |
| Recommendation — Manage SaaS authenticators and access tokens so dormant or departed users cannot retain access. | ||
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.
- SaaS Management Platform: A SaaS management platform is a visibility and optimisation layer for cloud software use. It helps teams discover applications, track utilisation, and understand spend patterns, but it does not by itself enforce access policy, revoke permissions, or manage identity lifecycle state.
- Application-Level Deprovisioning: Application-level deprovisioning is the process of removing a user’s account, roles, licenses, and related credentials inside the target application itself. It is stronger than disabling SSO because it reaches beyond the login path. Without it, access can survive even after identity-provider access has been turned off.
- Entitlement Drift: Entitlement drift is the slow accumulation of permissions that no longer match the original purpose, role, or workload. In cloud-native and NHI-heavy environments, it usually happens because access changes faster than review cycles, leaving organizations with more privilege than they intended.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management 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 or identity governance programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org