SaaS sprawl shows why identity governance must start earlier

At a glance

What this is: This is an identity-first analysis of SaaS sprawl and its security, compliance, and cost impact across enterprise SaaS estates.

Why it matters: It matters because unmanaged SaaS adoption creates fragmented access paths that cut across human IAM, NHI governance, and lifecycle controls that security teams rely on to contain privilege creep.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Linx Security's analysis of SaaS sprawl and identity governance

Context

SaaS sprawl is what happens when departments buy and use cloud applications without a shared identity governance model. The result is not just application duplication, but fragmented entitlements, inconsistent offboarding, and a growing gap between who should have access and who actually does.

For IAM and governance teams, the lesson is familiar even when the technology changes: access control weakens when provisioning, review, and revocation are handled tool by tool instead of as a lifecycle. That makes SaaS sprawl a governance problem first and a technology problem second.

Key questions

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

A: Start with a central intake process that ties procurement, approval, and identity creation together. That lets teams approve useful SaaS quickly while preventing shadow subscriptions, unmanaged admins, and duplicate tools. The key is not blocking adoption. It is making every new app visible, reviewable, and reversible from the moment it is introduced.

Q: Why does SaaS sprawl create so much IAM risk?

A: Because each new application creates another access model, another set of roles, and another offboarding path. Over time, those differences produce privilege creep, stale accounts, and inconsistent policy enforcement. The risk is not just volume. It is the loss of a shared control plane for deciding who should retain access.

Q: What breaks when access reviews are done app by app?

A: Teams lose the ability to see accumulated privilege across the estate. A user may look reasonable in one system and excessive in three others, especially when shared workspaces and delegated admin rights are involved. App-by-app reviews hide the combined exposure, so they do not provide a reliable governance answer.

Q: Who should own SaaS offboarding when users change roles or leave?

A: IAM and security should define the process, but business owners need to confirm that access removal is complete. Offboarding must include standard roles, privileged access, integrations, and any hidden accounts attached to the SaaS app. If those elements are not covered, the identity remains active even after the person has moved on.

Technical breakdown

How SaaS sprawl turns into permission sprawl

Each SaaS application brings its own users, roles, sharing settings, and admin model. When those systems are adopted independently, identity state becomes distributed across many control planes, which makes it difficult to see who has access, why that access exists, and whether it still matches the job role. Permission sprawl emerges when access accumulates faster than review or revocation can keep pace. Practical implication: map SaaS entitlements back to a central identity source before access drift becomes normalised.

Practical implication: map SaaS entitlements back to a central identity source before access drift becomes normalised.

Why centralized IAM is the control plane for SaaS governance

Centralised IAM creates a single policy layer for authentication, authorisation, and lifecycle actions across many SaaS tools. It does not remove the need for each application to enforce its own controls, but it gives security teams a way to standardise who can request access, how entitlements are approved, and when accounts should be removed. Without that control plane, every new app becomes a new governance exception. Practical implication: enforce consistent joiner-mover-leaver logic across SaaS subscriptions instead of treating each app as a separate island.

Practical implication: enforce consistent joiner-mover-leaver logic across SaaS subscriptions instead of treating each app as a separate island.

Why SaaS audits need identity evidence, not just application inventories

A simple inventory of installed SaaS tools does not tell you whether access is appropriate. Identity-focused audits need to answer three questions: who can reach the app, which privileges they hold, and whether dormant accounts or redundant apps still exist. That makes entitlement review and deprovisioning the real audit work, not the spreadsheet of licences. Practical implication: pair application discovery with access review evidence so procurement, security, and compliance see the same risk picture.

Practical implication: pair application discovery with access review evidence so procurement, security, and compliance see the same risk picture.

Threat narrative

Attacker objective: The attacker objective is to exploit fragmented SaaS identity governance to reach data and systems through accounts and permissions that were never centrally controlled.

1. Entry occurs through unmanaged SaaS adoption, where departments or employees create new cloud app relationships outside central oversight.
2. Escalation follows when permissions accumulate across overlapping apps and offboarding gaps leave dormant or excessive access in place.
3. Impact is broader attack surface, harder compliance evidence, and a higher chance of unauthorized access to sensitive data and systems.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

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 an identity governance failure before it is a software problem. The common assumption is that application ownership and access review will stay aligned as tools proliferate. In practice, the governance model fractures first, because each department creates its own access logic, offboarding rhythm, and entitlement exceptions. The implication is that SaaS control has to be managed as a lifecycle discipline, not a shadow inventory exercise.

Permission sprawl is the SaaS equivalent of privilege creep in NHI estates. Once access is distributed across dozens of apps, no single team can reliably explain why a user still has a role, shared drive, or admin permission. That maps directly to OWASP-NHI and NIST CSF access governance concerns, even when the subject is human users rather than service accounts. Practitioners should treat repeated entitlement drift as a governance signal, not an isolated admin issue.

