SaaS sprawl exposes the gaps in enterprise identity governance

At a glance

What this is: This is an enterprise SaaS management analysis showing that manual tracking and weak governance let app sprawl, compliance risk, and wasted spend accumulate.

Why it matters: It matters because SaaS sprawl is now an identity and access problem as much as a procurement problem, affecting onboarding, offboarding, access review, and control consistency across human and non-human programmes.

By the numbers:

• Only 20% on the whole use SaaS management platforms.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Zluri's analysis of enterprise SaaS management and sprawl

Context

SaaS sprawl is what happens when application adoption outpaces governance, leaving IT teams to track who bought what, who uses it, and who should lose access when roles change. In identity terms, the problem is not just software count. It is whether joiner-mover-leaver processes, access reviews, and compliance checks still work when the application estate keeps expanding faster than the control model.

The article argues that spreadsheets cannot keep up with enterprise SaaS management because they do not update themselves, do not measure usage, and do not surface overlapping functionality. That gap matters for IAM, NHI governance, and lifecycle control because every new SaaS app creates more identities, more integrations, and more offboarding risk.

For a practical reference point on the governance side of this problem, see the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide. Both are relevant because SaaS management failures often show up first as identity lifecycle failures rather than as pure procurement issues.

Key questions

Q: How should organisations govern SaaS sprawl across identity and access teams?

A: Organisations should govern SaaS sprawl as an identity lifecycle issue, not as a simple procurement list. That means assigning application ownership, tying access to onboarding and offboarding, and reviewing whether each app still has a business purpose. Without those controls, access and spend both drift out of policy.

Q: Why do spreadsheets fail as a control model for enterprise SaaS management?

A: Spreadsheets fail because they are manual, static, and dependent on people remembering to update them. Enterprise SaaS estates change too quickly for that approach to stay accurate, which leaves stale ownership, missed offboarding, and weak evidence for compliance reviews and access decisions.

Q: How can security teams tell whether a SaaS application is still worth keeping?

A: Security teams should look at actual usage, owner accountability, and integration depth rather than license count alone. If an app has little use, duplicates another platform, or still carries active integrations without a clear business reason, it is a candidate for renewal challenge or retirement.

Q: Who should be accountable for SaaS governance when business teams buy applications directly?

A: Accountability should sit with both the business owner and the identity or IT governance function. Business teams can justify need, but identity teams must ensure access is visible, reviewed, and removed when the need ends. Shared accountability prevents shadow SaaS from becoming permanent.

Technical breakdown

Why spreadsheet-based SaaS governance breaks at enterprise scale

Spreadsheets depend on manual collection, manual updates, and a static snapshot of the environment. In enterprise SaaS estates, that model fails because application procurement, role changes, and offboarding happen continuously. The result is stale entitlement data, missed reviews, and no reliable way to tie access to actual business use. A spreadsheet can record that an app exists, but it cannot prove whether the app is still needed, whether the license is active, or whether the access path is still approved. Practical implication: replace spreadsheet tracking with an authoritative system of record for SaaS access and ownership.

Practical implication: replace spreadsheet tracking with an authoritative system of record for SaaS access and ownership.

SaaS governance depends on lifecycle control, not just procurement control

The article correctly shifts attention from buying software to governing it across onboarding, offboarding, and compliance. That is the lifecycle problem: access granted at procurement time often outlives the business need that justified it. In practice, SaaS governance intersects with IAM because each application introduces users, admin roles, API connections, and integrations that must be removed or recertified when the business context changes. Without lifecycle discipline, SaaS estates accumulate dormant apps, stale access, and duplicated functionality. Practical implication: treat SaaS onboarding and offboarding as identity lifecycle events, not as one-time IT admin tasks.

Practical implication: treat SaaS onboarding and offboarding as identity lifecycle events, not as one-time IT admin tasks.

Why SaaS visibility must include usage, integrations, and overlapping functionality

The article highlights a common blind spot: knowing that an application exists is not enough. Governance also needs feature-level usage, department ownership, and integration mapping so teams can see whether the app is delivering value or silently duplicating another service. That is especially important where SaaS tools connect to SSO, directory services, or downstream applications, because unused or redundant apps still represent identity exposure. If the business cannot see how software is used, it cannot rationally decide what to retire, consolidate, or review. Practical implication: build SaaS visibility around usage, ownership, and integration depth, not just license counts.

Practical implication: build SaaS visibility around usage, ownership, and integration depth, not just license counts.

NHI Mgmt Group analysis

