Because inventory alone does not remove access. A SaaS platform becomes a governance control only when it can revoke user, admin, and delegated app access as part of offboarding or ownership change. Without that, organisations keep paying for unused access while leaving stale permissions in place.
Why This Matters for Security Teams
saas inventory answers what is installed, but offboarding answers what is still authorised to act. That distinction matters because access is not just a licensing issue; it is an identity lifecycle issue that affects users, admins, API keys, OAuth grants, and delegated apps. NIST Cybersecurity Framework 2.0 frames this as a governance and access-management problem, not a discovery-only exercise.
When a SaaS tenant is handed to a new owner, merged, or retired, stale permissions often remain behind even if the tool is still visible in inventory. NHIMG’s NHI Lifecycle Management Guide treats offboarding as a required control point because lifecycle failure is where exposure becomes persistent. That is especially true when service-to-service access, delegated app permissions, and admin tokens are involved. In practice, many security teams encounter privilege residue only after a former owner leaves or a vendor relationship changes, rather than through intentional offboarding.
How It Works in Practice
A real offboarding workflow does more than close a SaaS ticket. It identifies every identity and trust path tied to the application, then revokes them in a sequence that prevents orphaned access. The most reliable workflows map the SaaS app to its human owners, admin roles, connected integrations, service accounts, OAuth consents, and any secrets stored outside the platform. That is the operational difference between app inventory and access control.
For SaaS governance, the practical sequence is usually:
- Confirm ownership change, retirement, or employee departure triggers the workflow.
- Revoke human access first, then admin privileges, then delegated app grants.
- Rotate or retire API keys, refresh tokens, certificates, and other secrets tied to the tenant.
- Validate that connected automations, SCIM links, and webhooks no longer hold usable access.
- Record the outcome in audit logs and ticketing so the offboarding is provable.
This is where lifecycle data matters. NHIMG’s Ultimate Guide to NHIs and lifecycle processes notes that only 20% of organisations have formal processes for offboarding and revoking API keys. That aligns with the real operational gap: many teams can list the app, but cannot enumerate every downstream identity it created or consumed. Current guidance suggests treating saas offboarding as a closure event for all associated NHIs, not just a deprovisioning task for the primary user.
For access governance, the objective is to make revocation deterministic and time-bound, with evidence that delegated access has been removed and any residual secrets have been invalidated. The NIST Cybersecurity Framework 2.0 supports this through access control, asset governance, and recovery-oriented practices. These controls tend to break down in highly integrated SaaS environments because undocumented app-to-app trust paths make complete revocation difficult to verify.
Common Variations and Edge Cases
Tighter offboarding often increases operational overhead, requiring organisations to balance complete revocation against fast employee exits and service continuity. That tradeoff is especially visible when SaaS tools are deeply embedded in sales, support, or engineering workflows.
Some environments need special handling. Shared workspaces may have no single “owner,” so offboarding must be tied to business process ownership rather than one account. In federated SaaS setups, SCIM can remove the user but still leave OAuth grants and API tokens alive in connected systems. Best practice is evolving here, and there is no universal standard for this yet: organisations should combine access reviews, secret rotation, and integration inventory rather than rely on a single control.
NHIMG’s research on the Top 10 NHI Issues is useful because stale credentials and excessive privilege often survive well past the ticket closure. In parallel, the Entro Security findings in the 2025 State of NHIs and Secrets in Cybersecurity report that 91% of former employee tokens remain active after offboarding, which shows why inventory alone is not a sufficient control.
In SaaS platforms that support delegated administration or app marketplaces, offboarding must also account for third-party grants and tenant-level automations. Otherwise, the platform remains “known” but still callable, and that is the failure mode that turns visibility into false assurance.
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 | Offboarding must revoke stale NHI credentials and app grants. |
| NIST CSF 2.0 | PR.AC-4 | Access control needs revocation when ownership changes or staff leave. |
| NIST AI RMF | Governance should cover lifecycle risk, accountability, and traceability. |
Apply AI RMF governance discipline to lifecycle ownership, logging, and revocation evidence.
