Because SCIM usually updates identity state, but it does not automatically kill the credentials already issued by the application. Sessions, refresh tokens and API keys can continue working until the app explicitly revokes them. If deprovisioning only flips a user to inactive, the account is recorded as closed while real access can remain available.
Why This Matters for Security Teams
SCIM is valuable for synchronising identity state, but offboarding risk is created by everything SCIM does not own: active sessions, refresh tokens, API keys, SSH keys, service credentials, and cached entitlements in downstream apps. That gap matters because deprovisioning often looks complete on paper while a former employee still has valid access paths in practice. NHI Management Group has also documented how lingering secrets create real exposure long after a notification window closes in its Ultimate Guide to NHIs.
Security teams tend to overtrust the SCIM event itself. In many environments, the identity provider marks the account inactive, but the application remains responsible for invalidating bearer tokens, terminating sessions, and revoking app-specific credentials. NIST guidance on access control and session management in NIST SP 800-53 Rev 5 Security and Privacy Controls makes that separation of duties clear, yet operational handoffs are still inconsistent. The practical problem is not whether the account is disabled, but whether the credential chain behind that account has actually been broken.
Current NHI research from The 2024 ESG Report: Managing Non-Human Identities shows the broader pattern: 72% of organisations have experienced or suspect a breach involving NHIs, which is a reminder that lifecycle controls fail when they stop at identity state instead of access reality. In practice, many security teams discover the gap only after a post-offboarding login or API call has already occurred, rather than through intentional validation.
How It Works in Practice
Effective offboarding needs two coordinated actions: deprovision the identity and revoke the credentials it was using. SCIM can remove group membership, deactivate the user object, or signal a downstream app to close an account, but that is not the same as invalidating all issued access artifacts. The application must explicitly terminate sessions, revoke refresh tokens, expire cookies, rotate API keys where applicable, and invalidate any delegated grants. This is why lifecycle management has to include both human identity workflows and application credential workflows, as described in the NHI Lifecycle Management Guide.
In mature environments, the offboarding sequence is usually policy-driven and event-based:
- Disable the authoritative identity in the IdP or HR trigger source.
- Call application APIs to revoke sessions and refresh tokens, not just mark the account inactive.
- Rotate shared secrets, service account passwords, and API keys that may have been exposed to the user.
- Check for delegated access through OAuth grants, shared inboxes, CI/CD credentials, and local caches.
- Verify closure with audit logs and a post-offboarding access test.
Where possible, teams should reduce dependence on long-lived secrets in the first place. NIST’s framework for identity and access governance in NIST Cybersecurity Framework 2.0 aligns with the broader principle that access needs continuous control, not one-time approval. For NHIs, that means pairing SCIM with secret inventory, token revocation APIs, and workflow automation across every app that can issue independent credentials. These controls tend to break down when the application has no revocation endpoint, when secrets are embedded in code or CI/CD systems, or when the business relies on manual confirmation from dozens of downstream owners.
Common Variations and Edge Cases
Tighter offboarding often increases operational overhead, requiring organisations to balance faster revocation against application compatibility and user impact. That tradeoff becomes sharper in environments with legacy SaaS, federated logins, and systems that do not support SCIM beyond basic account disablement. Current guidance suggests treating those apps as residual-risk systems until they can prove token and session revocation behaviour, but there is no universal standard for this yet.
Edge cases matter. Some applications issue refresh tokens that survive a user deactivation event unless an explicit revocation call is made. Others allow API keys to remain valid even after the user is removed because the key is attached to a project, not a person. Shared admin accounts, break-glass access, and service accounts used by the offboarded employee can also remain active unless they are inventoried separately. NHI Management Group’s research in the Ultimate Guide to NHIs highlights how often organisations miss these non-obvious credential paths.
Another common exception is delegated access. A former employee may no longer authenticate directly, yet still influence systems through OAuth approvals, shared secrets, or workflow automations they created. That is why offboarding should be tested as a credential lifecycle event, not just an HR termination event. In practice, the riskiest environments are those with many apps that each maintain their own token model and no central revocation endpoint, because SCIM can update state without ever breaking the access path.
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, NIST SP 800-53 Rev 5, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Offboarding gaps often leave NHI credentials valid after identity deactivation. |
| NIST CSF 2.0 | PR.AC-4 | Access revocation and session termination are core to identity lifecycle control. |
| NIST SP 800-53 Rev 5 | AC-2 | Account lifecycle management requires timely disablement and authorization removal. |
| NIST AI RMF | Lifecycle oversight supports trustworthy automation and accountable access decisions. | |
| NIST Zero Trust (SP 800-207) | Zero trust assumes sessions and credentials must be continually revalidated. |
Tie offboarding to verified removal of all application access, not just IdP status changes.