SaaS sprawl is an identity governance problem before it is a cost problem. The article frames SaaS management as a budgeting and tooling issue, but the deeper failure is lifecycle visibility. When applications are added faster than ownership, offboarding, and access review can be enforced, identities accumulate across too many systems for governance to remain reliable. Practitioners should read SaaS sprawl as control erosion, not just software growth.

Spreadsheet governance was designed for static inventories, not living access estates. That assumption fails when the application estate changes continuously through procurement, shadow adoption, and role churn. The implication is that enterprise SaaS governance must move from record-keeping to active control, because the business risk sits in stale access and unreviewed integrations, not in the spreadsheet itself.

Feature-level SaaS visibility is now an access decision input, not a nice-to-have reporting layer. Overlapping functionality, unused modules, and hidden integrations all affect whether an app should remain in the stack. If teams cannot see actual consumption, they cannot make defensible decisions about renewal, deprovisioning, or control placement. Practitioners should treat usage intelligence as part of governance evidence.

Identity lifecycle discipline is the only durable answer to SaaS accumulation. Onboarding creates the access graph, offboarding should collapse it, and recertification should prove it still matches business need. That applies equally to human access, service accounts, and application integrations tied to SaaS platforms. The practical conclusion is that SaaS governance should be managed as part of the broader identity programme, not as a separate spreadsheet exercise.

Named concept: SaaS access drift. This is the condition where access, ownership, and business need decouple as SaaS adoption expands. It appears when the organisation can no longer say who owns the application, who still uses it, and who should remove it. Practitioners should treat SaaS access drift as a signal that identity governance has lost operational reach.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% on the whole use SaaS management platforms, which shows how much enterprise governance still depends on manual tracking and incomplete visibility.
• For a broader control baseline, read NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding fit into identity governance.

What this signals

SaaS access drift: as application estates expand, ownership, usage, and deprovisioning increasingly separate from one another, which creates an identity governance problem that spreadsheets cannot absorb. The practical signal is that organisations need a control plane for SaaS lifecycle events, not just a catalogue of applications.

The security programme implication is straightforward. If the business cannot tell which SaaS tools are active, redundant, or still integrated to directories and SSO, access reviews will remain partial and offboarding will remain incomplete. That is why lifecycle discipline, not software count, becomes the governing metric for control effectiveness.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations such as code and config files, per the Ultimate Guide to NHIs, identity teams should expect SaaS sprawl and secret sprawl to reinforce each other unless ownership and offboarding are brought under the same operating model.

For practitioners

• Replace manual SaaS inventories with an authoritative system of record Use a managed platform or equivalent control process to track application ownership, usage, and access changes automatically. The goal is to eliminate stale spreadsheet data as the source of truth for access and renewals.
• Tie SaaS offboarding to identity lifecycle events Make application removal, role removal, and access revocation part of the same offboarding workflow so dormant SaaS accounts do not survive employee or team changes. Include admin accounts, integrations, and shared workspaces in the same process.
• Review overlapping SaaS functionality before renewals Map duplicate features across applications before contracts renew so procurement decisions reflect real usage rather than historical purchases. This reduces redundant access paths and helps identify applications that no longer justify their identity footprint.
• Track integrations as part of SaaS governance Record which SaaS apps are connected to SSO, directory services, and other downstream tools, then review those links regularly. Hidden integrations often preserve access even after the business thinks an app has been retired.

Key takeaways

• Enterprise SaaS sprawl is really a governance and lifecycle problem, because access, ownership, and usage drift apart as application counts rise.
• Spreadsheet-based tracking cannot keep pace with enterprise SaaS estates, leaving compliance, offboarding, and renewal decisions exposed to stale data.
• The durable fix is to manage SaaS as part of the broader identity programme, with lifecycle ownership, usage intelligence, and integration review in the same control model.

Key terms

• SaaS Sprawl: SaaS sprawl is the uncontrolled growth of software-as-a-service applications across an enterprise. It becomes an identity problem when ownership, access, and offboarding lag behind adoption, leaving the organisation unable to prove who should still have access or why an application remains active.
• Identity Lifecycle Management: Identity lifecycle management is the set of processes used to create, modify, review, and remove access as business needs change. For SaaS estates, it must cover not only people but also application accounts, integrations, and other access paths that outlive their original purpose.
• SaaS Access Drift: SaaS access drift is the gradual separation of granted access from current business need. It happens when apps stay active after their owners change, roles evolve, or usage drops, making access reviews less reliable and deprovisioning harder to complete accurately.

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 programme maturity, it is worth exploring.

This post draws on content published by Zluri: SaaS management in the enterprise. Read the original.