SaaS sprawl is becoming an identity governance problem

At a glance

What this is: This is a survey-backed look at how industries manage SaaS sprawl, showing that security, compliance, and visibility gaps are still driving poor control over application access.

Why it matters: It matters because SaaS sprawl is also identity sprawl, and IAM, IGA, and PAM teams need to govern both human and non-human access across a larger, less transparent application estate.

By the numbers:

• Gartner says 30 to 40% of enterprise spending goes to Shadow IT.
• 52% of these industries track the data manually through dashboards within the SaaS application itself.
• 80% of the surveyors have said they don't use any tool to track their SaaS usage.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Zluri's survey on how industries manage SaaS sprawl

Context

SaaS sprawl is the accumulation of overlapping, poorly governed business applications across an organisation. In identity terms, that means more accounts, more vendor relationships, more onboarding and offboarding events, and more opportunities for privilege creep and shadow access across SaaS estates.

Zluri’s survey shows that many organisations still rely on spreadsheets, dashboards, expense reports, and employee feedback to understand what software is actually in use. That is not just a procurement problem. It is an identity governance problem because every unmanaged application creates another place where access can persist after ownership, need, or employment changes.

For IAM and IGA teams, the challenge is not only knowing which applications exist. It is understanding who can access them, whether that access is still needed, and how third-party SaaS usage interacts with onboarding, offboarding, least privilege, and renewal controls across human and machine identities.

Key questions

Q: How should security teams govern SaaS sprawl across business units?

A: Security teams should govern SaaS sprawl by tying every application to an owner, an access method, and a lifecycle review. That means inventorying shadow apps, reconciling SSO and procurement data, and enforcing offboarding when business use ends. The goal is to control effective access, not just count subscriptions.

Q: Why do SaaS sprawl and shadow IT create IAM risk?

A: They create IAM risk because each unmanaged application introduces another identity system, another set of privileges, and another place where access can persist after need changes. Without central visibility, teams cannot reliably enforce least privilege, review entitlements, or revoke access consistently across the SaaS estate.

Q: What breaks when SaaS access is tracked only with spreadsheets and dashboards?

A: Governance breaks because those tools can describe usage but cannot enforce ownership, entitlement review, or deprovisioning. They also miss delegated admin paths, API connections, and vendor support access. The result is false confidence: leadership sees reporting, while excessive or stale access remains active.

Q: Who is accountable when SaaS access persists after offboarding?

A: Accountability should sit with the application owner, the identity team, and the business function that approved the access. If the environment includes third-party SaaS, the vendor relationship owner must also be in scope. Offboarding is only complete when all effective access has been revoked and verified.

Technical breakdown

SaaS sprawl creates hidden identity and access paths

When organisations add SaaS faster than they rationalise it, each new application creates its own authentication, authorisation, and lifecycle surface. That surface includes users, admins, API tokens, delegated connections, and vendor-managed access paths. The governance failure is not the application count itself. It is the loss of authoritative inventory, entitlement ownership, and consistent review across systems that do not share a common control plane. Once that happens, security teams cannot reliably answer which identities still have access, whether the access is justified, or whether offboarding has actually completed.

Practical implication: Map every SaaS app to an owner, an access method, and a review cadence before the next renewal cycle.

Manual SaaS tracking fails at lifecycle governance

Manual tracking through dashboards, spreadsheets, or expense reports can show spend, but it rarely proves control. Lifecycle governance needs timely signals for joiners, movers, leavers, renewals, and vendor changes, and those signals are fragmented when the estate is managed by humans alone. The result is that dormant accounts, stale privileges, and unmanaged vendor access survive longer than the business relationship that created them. In practice, the control weakness is not visibility in the abstract. It is the inability to enforce consistent onboarding and offboarding across dozens of disconnected SaaS tools.

Practical implication: Tie SaaS inventory to access reviews and deprovisioning workflows instead of treating usage reporting as a control.

Least privilege depends on SaaS-level entitlement visibility

Least privilege becomes difficult when organisations can see subscriptions but not effective entitlements. A user may have access to an application, an admin role inside it, delegated vendor support access, or a connected API token that is invisible to the procurement record. SaaS governance therefore has to distinguish between commercial ownership and actual access authority. Without that distinction, teams can overestimate control maturity while still leaving excessive access in place. This is especially important where third-party integrations and shared admin models blur who can do what inside the application.

Practical implication: Review privileged SaaS roles, delegated access, and API connections separately from license counts.

Threat narrative

Attacker objective: The practical objective is to exploit weak SaaS governance so that access persists beyond need and sensitive data remains reachable through forgotten or excessive entitlements.

