SaaS sprawl is turning software governance into an identity problem

At a glance

What this is: This is Zluri's argument that the software revolution is accelerating SaaS adoption while turning governance into an identity and access problem.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes now have to govern a larger SaaS surface where access, offboarding, and app sprawl all intersect.

👉 Read Zluri's blog post on SaaS growth, shadow IT, and identity governance

Context

SaaS sprawl is the condition this post is really about. When software becomes easy to buy and easy to connect, the governance problem shifts from deployment to lifecycle control, especially around access, ownership, and offboarding across the application estate.

For identity teams, that means the boundary between software management and identity governance gets thinner. Shadow IT, unused licenses, duplicate apps, and unmanaged onboarding paths all create access risk that traditional software procurement controls do not contain.

For a broader view of how this problem shows up across non-human identities and lifecycle controls, see the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide.

Key questions

Q: How should security teams govern SaaS sprawl without slowing business adoption?

A: Security teams should govern SaaS sprawl by linking app approval to identity ownership, lifecycle review, and offboarding requirements. The goal is not to block adoption, but to ensure every application has a named business owner, a technical owner, and a way to remove access cleanly when it is no longer needed.

Q: Why does SaaS growth create identity governance risk?

A: SaaS growth creates identity governance risk because every new application adds another access boundary, another admin path, and another set of credentials to track. If those paths are not governed, access persists after business need changes, which increases compliance exposure and the chance of forgotten privileges.

Q: What do teams get wrong about shadow IT in SaaS environments?

A: Teams often treat shadow IT as a procurement issue, but it is really a governance issue. The hidden risk is not just the tool itself, but the unmanaged access, integrations, and offboarding gaps that follow it. Discovery has to lead to lifecycle control, not just a cleanup exercise.

Q: Who should own SaaS access review and application retirement?

A: Ownership should sit with both business and technical stakeholders. Business owners decide whether the app still has value, while technical owners ensure users, admin accounts, service accounts, and tokens are removed. Without dual ownership, applications linger and access outlives the need that justified it.

Technical breakdown

Why SaaS growth turns access governance into an identity problem

SaaS changes the control point from infrastructure to entitlement. Instead of managing a small set of centrally deployed applications, organisations now manage many independently procured services with their own admins, OAuth grants, delegated access paths, and offboarding dependencies. That creates a governance stack where access review, provisioning, and deprovisioning matter as much as procurement approval. The core issue is not simply application count. It is that each application becomes another identity boundary with its own lifecycle, audit trail, and recovery path, which makes visibility and ownership the decisive variables.

Practical implication: map SaaS ownership and access paths into your identity governance processes before app sprawl makes review cycles unmanageable.

Shadow IT and duplicate apps create hidden privilege surfaces

Shadow IT is not only an inventory problem. Every unsanctioned or duplicate app creates a separate identity relationship, often with weak monitoring, inconsistent authentication standards, and incomplete deprovisioning when staff leave or roles change. The risk grows when teams adopt tools for convenience and later forget to retire them, because access persists even after business need disappears. In governance terms, the hidden exposure is lifecycle drift: credentials, integrations, and approvals outlive the purpose that justified them. That is why SaaS sprawl should be analysed as a privilege surface, not just a spend issue.

Practical implication: treat unmanaged SaaS as privileged access debt and fold discovery into recertification and offboarding workflows.

Why SaaS management now overlaps with NHI governance

SaaS environments are full of non-human identities, including service accounts, API keys, OAuth tokens, and automation links between systems. When software adoption accelerates, those machine identities multiply alongside human users, which means governance has to cover both people and the credentials that connect the apps. This is where the control model widens: application approvals alone do not answer who can call what, on whose behalf, and for how long. The right lens is lifecycle governance across human and non-human access paths, with clear ownership and termination logic for each.

Practical implication: extend identity governance to machine credentials and third-party app connections, not just employee access.

NHI Mgmt Group analysis

SaaS sprawl is a lifecycle governance problem disguised as procurement convenience. The post describes a market where buying software is easy, but retiring it is not. That imbalance creates lingering access, duplicate entitlements, and weak ownership, all of which sit squarely inside identity governance rather than application management. Practitioners should treat every new SaaS approval as a lifecycle obligation, not a one-time purchase decision.

