TL;DR: SaaS adoption is making software faster and cheaper to deploy, but Zluri argues that the resulting sprawl also creates shadow IT, duplicate apps, and governance gaps that expose security, compliance, and cost risk. The real control problem is no longer software procurement alone, but who can approve, monitor, and retire access across the expanding app estate.
At a glance
What this is: This article argues that SaaS growth is creating software sprawl, with duplicate apps, shadow IT, and unmanaged access turning procurement into an identity governance issue.
Why it matters: IAM, IGA, and PAM teams need to govern app approval, access ownership, and offboarding because the risk now sits in who can introduce, use, and retire software access.
Context
SaaS sprawl is the accumulation of duplicate, unused, and unapproved applications across a business estate. The governance gap appears when teams can add software quickly but cannot consistently prove who approved it, who owns the access, or when it should be retired.
For identity programmes, the issue is not software consumption alone. It is the loss of control over access lifecycle, application inventory, and offboarding discipline as the app estate expands faster than governance processes.
Key questions
Q: What breaks when SaaS sprawl is not in your identity catalogue?
A: Access reviews, provisioning, and offboarding all become partial controls. Teams certify and revoke access only for the applications they know about, while shadow applications remain outside governance. The result is a false sense of coverage: the workflow looks complete, but actual employee access is wider than the identity record shows.
Q: Why does SaaS sprawl create security risk as well as cost pressure?
A: SaaS sprawl increases the number of accounts, roles, permissions, and integrations that must be governed. Each additional application adds another place where access review, approval, and offboarding can fail. The result is not just wasteful spend but a larger, harder-to-audit identity surface across business systems.
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: How should security teams govern distributed SaaS without slowing the business down?
A: Use a shared operating model. Business units can keep local ownership, but security teams need inventory, approval rules for sensitive settings, and monitoring for integrations and external sharing. That keeps the organisation from turning speed into hidden access sprawl. The goal is not central approval for everything, but visible accountability for anything that changes the trust boundary.
Technical breakdown
How SaaS sprawl becomes an identity governance problem
SaaS sprawl creates a governance problem when application adoption outpaces inventory, approval, and offboarding controls. In that state, each new app introduces its own identities, entitlements, and renewal logic, often outside central oversight. The challenge is not just licensing waste. It is that access decisions become fragmented across departments, so no single team can reliably answer who owns the app, who can use it, or when access should be removed. That makes software governance behave like identity governance by another name.
Practical implication: unify app inventory with identity ownership so every SaaS app has a clear approver, owner, and retirement path.
Shadow IT and duplicate apps expand the access surface
Shadow IT is unmanaged software introduced without standard review, while duplicate apps are multiple tools serving the same business need. Both expand the access surface because each app can carry separate accounts, tokens, roles, and offboarding requirements. When teams pick tools independently, entitlement sprawl follows. The result is not only higher spend but more places where dormant access can persist after a user leaves or a project ends. That persistence creates governance debt even when the software itself looks low risk.
Practical implication: detect duplicate and unsanctioned apps early, then tie each one to a lifecycle process for approval and removal.
Why SaaS governance now depends on lifecycle control
Once software becomes easy to buy and easy to connect, the real control point moves to lifecycle management. Joiner, mover, leaver discipline must extend to SaaS so onboarding grants only approved access, movers do not accumulate duplicate entitlements, and leavers lose access across all apps, not just core systems. This is why software governance now intersects directly with IGA and NHI practice. If the lifecycle is weak, shadow IT becomes an access problem, not merely a procurement problem.
Practical implication: extend JML controls beyond core directories and into every SaaS application that stores business data.
Threat narrative
Attacker objective: The objective is not a single breach but sustained access and governance blind spots across an expanding SaaS estate that can be abused or left exposed.
- Entry happens when business users or teams adopt SaaS tools outside central review, often through free trials, freemium plans, or local purchasing decisions.
- Credential and access sprawl follow as each tool introduces separate accounts, permissions, and sometimes unmanaged third-party access paths.
- Impact appears when redundant, unused, or shadow applications remain active without clear ownership, increasing security, compliance, and cost 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
SaaS sprawl is no longer just a procurement issue. It is an identity governance issue because every unmanaged app introduces its own access lifecycle, ownership gap, and offboarding risk. The article’s central claim is that software can now be acquired faster than governance can track it. That changes the control model from budget oversight to identity assurance, where approval and retirement matter as much as purchase.
Shadow IT is the visible symptom, but duplicate apps are the structural problem. Duplicate tooling fragments entitlement control, because each app may carry its own roles, tokens, and admin paths. The result is a wider identity surface that IAM and IGA teams must govern as a portfolio rather than as isolated applications.
Software governance increasingly depends on lifecycle discipline across SaaS, not just directory control. Joiner, mover, and leaver processes now have to follow the app estate wherever it lives, or access will outlast need. That makes offboarding and recertification the practical controls that determine whether software sprawl stays manageable.
Identity ownership drift: when no one can clearly name the approver, operator, and remover for each SaaS app, governance breaks before a breach ever occurs. This is the named concept the article exposes. The implication for practitioners is that app inventory without accountable ownership is not inventory at all, only a list of unmanaged exposure points.
From our research library:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
What this signals
Identity ownership drift: SaaS sprawl becomes dangerous when no one can answer who approves an application, who owns the access model, and who removes it at the end of its life. That governance gap is what turns convenience into exposure.
The practical test for IAM and IGA teams is whether they can treat every new SaaS request as a lifecycle event, not a one-off purchase. If approval, review, and offboarding are not tied to the app itself, shadow IT will keep expanding the control surface.
For practitioners
- Define app ownership for every SaaS tool Assign a named business owner, technical owner, and access approver to every SaaS application so approval and retirement are not ambiguous.
- Map duplicate and unsanctioned apps Create an authoritative inventory that flags duplicate tools, personal trials, and shadow IT so governance can target the highest-friction sprawl first.
- Extend leaver controls into SaaS Ensure offboarding removes user access, shared accounts, and delegated access across all business apps, not just core enterprise systems.
- Review app approval thresholds Set criteria for when a new SaaS request needs security review, legal review, or identity governance review before it enters the environment.
Key takeaways
- SaaS sprawl changes the problem from software buying into software governance, because every application adds an identity and access lifecycle.
- Duplicate apps, shadow IT, and unmanaged onboarding create exposure even when the software itself is low risk.
- The most effective control is to tie app approval and offboarding to accountable ownership across the SaaS estate.
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 | Unmanaged SaaS leaves access behind when apps or users are no longer needed. |
| NHI-05 — Overprivileged NHI | SaaS sprawl often creates excessive app access and duplicate entitlements. | |
| Recommendation — Map SaaS offboarding gaps to NHI-01 and remove stale app access paths on exit. Review SaaS entitlements for overprivilege and reduce access to the minimum business need. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on governing who can approve and retain SaaS access. |
| Recommendation — Apply PR.AA-05 to keep SaaS permissions aligned with explicit business authorisation. | ||
| CIS Controls v8 | CIS-5 — Account Management | SaaS sprawl creates multiple accounts that need consistent lifecycle control. |
| Recommendation — Use CIS-5 to inventory SaaS accounts and remove orphaned access promptly. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Duplicate apps and shadow IT increase entitlement scope beyond necessity. |
| Recommendation — Enforce AC-6 so SaaS access stays limited to the privileges each role actually needs. | ||
Key terms
- SaaS Sprawl: SaaS sprawl is the uncontrolled spread of software-as-a-service applications across teams and business units. It creates fragmented ownership, duplicated functionality, and weak visibility into who can access what. For IAM and NHI teams, the main risk is not only cost but persistent entitlements that outlive business need.
- 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.
- Identity Ownership: Identity ownership is the assignment of a responsible human for each identity's purpose, access, review, and retirement. For non-human identities, ownership must be explicit because the creator is not always the right person to approve ongoing access. Without ownership, review and revocation become inconsistent and slow.
- Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
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