1. Entry occurs when organisations adopt SaaS outside formal governance, often through shadow IT, departmental procurement, or fragmented renewals that bypass central identity controls.
2. Escalation happens when manual tracking cannot keep pace with onboarding, offboarding, and vendor changes, leaving stale accounts, shared privileges, and hidden access paths in place.
3. Impact follows as exposed SaaS accounts, redundant subscriptions, and unmanaged vendor access widen the attack surface and create data exposure, compliance drift, and avoidable cost.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SaaS sprawl is identity sprawl, not just software bloat. Once SaaS adoption outpaces governance, the real problem becomes fragmented access control across dozens of application-specific identity systems. The article’s data shows how often organisations still depend on manual tracking, which cannot reliably support entitlement review or offboarding. Practitioners should treat SaaS inventory as an identity control surface, not a procurement list.

Ephemeral SaaS ownership is the governance gap. SaaS tools change hands, teams change usage patterns, and vendors change relationships faster than many review cycles can react. That creates a recurring mismatch between who owns the application, who can access it, and who is responsible for revoking access when use ends. The implication is that access governance must follow the application lifecycle, not the finance cycle.

Least privilege in SaaS is only real when entitlement data is complete. The article shows that teams care about least privilege, visibility, and unused subscriptions, which are all signs that entitlement certainty is missing. A licence count does not tell you whether an admin role, delegated token, or support connection still exists. Practitioners should judge SaaS maturity by whether they can prove who has effective access, not by how many apps are under contract.

Manual visibility creates false confidence in SaaS control. Dashboards, surveys, and expense reports can describe spend patterns, but they do not enforce governance decisions. That gap matters because it lets stale access survive while leadership believes the environment is under control. The practitioner conclusion is that control must be embedded into the SaaS lifecycle, not inferred from reporting.

Cross-domain governance is now unavoidable. SaaS management sits at the intersection of human IAM, third-party access, and non-human identity because modern SaaS estates depend on users, admins, integrations, and tokens at the same time. That is why NIST Cybersecurity Framework 2.0 and OWASP-NHI both matter here. Teams should design one lifecycle model that covers users, vendors, and machine access together.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Use NHI Lifecycle Management Guide to connect SaaS offboarding, secret revocation, and identity lifecycle controls in one process.

What this signals

SaaS governance is converging with identity governance. As organisations accumulate more applications than they can track manually, the control problem shifts from spend management to entitlement certainty. Teams that still separate SaaS administration from IAM will keep finding stale access after the business thinks an app has been retired.

Identity programmes should expect SaaS to expose lifecycle weak points first. Onboarding, offboarding, and renewal are the moments when application ownership and effective access diverge. The practical response is to build lifecycle checks into procurement, review, and deprovisioning workflows before the next wave of SaaS adoption expands the gap.

Ephemeral application ownership is now a named governance problem. Applications move between teams, vendors, and use cases faster than many access review cycles can certify. That makes inventory accuracy and access verification the controls that decide whether SaaS sprawl stays manageable or becomes a persistent identity debt.

For practitioners

• Build a complete SaaS identity inventory Create one authoritative list of SaaS applications, business owners, access methods, admin roles, and connected integrations. Reconcile it against procurement, SSO, and expense data so shadow applications do not stay outside review cycles.
• Separate licence management from entitlement review Review who can actually do what inside each SaaS application, including privileged roles, support access, and API connections. Licence counts alone do not show whether effective access is still justified.
• Automate offboarding across SaaS renewals Link leaver processes to application ownership and renewal events so access is removed when usage ends or contracts change. Use the NHI Lifecycle Management Guide to align account revocation, ownership transfer, and review cadence.
• Treat third-party access as a governed identity path Track vendor logins, delegated support accounts, and shared admin access separately from employee access. Apply the same review standard to external access that you use for internal privileged accounts.
• Measure hidden SaaS access by control gaps Look for applications with no owner, no current review cadence, no offboarding workflow, or no inventory source. Those gaps usually reveal where privilege can outlive business need.

Key takeaways

• SaaS sprawl becomes an identity problem the moment access can no longer be tied to a single owner, lifecycle, and review process.
• The survey shows that many teams still rely on manual tracking, which can report usage but cannot reliably revoke stale or excessive access.
• Practitioners should connect SaaS inventory, entitlement review, and offboarding so software growth does not turn into hidden privilege growth.

Key terms

• SaaS sprawl: The uncontrolled growth of software-as-a-service applications across teams, departments, and vendors. It creates overlapping functionality, fragmented ownership, and uneven access controls, making it harder to know who can reach which systems and whether that access still makes business sense.
• Shadow IT: Technology, applications, or services adopted outside central governance or formal approval. In identity terms, shadow IT often creates hidden accounts, unmanaged admin privileges, and offboarding gaps because the systems were never brought into the organisation’s normal review and deprovisioning process.
• Entitlement review: The process of checking whether a user, admin, token, or vendor connection still needs the access it has. In SaaS environments, entitlement review is the only reliable way to distinguish active business use from stale or excessive access that has simply been left behind.
• SaaS lifecycle governance: The discipline of managing SaaS applications from approval through ownership change, renewal, and retirement. It ties access control to application lifecycle events so onboarding, offboarding, and privilege review happen when the business context changes, not after a problem appears.

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: SaaS Management How Different Industries Manage SaaS: A Data-Backed Study. Read the original.