Shadow IT becomes dangerous when identity controls do not follow the application. The article correctly points to financial, compliance, and security risk, but the deeper issue is that every unmanaged app introduces an unmanaged identity boundary. That boundary can include admin roles, delegated tokens, and forgotten integrations that never enter standard review processes. The practical conclusion is that discovery without governance is incomplete.

Hidden app access debt: the real problem is not the number of tools, but the number of identity relationships that outlive business need. This is the pattern identity teams need to name, because it captures both human and non-human access persistence. In a SaaS-heavy environment, the governance model must account for ownership, review, and offboarding across the full app estate. Practitioners should measure how much access remains after applications fall out of active use.

The software revolution validates identity lifecycle management as a core control plane. As software becomes cheaper and more distributed, governance has to shift from periodic approval to continuous inventory, entitlement tracking, and offboarding discipline. That is true for employee access, service accounts, and API-driven connections alike. The implication is straightforward: identity programmes that still stop at login controls are already behind the operational reality of SaaS sprawl.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from the same report shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs.
• That visibility gap points directly to lifecycle and discovery gaps, which is why practitioners should also review the NHI Lifecycle Management Guide.

What this signals

Hidden app access debt: SaaS sprawl should now be read as an identity inventory problem, not a software buying problem. When organisations cannot see every app, vendor connection, and delegated grant, recertification becomes incomplete and offboarding becomes unreliable.

The operational signal to watch is whether procurement data, access data, and app discovery data converge. If those views do not align, the programme is already carrying unmanaged access paths that will not be fixed by periodic review alone.

For teams already building lifecycle controls, the next step is to connect SaaS discovery to machine identity governance. The NIST Cybersecurity Framework 2.0 remains a useful reference point for aligning identify, protect, detect, and recover functions around this broader app estate.

For practitioners

• Inventory SaaS applications by identity dependency Create a current register of sanctioned and unsanctioned apps, then map each one to business owner, admin owner, human access, and non-human connections. Use the inventory to identify duplicate tools, orphaned apps, and services with no clear offboarding path.
• Embed offboarding into app retirement workflows Require every SaaS retirement or renewal decision to include removal of user access, service accounts, API keys, and delegated tokens. Tie application closure to lifecycle checkpoints so that access does not survive after the business use case ends.
• Extend recertification beyond employee access Include SaaS admins, privileged app owners, OAuth grants, and machine credentials in access reviews. Review cadence should reflect the rate at which tools are added, duplicated, or abandoned in the environment.
• Track shadow IT as a governance signal Measure how many applications enter the environment outside approved procurement channels and how long they remain before discovery. Use that signal to prioritise controls for discovery, approval, and lifecycle enforcement rather than relying on periodic audits alone.

Key takeaways

• SaaS sprawl turns application management into an identity governance problem because access, ownership, and offboarding now span many independent tools.
• Shadow IT matters most when it creates hidden identity relationships, including admin accounts, delegated tokens, and unmanaged integrations.
• Identity programmes should extend discovery and lifecycle control to SaaS apps, machine credentials, and retirement workflows, not just employee logins.

Key terms

• SaaS Sprawl: SaaS sprawl is the uncontrolled growth of software applications across a business, often with overlapping functionality and inconsistent ownership. In identity terms, it expands the number of access boundaries, admin roles, and offboarding paths that must be governed.
• Shadow IT: Shadow IT is software or service usage that appears outside approved procurement or governance channels. It matters to identity teams because it often comes with hidden user accounts, delegated access, and credentials that never enter standard lifecycle controls.
• Identity Lifecycle Management: Identity lifecycle management is the discipline of creating, changing, reviewing, and removing access in step with business need. For SaaS environments, it must cover humans, admins, service accounts, and integrations so that access does not outlive the application or its purpose.
• OAuth Grant: An OAuth grant is a delegated permission that allows one application to act on behalf of a user or another system. In SaaS ecosystems, grants can become persistent identity links if they are not reviewed, scoped, and revoked when business use changes.

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.

This post draws on content published by Zluri: IT teams, SaaS, and the next big revolution. Read the original.