Shadow SaaS and identity sprawl are outpacing ITAM controls

At a glance

What this is: This article explains how shadow SaaS and identity sprawl outgrew manual ITAM and spreadsheet-based controls, leaving organisations unable to see who approved, bought, or accessed many applications.

Why it matters: For IAM, NHI, and governance teams, the issue is that access, procurement, and inventory data now sit in separate processes, so unmanaged SaaS expands the identity surface faster than reviews can catch up.

Context

Shadow SaaS is the use of cloud applications that enter the business outside approved procurement and governance processes. In this article, that sprawl is presented as an identity and access problem as much as a software asset problem, because untracked apps bring untracked accounts, entitlements, and data flows with them.

The central governance gap is fragmentation: procurement may see spend, finance may see expenses, security may see risk, and ITAM may see only partial inventory. When those views do not reconcile, organisations cannot reliably answer who approved the application, who is using it, or what business data it touches.

Key questions

Q: What breaks when SaaS purchases bypass central procurement and IT approval?

A: When SaaS purchases bypass central approval, organisations lose the link between buying authority, asset inventory, and access ownership. That makes shadow IT harder to detect, renewals harder to justify, and offboarding harder to complete. The immediate failure is not just overspend. It is the absence of a governed lifecycle for the application and its identities.

Q: Why do shadow SaaS apps create IAM risk?

A: Shadow SaaS creates IAM risk because access can exist outside approved onboarding, review, and offboarding processes. When business teams adopt apps without central visibility, security teams lose the ability to enforce least privilege, inspect entitlements, or revoke access consistently across the SaaS estate.

Q: What signals show that SaaS governance is not working?

A: Look for delayed offboarding, repeated manual exports, inconsistent access review responses, and inactive accounts that still carry paid licenses. Those signals indicate that entitlement ownership and usage data are not reconciled often enough to support reliable governance.

Q: Should organisations manage shadow SaaS through ITAM, IAM, or both?

A: They need both, but not as separate workstreams. ITAM tracks what exists and what it costs, while IAM determines who can use it, administer it, and revoke it. If those disciplines do not share the same approval and offboarding process, unsanctioned SaaS will continue to slip through governance gaps.

Technical breakdown

Why spreadsheet-based SaaS management fails at scale

Spreadsheet-led ITAM can record assets, but it does not reliably model SaaS lifecycle events such as self-service purchase, delegated admin access, or informal renewals through expense claims. The result is control drift: the record of an application and the reality of its users, owners, and data paths diverge. Once that happens, governance becomes retrospective rather than preventive, and teams spend time reconciling fragmented evidence instead of controlling the estate.

Practical implication: Treat spreadsheets as a stopgap, not a control plane, and move inventory, ownership, and approval evidence into a governed system of record.

How employee-led SaaS adoption creates identity sprawl

Shadow SaaS is not only about software count. Each unsanctioned app can create its own authentication pathway, personal account, shared workspace, or privileged admin role, which expands the identity surface beyond what central IAM can see. That is why unmanaged SaaS becomes an access governance problem: the organisation may have no authoritative view of the identities attached to the application, especially when purchase, onboarding, and offboarding happen outside IT.

Practical implication: Map SaaS discovery to identity inventory so every application has an owner, an access path, and a removal trigger.

Why procurement, finance, and security need a shared approval model

The article shows that effective SaaS governance depends on correlating procurement, finance, and security signals rather than treating them as separate functions. Procurement identifies what was approved, finance exposes what was paid for, and security assesses whether the app and its identities fit policy. When those signals are not joined, organisations can neither block unsanctioned tools early nor prove that approved tools remain governed throughout their life cycle.

Practical implication: Build a single approval and review workflow that joins spend, risk, and identity ownership before software reaches production use.

Threat narrative

Attacker objective: The practical objective is not always a classic intrusion but uncontrolled access to business data through unmanaged applications and identities.