Identity-based procurement controls matter because they define the first review point. If a new SaaS app can be adopted before security and IAM see it, the organisation has already accepted unmanaged identity risk. That is why procurement, access approval, and deprovisioning need to be linked from the start. The practical conclusion is simple: the earlier identity enters the buying process, the less sprawl becomes an operating model.

Identity-based access reviews are the only scalable way to separate useful SaaS from redundant SaaS. Licensing rationalisation alone misses the governance problem, because the real risk sits in stale roles, forgotten admins, and overlapping access rights. The field should read this as a lifecycle issue across human IAM and adjacent NHI controls, especially where SaaS platforms also host API tokens, service integrations, and delegated access. Practitioners should make entitlement evidence the basis of rationalisation decisions.

Autonomous discovery and review will increasingly be needed, but they do not replace governance intent. As SaaS estates and connected identities grow, manual review cycles become too slow to keep pace with access drift. That does not change the governance premise that access must be explainable and revocable. It changes the operating model around it. The implication is that automation should support governance decisions, not become the governance decision itself.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to NHI Mgmt Group research.
• For the governance model behind these risks, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls.

What this signals

SaaS sprawl will increasingly be judged by identity evidence, not application count. Security teams should expect procurement, access review, and offboarding to be assessed as one continuous control rather than three separate processes. The practical signal is whether every SaaS app has a clear owner, a defined approval path, and a revocation mechanism that can be tested.

Permission drift across SaaS is becoming a lifecycle problem that cuts across human and non-human identity. Many SaaS platforms now host API tokens, service integrations, and delegated admin roles alongside user accounts, so one review cycle often has to cover all three. That means teams need a control model that can explain access across human IAM and NHI governance together.

Only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for every identity programme that still relies on fragmented inventories. When the same organisation cannot see service identities cleanly, it is unlikely to have reliable visibility into SaaS entitlements, shared access, or delegated admin sprawl. The next step is to align discovery, lifecycle, and review around one identity record.

For practitioners

• Centralise SaaS discovery and entitlement mapping Build a live inventory that ties every SaaS app to its owning department, authentication method, and active entitlement set. Use that inventory to identify duplicate tools, orphaned admins, and apps that sit outside procurement review.
• Connect procurement to identity approval Require security and IAM approval before a new SaaS subscription can be fully provisioned, and make the approval record part of the app's identity history. This closes the gap where employees can create access before governance sees the tool.
• Run access reviews on SaaS roles, not just users Review whether roles, shared workspaces, and delegated admin rights still match current job functions. Prioritise apps with overlapping functionality and the highest concentration of privileged access.
• Link deprovisioning to role change events Trigger removal of SaaS access when employees move teams or leave, and verify that privileged roles, integrations, and backups are included in the offboarding step.

Key takeaways

• SaaS sprawl is fundamentally a governance and identity problem, because unmanaged adoption creates fragmented access, stale entitlements, and inconsistent offboarding.
• The evidence points to a familiar failure pattern: once access is handled app by app, privilege creep and compliance gaps become structural rather than exceptional.
• Teams should connect procurement, entitlement review, and deprovisioning into one lifecycle process so every SaaS app stays visible, accountable, and revocable.

Key terms

• SaaS Sprawl: SaaS sprawl is the uncontrolled growth of cloud applications adopted outside a central governance process. It usually leads to duplicate tools, fragmented access, and inconsistent offboarding, which makes identity control harder to enforce across the organisation.
• Permission Sprawl: Permission sprawl is the accumulation of unnecessary or overlapping access rights across multiple applications. It often happens when role changes, app duplication, and weak review cycles allow privileges to persist long after they are needed.
• Identity-Based Access Review: Identity-based access review is the practice of checking who has access, what level of access they have, and whether that access still matches business need. In SaaS environments, it is the most reliable way to uncover dormant accounts and excessive permissions.
• Centralised IAM: Centralised IAM is an access control model in which identity, authentication, and authorisation policies are managed from a shared control plane. For SaaS governance, it gives security teams a consistent way to approve, monitor, and revoke access across many applications.

What's in the full article

Linx Security's full post covers the operational detail this post intentionally leaves for the source:

• Step-by-step SaaS audit workflow for finding shadow applications and orphaned permissions
• Practical procurement checks that tie SaaS approval to identity governance from day one
• Identity access analytics examples for spotting dormant accounts and privilege sprawl
• Organisational committee model for aligning IT, security, and business owners on SaaS control

👉 The full Linx Security post covers audits, procurement controls, and access cleanup in more detail.

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 identity governance in your organisation, it is worth exploring.