SaaS sprawl is becoming an access governance problem for IAM teams

At a glance

What this is: This is an editorial analysis of SaaS sprawl and how access governance is used to regain visibility, control, and compliance across fragmented SaaS estates.

Why it matters: It matters because SaaS sprawl creates unmanaged access paths that overlap with NHI governance, especially for service accounts, tokens, and delegated SaaS integrations.

By the numbers:

• Software as a Service applications have become the backbone of productivity and innovation, growing 18% annually.
• The average company wastes over $18M a year on unused, underused, or duplicate SaaS tools.

👉 Read SafePaaS's analysis of SaaS sprawl and access governance

Context

SaaS sprawl is what happens when organisations lose track of how many applications are in use, who approved them, and what access they retain over time. For IAM and NHI practitioners, the problem is not only application proliferation. It is the accumulation of unmanaged entitlements, orphaned accounts, and inconsistent review processes across a large and shifting SaaS estate.

The article frames access governance as the control layer that restores visibility, policy enforcement, and certification discipline across SaaS tools. That basic premise is sound, but the deeper issue is that sprawl turns every SaaS integration into a governance decision about identity, privilege, and revocation. In that sense, the starting position described here is increasingly typical, not exceptional, across mid-size and large enterprises.

Key questions

Q: How should security teams govern access across SaaS sprawl?

A: Security teams should govern SaaS sprawl with one inventory, one policy model, and one review process that covers both human and non-human access. The practical goal is to connect application approval, entitlement review, and revocation to business ownership. Without that linkage, access governance becomes a manual cleanup exercise instead of a control system.

Q: Why does SaaS sprawl increase non-human identity risk?

A: SaaS sprawl increases NHI risk because every new integration can create tokens, service accounts, OAuth grants, and delegated permissions that persist outside normal review cycles. Those identities often have more reach than human users and fewer lifecycle checks. The result is wider attack surface and harder-to-audit access paths.

Q: What is the difference between access governance and privileged access management in SaaS?

A: Access governance manages the full process of requesting, reviewing, certifying, and revoking access across applications. Privileged Access Management focuses on high-risk elevated access, such as admin functions or sensitive workflows. In SaaS, the two should work together: governance sets the policy, and PAM constrains the riskiest actions.

Q: Should organisations prioritise SaaS cleanup before expanding access controls?

A: Organisations should clean up SaaS sprawl and expand access controls in parallel, but high-risk entitlements should be first in line. If the estate is full of dormant apps, duplicate licenses, and stale permissions, adding more controls later only locks in the existing mess. Start with inventory, then focus on revocation and certification.

Technical breakdown

How SaaS sprawl creates NHI governance gaps

SaaS sprawl is not just app count growth. It is a control failure in which identity records, entitlements, and audit trails become fragmented across business units and cloud services. Each new app can introduce service accounts, API tokens, delegated OAuth grants, and admin roles that are not centrally tracked. Over time, the organisation loses the ability to answer basic questions about who or what has access, for how long, and under which policy. That is an NHI problem because many of the effective actors in SaaS are non-human identities with persistent privilege and weak lifecycle governance.

Practical implication: inventory SaaS-connected non-human identities alongside applications, not after the fact.

Why access governance becomes the control plane for SaaS estates

Access governance sits above individual SaaS tools and standardises how access is requested, reviewed, certified, and revoked. In practical terms, it creates a control plane for joiner, mover, leaver, and access-review workflows across disparate systems. That matters when organisations cannot rely on each application owner to apply the same rules. For NHI governance, the same pattern should apply to service accounts and application-to-application access, because the risk is usually not one broken control but inconsistent control coverage across hundreds of entitlements.

Practical implication: unify SaaS access reviews and revocation triggers under one policy model.

Policy-based access controls and PAM in sprawling SaaS environments

Policy-based access controls define who can obtain access under what conditions, while Privileged Access Management adds stronger controls around elevated actions. In a sprawling SaaS estate, this combination helps reduce standing access, limit privileged escalation, and create clearer evidence for audit and compliance teams. The key architectural point is that controls must work across identity stores, not just inside a single platform. Without that, the organisation only shifts risk from one application to another while keeping the same access assumptions in place.

Practical implication: apply policy-based rules and privileged controls consistently across all high-risk SaaS integrations.

Threat narrative

Attacker objective: The objective is to exploit governance gaps in SaaS identity and access control to reach sensitive data or business workflows through trusted applications.

