De-provisioning is the process of removing access when an identity no longer needs it. In distributed environments, it must reach every connected app, token, and delegated permission, not only the primary login path, or the identity may retain access after the official offboarding step is complete.
Expanded Definition
De-provisioning is the controlled removal of access, entitlements, and trust relationships when an identity no longer has a business need. In NHI environments, that scope is broader than a human account shutdown because a service identity may be authenticated by tokens, certificates, API keys, cloud roles, delegated permissions, and workload-specific connectors. Guidance varies across vendors, but the practical expectation is consistent: de-provisioning must terminate effective access everywhere the identity can operate, not only in the primary directory or login system.
That makes de-provisioning a lifecycle control, not just an offboarding task. It is closely tied to NHI Lifecycle Management Guide and to broader governance patterns reflected in NIST Cybersecurity Framework 2.0. In practice, the process should revoke or expire credentials, remove delegated access, invalidate sessions where possible, and confirm that downstream systems no longer accept the identity. The most common misapplication is treating directory disablement as complete de-provisioning, which occurs when teams forget tokens, service-to-service permissions, and cached credentials in connected applications.
Examples and Use Cases
Implementing de-provisioning rigorously often introduces coordination overhead across teams and platforms, requiring organisations to weigh faster access removal against the operational effort of verifying every dependency.
- A service account used by a CI/CD pipeline is retired after a migration, and the pipeline’s API key, cloud role binding, and stored secret are all revoked at the same time.
- An application vendor contract ends, so delegated permissions, OAuth grants, and integration tokens are removed from the tenant rather than leaving the login account merely disabled.
- A workload certificate is replaced during a platform redesign, and the old certificate is invalidated so the retired workload cannot continue authenticating.
- A privileged automation bot is moved to a new identity model, and access is removed from the old bot after confirming no job scheduler or secret store still depends on it.
- Offboarding reviews are aligned to the lifecycle approach described in Ultimate Guide to NHIs, with verification steps that match NIST’s access control and remediation expectations.
Why It Matters in NHI Security
De-provisioning failures are a major cause of residual access because NHIs often persist outside the visibility of the primary identity system. NHIMG reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotation, which helps explain why stale access remains such a common control gap. This is especially dangerous in distributed architectures where one identity may be present in code, secrets stores, orchestration platforms, and third-party integrations at the same time. The risk is amplified by the volume of exposed and overprivileged NHIs identified in Top 10 NHI Issues.
Effective de-provisioning supports the intent of zero trust and access minimisation by ensuring that retired identities cannot be reused, replayed, or silently inherited by dependent systems. It also reduces the chance that an organisation mistakes token expiry for genuine revocation, or assumes a deactivated account means the associated secret has been neutralised. Organisations typically encounter the real impact only after a breach review, at which point de-provisioning becomes operationally unavoidable to close the access path that was left behind.
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 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-01 | Covers lifecycle and offboarding gaps that leave NHI access active after retirement. |
| NIST CSF 2.0 | PR.AA | Access removal and entitlement cleanup are core identity governance activities in CSF. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous trust reevaluation, including terminating obsolete identities. |
Verify de-provisioning events are fully executed and auditable across connected systems.
Related resources from NHI Mgmt Group
- What is the difference between just-in-time provisioning and just-in-time access?
- What is the difference between access certification and provisioning?
- What is the difference between onboarding access and NHI provisioning?
- What is the difference between access recertification and access provisioning?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
