Identity deprovisioning is the process of removing an account’s access when a person, service, or system no longer needs it. In IAM, it disables or deletes human and NHI credentials, revokes roles, tokens, and certificates, and updates connected applications to reduce lingering access and unauthorized use.
What Identity Deprovisioning Covers
Identity deprovisioning is the end of the access lifecycle. It removes an account’s ability to authenticate, authorize, or continue acting once the person, service, or system no longer has a valid need for access.
In practice, that means more than just disabling a login. It also means revoking roles, expiring tokens, removing certificates, and closing any remaining trust paths that connected applications may still accept.
Why Identity Deprovisioning Matters
Deprovisioning matters because stale access is one of the easiest ways for legitimate access to become unauthorized access. The longer an inactive account, token, or service credential remains usable, the more time an attacker, ex-employee, or forgotten integration has to exploit it.
This is especially important in environments with many SaaS apps, federated logins, and machine credentials. Employee offboarding security and similar lifecycle controls are only effective when deprovisioning reaches every place that account authority was copied or cached.
What Gets Removed During Deprovisioning
A complete deprovisioning flow usually touches several layers at once. Human access may be terminated through directory disablement, while NHI-related access may require token revocation, certificate invalidation, secret rotation, or removal of service-account entitlements.
The key idea is that access is often distributed. A single identity can have direct app access, API access, delegated roles, group membership, and long-lived credentials in downstream systems. If any one of those remains active, the identity is not really deprovisioned.
That is why many organisations pair deprovisioning with Joiner-Mover-Leaver (JML) processes and automated workflows, so role changes and departures do not leave behind access that outlives the business need.
How Deprovisioning Should Be Governed
Good deprovisioning depends on ownership, timing, and coverage. HR, IAM, application owners, and platform teams all need a clear handoff path so that access removal happens quickly and consistently instead of relying on manual memory or ad hoc tickets.
For non-human access, governance is just as important as for people. SCIM and automated provisioning help organisations standardise lifecycle changes, but they only work well when downstream applications actually support deprovisioning and when exceptions are tracked, not ignored.
Strong programs also keep a visible inventory of where identities exist, what they can do, and which systems must be updated when access ends. Without that inventory, deprovisioning becomes partial by default.
Risk and Threat Considerations
Lingering access creates a direct security exposure because the account still exists after the business relationship has ended. That can lead to unauthorized access, persistence after compromise, privilege reuse, and hidden access paths that survive normal review cycles.
Failure mechanism: Deprovisioning often fails when one system is updated but another still trusts the old identity, such as a revoked directory account that still has valid tokens, certificates, API keys, or app-local entitlements.
Impact: The result can be account takeover, unauthorized data access, fraudulent use of services, lateral movement, or delayed detection of a compromise because the access looks legitimate to downstream systems.
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 surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Directly governs account disabling and removal across the identity lifecycle. |
| IA-5 — Authenticator Management | Applies because deprovisioning must revoke or invalidate credentials, tokens, and keys. | |
| Recommendation — Automate AC-2 to disable and remove accounts immediately when access is no longer needed. Apply IA-5 to revoke authenticators and rotate shared secrets during offboarding. | ||
| CIS Controls v8 | 5 — Account Management | Covers account lifecycle hygiene, including timely removal of unused or departed access. |
| Recommendation — Use CIS-5 to inventory, disable, and remove accounts that no longer have a business need. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Requires access rights to be provisioned, reviewed, and removed according to policy and need. |
| Recommendation — Use A.5.18 to ensure access removal follows defined approval and revocation procedures. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Defines the risk of leaving non-human identities active after their intended lifecycle ends. |
| Recommendation — Remove non-human access promptly when the identity is no longer required. | ||
Practitioner Guidance
Why practitioners should care: Treat deprovisioning as a control that must be complete, timely, and testable, not as a help desk closure step. The real question is whether every authority tied to the identity has been removed from every system that still accepts it.
What to watch for: Delays between termination and revocation, orphaned service accounts, inactive but still-valid tokens, and applications that cannot prove they removed access are the warning signs that deprovisioning is incomplete.
Practitioner takeaway: If you cannot confirm that access disappeared everywhere, the identity is still effectively active.