TL;DR: SaaS sprawl grows when teams adopt project tools outside procurement, then leave unused accounts, duplicate subscriptions, and unclear deprovisioning paths behind, according to 1Password. The security issue is not the bill alone, but the identity lifecycle gap that appears when access removal, data reassignment, and ownership are handled inconsistently.
At a glance
What this is: This is a SaaS optimization analysis showing that unused seats, duplicate apps, and inconsistent deprovisioning create a broader identity lifecycle gap than cost waste alone.
Why it matters: It matters because IAM, IGA, and SaaS governance teams have to control access removal, data transfer, and ownership changes together, not treat license cleanup as a finance exercise.
Context
SaaS sprawl happens when teams can adopt software quickly, often without procurement or IT visibility. In practice, the identity problem appears when accounts are created outside central governance and later removed, reassigned, or left dormant without a consistent offboarding path.
For IAM and IGA teams, the issue is not just redundant spend. It is the lack of a reliable lifecycle model for SaaS access, especially when project tools, social logins, and manual deprovisioning steps are handled differently from one application to the next.
The article focuses on project management tools, but the underlying pattern is broader: self-service adoption is easy, while proving who still needs access and what happens to their data is far harder. That is typical across SaaS estates, not an edge case.
Key questions
Q: What breaks when SaaS deprovisioning is handled as a one-click admin task?
A: Accounts may be disabled without understanding whether the user is seasonal, whether data must be transferred, or whether work needs to be reassigned. That can create orphaned tasks, accidental deletion, and access gaps that only appear when someone urgently needs the application again.
Q: When should teams prioritise deprovisioning over license consolidation?
A: Prioritise deprovisioning first when you cannot yet prove who still needs access or what happens to the user’s data. License consolidation reduces cost, but deprovisioning removes residual access risk and exposes the true lifecycle state of the SaaS estate.
Q: How do you know if SaaS access governance is working?
A: It is working when access disappears quickly after a business change, review records identify a clear owner for each app, and audit evidence links entitlements to current need. If dormant accounts, unmanaged integrations, or unknown app owners keep appearing, the programme is documenting sprawl rather than controlling it.
Q: What happens when a user leaves a SaaS app but their data and tasks are not reassigned?
A: The account may disappear while the operational work remains behind, creating orphaned files, unresolved tasks, or hidden privilege transfer to the next person who inherits the account. That is a governance failure because access removal was not paired with data and workflow disposition.
Technical breakdown
Why SaaS discovery is only the first control
SaaS discovery tells you what exists, but it does not by itself tell you whether access is still needed. In many environments, employees can create accounts in minutes, use credit cards or free tiers to bypass procurement, and leave no clean central inventory trail. That creates a governance blind spot where IT can see cost signals later than the business sees adoption. Discovery therefore has to connect to ownership, user intent, and app criticality, otherwise it becomes a list rather than a control plane.
Practical implication: tie SaaS discovery to ownership assignment and access review, not just application enumeration.
How deprovisioning differs from simple account deactivation
Deprovisioning is the lifecycle step that removes access and handles the user’s data and associated work. The article makes clear that this can mean very different outcomes across SaaS products: an account may be disabled, retained for reactivation, or deleted after a delay, and content may be transferred to another user. That means offboarding is a policy decision as much as an administrative task. If the same process is used everywhere, teams will either over-remove access or leave residual access and orphaned data behind.
Practical implication: define offboarding rules per application class, including account state, data retention, and reassignment behavior.
Why social logins and manual workflows widen the identity gap
Social login visibility can reveal who is using a SaaS application, but it does not solve governance on its own. If access is mediated through external identities and the offboarding workflow is manual, the control chain still depends on humans noticing inactivity, contacting the user, and checking contract timing before actioning removal. That creates a delay window in which access may persist beyond need. The architectural issue is not the login method itself, but the absence of a consistent lifecycle trigger between usage change and account disposition.
Practical implication: integrate login telemetry with offboarding triggers and approval logic so access removal is not dependent on ad hoc follow-up.
Threat narrative
Attacker objective: The practical objective is not theft in the classic sense, but persistence of unnecessary access and unmanaged data paths across the SaaS estate.
- Entry occurs when employees sign up for SaaS tools directly in the browser, often outside procurement or IT visibility.
- Escalation happens when redundant subscriptions and unused seats accumulate, leaving access and ownership decisions inconsistent across applications.
- Impact follows when deprovisioning is delayed or applied unevenly, creating orphaned accounts, unclear data reassignment, and unnecessary security and compliance exposure.
Breaches seen in the wild
- Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity lifecycle is the real control gap behind SaaS sprawl: the article is not really about how many tools exist, but about how easily access is created and how inconsistently it is removed. That gap sits between discovery and offboarding, where ownership, user intent, and data handling are often treated as separate tasks. For IAM and IGA programmes, SaaS sprawl should be read as a lifecycle governance problem first and a cost problem second.
Service account visibility is the clearest indicator that discovery still underperforms governance: when organisations cannot see who or what still has valid access, they cannot credibly certify risk or prove least-privilege enforcement. The low visibility benchmark in the article underscores that many teams still lack a reliable view of non-human and service access across SaaS estates. Practitioners should treat that as evidence that the inventory is not yet governable.
Identity reassignment logic is part of the security model, not just an admin detail: when one user leaves, the question is not only whether their account is disabled, but where their tasks, files, and approvals go next. Inconsistent reassignment creates hidden continuity risks and can silently expand the next user’s effective privilege. Governance teams need to treat reassignment behavior as a policy boundary, not an afterthought.
Standardisation only works when exceptions are explicit: the article is right to note that some teams need specialised tools, but that exception logic must be visible and documented. Otherwise, standardisation becomes an informal sprawl of tolerated exceptions. The broader lesson is that application rationalisation without governance of exceptions simply relocates the fragmentation.
SaaS optimisation is becoming a lifecycle discipline: the next maturity step is not just consolidating licenses, but aligning discovery, approval, access removal, and data transfer in one operating model. That is where SaaS management stops being a procurement exercise and becomes identity governance. Practitioners should measure success by how cleanly users, data, and ownership move through the lifecycle.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Lifecycle ownership needs to move upstream of offboarding: teams that only act when seats look unused will always be late, because the harder problem is deciding what should happen to data and task ownership before access is removed. SaaS governance becomes materially stronger when ownership, reassignment, and deletion rules are defined per application class, not improvised at the point of removal.
Discovery without disposition is not governance: an application inventory is useful only when it connects to an explicit removal path, an owner, and a retention decision. Otherwise, the programme can report on sprawl without reducing it. That is why SaaS optimisation and identity governance have to be run as the same operating process.
Identity lifecycle discipline now spans human and non-human access patterns: the same organisations that struggle to see service accounts clearly often struggle just as much with SaaS users who self-provision through credit cards, free tiers, or social login. The governance lesson is consistent across actor types: access creation is easy, but accountable removal is what determines risk.
For practitioners
- Implement SaaS offboarding rules by application Define whether each app should disable, retain, or delete an account, and specify how associated data is reassigned or retained before any deprovisioning begins.
- Review unused SaaS seats against last login Use last-login data to identify accounts that appear dormant, then validate whether they are seasonal, infrequent, or genuinely abandoned before removal.
- Document data handoff behavior on deprovisioning Map what happens to tasks, files, and ownership when a user leaves each major SaaS tool so removal does not create orphaned work or hidden privilege transfer.
- Separate standard apps from approved exceptions Create a documented exception list for teams that genuinely need specialist tools, and review those exceptions on a recurring governance cycle.
- Connect SaaS discovery to identity governance Feed adoption and login telemetry into access review and lifecycle workflows so offboarding does not depend on ad hoc manual follow-up.
Key takeaways
- SaaS sprawl becomes a governance problem when teams can create access quickly but cannot remove it with equal clarity.
- The real control gap is not the number of subscriptions alone, but the inconsistent handling of deprovisioning, reassignment, and data retention.
- IAM and SaaS governance teams should treat offboarding rules as part of the access model, not as a cleanup task after cost optimisation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article centres on delayed and inconsistent SaaS offboarding across apps. |
| NHI-03 — Vulnerable Third-Party NHI | SaaS tools create external identity dependencies that change ownership and access scope. | |
| NHI-05 — Overprivileged NHI | Unused seats and duplicate subscriptions often leave more access active than the business needs. | |
| Recommendation — Map SaaS deprovisioning gaps to NHI-01 and standardise offboarding outcomes by application. Review third-party SaaS access paths for unmanaged lifecycle dependencies and offboard them cleanly. Reconcile active SaaS accounts against actual use and remove excess privileges from dormant users. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing who still has access and when that access should be removed. |
| Recommendation — Apply PR.AA-05 to keep SaaS entitlements aligned with current business need and ownership. | ||
| CIS Controls v8 | CIS-5 — Account Management | The core operational issue is tracking, deactivating, and transferring SaaS accounts consistently. |
| Recommendation — Use CIS-5 to formalise account lifecycle handling across your SaaS portfolio. | ||
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.
- Deprovisioning: Deprovisioning is the removal of access when a user changes roles or leaves an organisation. For security teams, it is the point where stale accounts, tokens, and permissions should disappear. Weak deprovisioning leaves residual access that can outlive the business need that created it.
- Identity lifecycle automation: The orchestration of joiner, mover, and leaver events so access is granted, adjusted, and removed without manual gaps. For mixed identity estates, it matters because revocation and review must keep pace with identities that do not follow human employment timelines.
- Access Review Reassignment: Access review reassignment changes the reviewer because the original assignment is no longer valid. This is appropriate when ownership has shifted, the person has changed roles, or the reviewer record is outdated. Reassignment corrects the control at the source rather than borrowing another person’s authority for one cycle.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org