Ownership should sit with a shared governance process across IAM, IT, procurement, and application owners, because reclaimed licences can still hide active access or stored data. The key is to make offboarding and renewal decisions from the same entitlement record, so decommissioning does not lag behind spending decisions.
Why This Matters for Security Teams
SaaS licence reclamation is often treated as a finance exercise, but the security impact is operational and immediate. A reclaimed licence can still map to an active service account, cached API token, shared mailbox, or stored business data, so “unused” rarely means “safe to remove.” That is why licence decisions and offboarding decisions must be tied to the same entitlement record, not run as separate workflows.
Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that identity, access, and asset governance should be coordinated across functions rather than handled in silos. NHIMG research shows how costly the gap can be: in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, only 20% of organisations reported formal processes for offboarding and revoking API keys. That same weakness shows up in SaaS cleanup, where no one owns the full chain from purchase, to access, to revocation.
The practical risk is simple: reclaiming spend without removing access creates a false sense of control. In practice, many security teams discover stale access only after a renewal, audit finding, or data exposure has already exposed the gap.
How It Works in Practice
The strongest operating model is shared ownership with a clear system of record. IAM should own identity and entitlement enforcement, IT should execute technical offboarding, procurement should control renewal and contract timing, and application owners should confirm whether the app still supports a business process. Security should define the policy and verify completion, not carry every task itself.
In practice, that means every SaaS app needs a single entitlement record that includes the user, group, service account, SSO connection, API tokens, data retention state, and renewal date. When a licence is flagged for reclamation, the workflow should answer three questions before removal: does the app hold sensitive data, does it authenticate anything other than the named user, and does deprovisioning trigger downstream dependency cleanup? If the answer to any of those is yes, the app offboarding path must run, not just the licence reclaim path.
This is where lifecycle discipline matters. NHIMG’s NHI Lifecycle Management Guide is relevant because the same pattern applies to non-human access: identify, approve, use, rotate, revoke, and verify. For SaaS, that verification step should confirm that tokens are invalidated, integrations are broken intentionally, and data ownership has been transferred or deleted according to policy. The Top 10 NHI Issues also reflects a common failure mode: organisations know where spending is, but not where access is still alive.
- Use procurement to trigger review at renewal or non-use thresholds.
- Use IAM to revoke SSO, groups, and service-account entitlements.
- Use app owners to confirm data, integrations, and downstream dependencies.
- Use IT to execute deletion, archive, or transfer steps and record completion.
- Use security to validate that revocation actually removed standing access.
These controls tend to break down in highly integrated SaaS environments because one licence can mask multiple machine-to-machine connections, shared admin roles, and externally stored secrets.
Common Variations and Edge Cases
Tighter offboarding often increases coordination overhead, requiring organisations to balance rapid licence recovery against the risk of breaking business workflows. That tradeoff is real, especially where applications are shared across teams or where a single SaaS account acts as both a human seat and an automation endpoint.
There is no universal standard for this yet, but current guidance suggests a few practical exceptions. First, shared admin accounts and integration accounts should be treated as non-human identities, not ordinary licences, because reclaiming the seat without revoking the token leaves the highest-risk path open. Second, regulated environments may require retention holds, so offboarding must preserve evidence and data according to legal policy before access is removed. Third, if an application has no dependable owner, procurement should not be the final authority by default; the app should be escalated to the business system owner or formally retired.
NHIMG breach research, including the Salesloft OAuth token breach, shows why this matters: access often persists through tokens and integrations long after a user stops using the interface. For security teams, the rule is not “who paid for it” but “who can prove the app is safe to shut down.”
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Licence reclamation often fails when non-human credentials are not revoked. |
| NIST CSF 2.0 | PR.AC-4 | Shared ownership is needed to manage access rights through the full lifecycle. |
| CSA MAESTRO | M1 | SaaS offboarding must account for machine and agent access, not just users. |
Tie every SaaS reclaim to token, key, and service-account revocation before closing the record.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