1. Entry occurs when an employee purchases or subscribes to a SaaS application outside approved channels, often using a corporate card or expense claim.
2. Credential and account creation follow as the app introduces a new login, admin console, or delegated access path that central IT may never inventory.
3. Impact occurs when the organisation cannot see who uses the app, what data it holds, or how it interacts with other systems, leaving governance and security blind to exposure.

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 SaaS is an identity governance problem before it is a software asset problem. The article's core pattern is that application sprawl becomes access sprawl the moment users can buy tools outside formal approval. That means the control failure is not simply missing inventory, but missing ownership of the identities and permissions created by each unsanctioned app. Practitioners should treat SaaS discovery as a governance issue, not a procurement clean-up exercise.

Manual ITAM cannot keep pace with employee-led SaaS adoption. Excel can record known assets, but it cannot continuously reconcile purchases, expenses, user accounts, and admin entitlements across a fast-moving SaaS estate. The governance assumption that applications can be reviewed after the fact no longer holds when business users can provision services in minutes. The implication is that identity visibility has to be continuous, not periodic.

Shadow SaaS creates a governed-spend gap and a governed-access gap at the same time. A team may know money left the business, yet still not know which identities now control the app or what data the service can reach. That dual blind spot is why procurement, finance, and security need a shared control model. Practitioners should redesign approval workflows so access review begins at purchase, not after deployment.

Identity surface management is the right concept for this problem. The article shows that SaaS growth cannot be managed by counting licences alone, because each application introduces its own people, tokens, and admin boundaries. The useful unit is the full identity surface of the SaaS estate, including sanctioned and unsanctioned tools. Practitioners should measure governance coverage by how much of that surface is actually owned, reviewed, and removable.

Shadow SaaS exposes the limits of traditional ITAM maturity language. Mature asset management is necessary, but it is not sufficient when software selection is decentralised and identity is embedded in every subscription. The field needs to stop treating SaaS as an asset-only category and recognise it as a distributed identity and access layer. Practitioners should align SaaS governance to identity lifecycle controls rather than isolated asset registers.

What this signals

Identity surface management is becoming the right lens for SaaS sprawl. Teams can no longer treat every application as a simple asset record because each one can create its own admin boundary, access path, and offboarding obligation. Governance needs to follow the identity surface, not just the software catalogue.

The practical shift is from periodic inventory cleanup to continuous discovery tied to approvals and revocation. When purchase channels, expense data, and access governance are not unified, shadow SaaS keeps reappearing faster than spreadsheets can close the gap.

For practitioners

• Correlate procurement, finance, and security records Join approved purchase data, expense claims, and security review results so unsanctioned SaaS can be identified before it becomes a blind spot.
• Build continuous SaaS discovery into the governance workflow Use discovery sources that expose new applications, owners, and access paths instead of relying on periodic spreadsheet reconciliations.
• Assign an owner to every SaaS application Require each app to have a business owner, a technical owner, and a removal trigger so offboarding is possible when the service is no longer sanctioned.
• Review SaaS admin and delegated access separately Check who can administer the service, who can consent to integrations, and who can access data, because those roles often diverge in shadow deployments.
• Tie SaaS offboarding to identity lifecycle events Remove access when a tool is retired or when the business case ends, and make sure the account closure path is part of the application record.

Key takeaways

• Shadow SaaS becomes a governance failure when unsanctioned applications create identities and access paths that ITAM cannot see or revoke.
• The article shows that organisations often know about the spend before they know about the app, which leaves procurement, finance, and security working from different records.
• The control gap closes when application ownership, approval evidence, and identity offboarding are managed as one lifecycle rather than three disconnected processes.

Key terms

• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
• Identity Surface: The identity surface is the full set of credentials, tokens, tool permissions, and delegated identities an AI agent can use during execution. It matters because agents often do not operate through a single account, and partial visibility into that surface creates false confidence about control coverage.
• SaaS offboarding: The process of removing a departing user from software access while also closing the related account, subscription, and data-handling obligations. In mature programmes, it includes license recovery, file transfer, inbox ownership changes, and evidence that the app lifecycle has ended cleanly.
• Governed Purchase Path: A governed purchase path is the approved route through which business software is requested, reviewed, and sanctioned before use. It matters because it creates the first control point for ownership, risk review, and identity assignment, especially when employees can otherwise buy tools directly.

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.