1. Entry occurs through unmanaged SaaS adoption, shadow IT, or weakly governed integrations that create accounts and tokens outside central review.
2. Escalation follows when unused or over-privileged entitlements persist, allowing attackers or insiders to move through SaaS-connected data and workflows.
3. Impact is reached when sensitive data, finance processes, or operational records are accessed through accounts the organisation no longer actively monitors.

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 now an NHI governance problem, not just a software cost problem. The article correctly focuses on hidden spend, but the more durable risk is identity drift across SaaS integrations, delegated access, and machine accounts. Once control ownership is fragmented, access review quality drops and revocation becomes inconsistent. Practitioners should treat sprawl as a governance and exposure issue, not a licence-optimisation exercise.

Access governance only works when it covers the full lifecycle of non-human access. Centralised visibility is necessary, but it is not enough if provisioning, certification, rotation, and offboarding still happen manually or in separate tools. SaaS environments expose the weakness in point-in-time control models because access changes faster than audit cycles. The field needs lifecycle discipline, not periodic clean-up.

SaaS control failure has a clear blast-radius effect. Every unmanaged app widens the set of identities that can reach sensitive data, finance workflows, and administrative functions. That expands the number of places where a single token, role, or integration failure can create lateral access. The practical lesson is to reduce standing privilege before expanding app coverage.

Access governance is becoming the bridge between IAM and NHI security programmes. Traditional IAM teams understand certification and policy enforcement, while NHI practitioners understand service accounts, secrets, and API access. SaaS sprawl forces those disciplines together because the same integration can involve human approvers and non-human execution paths. Organisations that keep those programmes separate will keep missing shared exposure.

Identity blast radius is the right concept for SaaS sprawl. The issue is not how many applications exist, but how far an identity can move once it is compromised or over-privileged. That blast radius is shaped by entitlements, dormant accounts, and cross-app permissions. Teams should measure and reduce that radius directly.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• This gap points to a broader lifecycle problem, as NHI Lifecycle Management Guide shows why provisioning, rotation, and offboarding must be governed together.

What this signals

SaaS sprawl is a preview of how identity governance fails when application growth outruns lifecycle control. As teams add more SaaS integrations, they also expand the number of machine-facing permissions that require ownership, review, and revocation. The right response is to treat SaaS access as part of the identity fabric, not as a separate software management concern.

Identity blast radius: the useful lens here is not just how many apps exist, but how far a compromised or stale identity can move across SaaS-connected processes. With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, the next governance step is to reduce cross-app trust and map each integration to a clear owner.

For programmes aligned to NIST Cybersecurity Framework 2.0, this means treating SaaS entitlement hygiene as a continuous detect and protect activity rather than a periodic audit task. The operational question shifts from which apps are installed to which identities can still act without active business need.

For practitioners

• Inventory SaaS applications and connected identities Build a single inventory that includes sanctioned apps, shadow IT, service accounts, API tokens, and OAuth grants. Tie each entry to an owner, business purpose, and review cadence so access decisions are not detached from operational accountability.
• Automate access certification for high-risk SaaS entitlements Prioritise privileged roles, finance workflows, and externally shared applications for continuous certification. Use exception handling for dormant accounts and stale integrations so revocation does not depend on quarterly review alone.
• Align SaaS controls with NHI lifecycle management Apply the same lifecycle discipline to machine access that you use for human access, including provisioning, rotation, and offboarding. This is especially important for application-to-application trust where credentials often outlive the business need.
• Reduce standing privilege across SaaS integrations Replace persistent admin access with just-in-time elevation wherever the platform allows it, and pair that with logging for delegated actions. The goal is to shrink the identity blast radius before an attacker or insider can reuse old permissions.
• Map SaaS governance to audit and compliance evidence Keep evidence for who approved access, when it was reviewed, and when it was revoked. That record should support GDPR, HIPAA, and CCPA obligations without forcing teams to reconstruct access history from multiple consoles.

Key takeaways

• SaaS sprawl becomes a governance risk when organisations lose track of who and what still has access.
• The scale is not marginal, with the source citing 18% annual SaaS growth and more than $18M in yearly waste from unused or duplicate tools.
• The response is lifecycle control, including inventory, certification, revocation, and reduced standing privilege across human and non-human access.

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.
• Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.
• Identity Blast Radius: Identity blast radius is the amount of damage an account can cause once it is compromised or over-privileged. In SaaS estates, the radius grows when integrations share trust, permissions are persistent, and ownership is unclear. Reducing blast radius means constraining privilege, shortening access duration, and improving revocation speed.
• Non-Human Identity Lifecycle: The non-human identity lifecycle covers the full sequence of creating, assigning, reviewing, rotating, and removing machine identities such as tokens, service accounts, and API keys. Strong lifecycle management prevents credentials from lingering after a system, project, or integration should no longer have access.

Deepen your knowledge

SaaS sprawl, access certification, and NHI lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring SaaS governance and machine access under one model, it is worth exploring.

This post draws on content published by SafePaaS: Eliminate the dangers of SaaS sprawl with access governance. Read the original.