TL;DR: SaaS adoption is creating a shadow IT problem that traditional surveys, SSO, CASB, ITAM, and SAM tools only partially expose, while Zluri argues that nine discovery methods are needed to map usage across the enterprise, according to Zluri. Shadow IT is now an identity governance and access visibility issue, not just an application inventory problem.
At a glance
What this is: This is an analysis of why SaaS shadow IT remains hard to find and why common discovery methods expose only partial visibility into the application estate.
Why it matters: For IAM and IGA teams, incomplete SaaS discovery means access, license, and offboarding decisions are being made against an unreliable inventory, which weakens governance across human and non-human usage.
By the numbers:
- 97% of cloud apps used in the enterprise are shadow IT, unmanaged, and often freely adopted, according to Netspoke research cited by Zluri.
Context
SaaS shadow IT is a visibility and governance gap, not only an inventory problem. When teams can adopt cloud apps in minutes, traditional software discovery assumptions break because the control point moves from procurement to user-led adoption.
In this article, Zluri argues that surveys, SSO, CASB, ITAM, and SAM all leave blind spots in SaaS discovery. The practical issue for identity programmes is that access governance depends on knowing which apps exist, who can reach them, and which identities are already using them.
The underlying challenge is that SaaS usage now spans sanctioned and unsanctioned tools, often outside the normal lifecycle and entitlement workflows. That makes shadow IT a governance issue for human access, delegated access, and broader identity surface management.
Key questions
Q: How should IAM teams discover SaaS apps that are not tied to SSO?
A: Use multiple evidence sources, including finance data, direct app integrations, directories, and endpoint or browser signals, rather than relying on SSO alone. SSO shows federated access, but many SaaS tools are adopted outside that path. The goal is to build a reconciled inventory that can support access reviews, ownership assignment, and offboarding.
Q: Why do ITAM and SAM miss shadow IT in SaaS environments?
A: They miss it because they were built around hardware and on-premise software, not browser-delivered subscriptions created outside traditional procurement flows. SaaS adoption often happens through self-service sign-up or business-led purchasing, so endpoint-focused inventory leaves a gap where access exists but the governance team cannot see it.
Q: What breaks when SaaS discovery is not connected to governance workflows?
A: Discovery becomes reporting instead of control. If newly found applications are not routed into ownership, certification, and remediation processes, teams may know an app exists but still fail to manage access, licensing, or offboarding. The result is a visible inventory with no governance effect.
Q: When should security teams treat an app as shadow IT rather than an approved tool?
A: Treat an app as shadow IT when it exists outside the governed acquisition, approval, or identity lifecycle, even if users adopted it for legitimate work. The key signal is not whether the tool is popular, but whether IT can verify ownership, access paths, and lifecycle control.
Technical breakdown
Why traditional discovery methods miss SaaS shadow IT
Traditional discovery methods were built for software and infrastructure that sit behind procurement, installation, or network controls. SaaS breaks that model because users can self-provision apps, connect them through browser-based access, or pay with a corporate card without passing through central onboarding. Surveys depend on self-reporting, SSO only sees apps that use federated login, CASB visibility is uneven across SaaS usage patterns, and ITAM or SAM were designed primarily for on-premise assets and licenses. The result is partial coverage, not a complete identity-to-app map.
Practical implication: treat every single discovery source as a partial control and reconcile them into one governed application inventory.
What nine discovery methods change for SaaS visibility
Nine discovery methods matter because no single telemetry source can prove the full SaaS footprint. Identity providers, finance systems, direct app integrations, directories, and optional endpoint or browser signals each expose a different layer of evidence about app use, ownership, and access. The technical point is not that more data is always better, but that SaaS discovery requires overlapping signals to resolve sanctioned apps, hidden purchases, dormant apps, and untracked usage. That is an identity governance architecture problem as much as a tooling problem.
Practical implication: design SaaS discovery as a multi-signal control plane, not as a single-source lookup.
How SaaS discovery feeds identity governance
Discovery is the prerequisite for entitlement review, application ownership, access certification, and offboarding. If the inventory is incomplete, reviews are biased toward known apps and miss shadow estates entirely. That means access decisions are made against stale assumptions about business need, license scope, and who has administrative access. In governance terms, discovery is upstream of recertification and downstream remediation. If the app is invisible, its access paths are effectively unmanaged, regardless of how strong the downstream policy appears.
Practical implication: connect discovery outputs directly to joiner-mover-leaver, access review, and dormant-app remediation workflows.
NHI Mgmt Group analysis
SaaS shadow IT is now an identity governance problem disguised as discovery. The article is about more than missing app inventory. Once users can self-adopt SaaS outside central procurement, the programme loses sight of who created the access path, who approved it, and who is accountable for offboarding it. That turns discovery into an identity control issue, not just an IT asset-management issue.
Single-source visibility is structurally insufficient for SaaS. Surveys, SSO, CASB, ITAM, and SAM each see different slices of the estate, so none can serve as the governing record on their own. The important shift for practitioners is to stop asking which tool is best and start asking how overlapping evidence is reconciled into one authoritative inventory for governance decisions.
Shadow IT discovery should be treated as a lifecycle control, not a point-in-time project. SaaS usage changes as teams experiment, pay for tools directly, or abandon apps after short projects. The governance failure is not only that apps appear outside policy, but that their access and licensing state can drift faster than periodic reviews can catch it. Practitioners need a continuous discovery model because static inventory processes cannot keep pace.
Identity programmes need a named concept for the visibility gap: shadow application drift. This is the state where sanctioned and unsanctioned SaaS move in and out of the environment faster than access reviews, asset registers, or license reconciliations can absorb. That drift weakens certification, offboarding, and entitlement governance at the same time, so the practitioner conclusion is to govern the discovery pipeline as part of identity architecture.
For IAM teams, the real question is whether discovery evidence is actionable enough to drive control enforcement. Knowing that an app exists is only the first step. The programme has to determine ownership, access scope, business purpose, and whether the app is attached to an identity path that should be certified, reduced, or removed. Without that chain, discovery produces noise rather than governance.
What this signals
Shadow application drift: SaaS usage can appear, expand, and disappear faster than periodic inventory processes can certify it. That means discovery has to be continuous and reconciled across identity, finance, and application evidence if governance is expected to keep up.
For IAM and IGA programmes, the practical boundary is no longer the application catalogue alone. Teams need a governance record that shows who uses each SaaS app, how it was adopted, and whether it still belongs in the environment, otherwise certification and offboarding remain incomplete.
For practitioners
- Build a multi-signal SaaS inventory Combine identity provider logs, finance and expense records, direct app integrations, and directory data so no single source defines the application estate.
- Reconcile shadow apps into governance workflows Route discovered SaaS into access review, application ownership assignment, and dormant app cleanup so discovery leads to action, not just reporting.
- Separate sanctioned from self-adopted SaaS Tag applications by procurement path, identity source, and business owner so unsanctioned adoption is visible during certification and offboarding.
- Treat SSO coverage as partial evidence Use SSO as one telemetry source, but do not assume federated login coverage equals complete SaaS visibility or complete access governance.
- Continuously reconcile dormant usage Compare app-level usage, license tier data, and access logs to find tools that were adopted for short projects and left unmanaged.
Key takeaways
- SaaS shadow IT is fundamentally a governance visibility problem because users can adopt cloud apps faster than traditional inventory processes can track them.
- No single discovery source is enough, since SSO, CASB, ITAM, SAM, finance data, and direct integrations each expose only part of the SaaS estate.
- If discovery does not feed ownership, access review, and offboarding, the organisation gains data without gaining control.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Shadow SaaS often arrives through unmanaged third-party app connections and unsanctioned access paths. |
| NHI-05 — Overprivileged NHI | Incomplete discovery hides overbroad access in shadow apps and the accounts using them. | |
| Recommendation — Map unsanctioned SaaS access paths to NHI-03 and review third-party app onboarding before certification. Use NHI-05 to trim excessive SaaS permissions once apps are discovered and owned. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Discovery gaps undermine the inventory needed to govern entitlements across SaaS tools. |
| Recommendation — Apply PR.AA-05 to keep SaaS entitlements tied to an authoritative access inventory. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shadow SaaS creates unmanaged accounts and weakens lifecycle control over app access. |
| Recommendation — Use CIS-5 to reconcile unmanaged SaaS accounts into account and access governance. | ||
| NIST Zero Trust (SP 800-207) | Principle of continuous verification — Continuous verification | Shadow IT discovery depends on ongoing evidence, not one-time inventory assumptions. |
| Recommendation — Adopt continuous verification so SaaS discovery and entitlement state stay current. | ||
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 Discovery: SaaS discovery is the process of identifying all sanctioned and unsanctioned software-as-a-service applications in use across the organisation. It matters because cloud assurance increasingly depends on seeing where apps share data, what permissions they hold, and which identities can reach them.
- Application Inventory: An application inventory is the authoritative list of software an organisation believes it uses and governs. For identity teams, the inventory matters because every access review, ownership decision, and offboarding workflow depends on it being complete enough to reflect the real application estate.
- Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
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.
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