They treat unused licenses as a cost issue only, when they are often a sign that access was never revalidated after role changes or project completion. Unused seats should trigger a review of ownership, tiering, and whether the application still belongs in the stack. Otherwise the organisation keeps paying for dormant access.
Why This Matters for Security Teams
Unused SaaS licenses are rarely just a finance problem. In identity-heavy environments, a dormant seat can indicate that access was not revalidated after a role change, project exit, or vendor transition. That matters because SaaS access often includes connected API tokens, delegated admin rights, and shared workflows that outlive the named user. NHI Mgmt Group notes that only 20% of organisations have formal offboarding and revocation processes for API keys, and even fewer rotate them consistently, which shows how easily “unused” access becomes forgotten access.
The security risk is that licence sprawl and access sprawl usually move together. A seat that looks inactive in procurement data may still be linked to mailbox rules, OAuth grants, or admin scopes. That is why current guidance from the NIST Cybersecurity Framework 2.0 treats access governance as an operational control, not just an entitlement spreadsheet. In practice, many security teams encounter the breach only after a dormant account or token has already been reused, rather than through intentional lifecycle review.
How It Works in Practice
Effective handling starts by separating three questions that are often conflated: did the user stop using the app, did the licence remain assigned, and does any downstream access still exist? The first is a usage signal. The second is a contract or spend signal. The third is a security signal. Organisations need all three views because a dormant SaaS seat can still hold privileged access through delegated permissions, connected identities, or machine-to-machine integrations.
Operationally, the strongest pattern is to tie SaaS lifecycle review to identity lifecycle events. When a person changes role, finishes a project, or leaves, the organisation should review application ownership, remove stale entitlements, and reissue access only where justified. For service-heavy apps, this should include connected secrets and tokens, because SaaS access often persists beyond the human account itself. The broader NHI guidance in Ultimate Guide to NHIs is relevant here because the same governance model applies to non-human access that is easy to miss during software cleanup.
- Use usage data to identify inactive seats, then validate whether the account is truly dormant.
- Check whether the app is still approved, still owned, and still tied to a business process.
- Review connected API keys, OAuth grants, and admin roles before reclaiming the licence.
- Reassign or remove access through a formal workflow, not ad hoc seat cleanup.
- Feed the findings into access review, procurement, and offboarding controls.
This becomes more important after incidents such as the Salesloft OAuth token breach and the BeyondTrust API key breach, where the credential problem was not visible as “license waste” in isolation. These controls tend to break down when SaaS ownership is split across procurement, IT, and business teams because no single group owns the full access lifecycle.
Common Variations and Edge Cases
Tighter licence reclamation often increases operational overhead, requiring organisations to balance cost savings against user friction and support workload. That tradeoff is especially real in fast-moving teams, temporary project environments, and companies with high contractor turnover. A seat may look unused because the user logs in through automation, a shared admin workflow, or infrequent but legitimate business activity. Current guidance suggests that “inactive for 30 days” is not, by itself, a defensible security conclusion.
There is also no universal standard for how to classify SaaS inactivity across all applications. Some tools generate noisy usage telemetry, while others under-report access because activity happens through API calls rather than interactive logins. In those cases, organisations should prefer evidence of ownership and downstream access over simplistic login counts. The most reliable answer often comes from reconciling SaaS inventory with identity governance and lifecycle controls, rather than from finance reports alone.
For teams building a broader governance model, the lesson from incidents like the Snowflake breach is that dormant or mis-scoped access can remain exploitable long after it appears unused. Security teams should treat reclaimed licences as a trigger for review, not as proof that risk has disappeared.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Unused SaaS seats often hide stale credentials and weak offboarding. |
| NIST CSF 2.0 | PR.AC-4 | Access reviews are the right control for reclaiming inactive SaaS permissions. |
| NIST AI RMF | AI RMF helps frame lifecycle, accountability, and governance for identity decisions. |
Revalidate and revoke dormant SaaS-linked identities, tokens, and keys on a defined schedule.
