Deactivation is the process of disabling an identity’s access while preserving its record and related history. Organisations use it when they need to stop access quickly but still retain evidence for audit, investigation, or retention. It is different from deletion because the identity remains available for governance and compliance purposes.
Expanded Definition
Deactivation in NHI governance means suspending an identity’s ability to authenticate, authorise, or call tools while preserving the identity record, metadata, and related audit history. In practice, it sits between active use and full retirement, and it is especially important for service accounts, API keys, certificates, and agent identities that may need to be stopped immediately without destroying evidence. This distinction matters because deletion can break investigations, retention obligations, and dependency tracing.
Definitions vary across vendors on whether deactivation must disable token issuance, revoke existing sessions, or merely mark the identity as inactive. In NHI Management Group terms, a sound deactivation process should address both access blocking and downstream cleanup, including credential revocation, policy updates, and logging. For control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls is the clearest external reference for lifecycle-linked access control and auditability.
The most common misapplication is treating deactivation as deletion, which occurs when teams disable an account in one system but leave valid secrets, cached sessions, or automation hooks active elsewhere.
Examples and Use Cases
Implementing deactivation rigorously often introduces operational friction, requiring organisations to balance rapid containment against the risk of disrupting dependent workloads, pipelines, or incident response evidence.
- An API key used by a third-party integration is deactivated after anomalous calls are detected, while the key record is retained for forensics and vendor review.
- A service account linked to a departed application owner is disabled, then reviewed for remaining dependencies before the identity is either reissued or formally retired.
- An AI agent with tool access is paused during a security incident so it cannot execute actions, but its event history remains intact for root-cause analysis.
- A certificate-based workload identity is marked inactive after rotation, preventing reuse of an old credential while preserving traceability across systems.
- An offboarding workflow references guidance from the Ultimate Guide to NHIs and aligns the final access state with NIST SP 800-53 Rev 5 Security and Privacy Controls.
In mature environments, deactivation is triggered by incident containment, ownership change, contract end, or credential compromise rather than by a fixed calendar date alone.
Why It Matters in NHI Security
Deactivation is a core control point because inactive identities that remain technically usable become hidden access paths. In NHI environments, a “disabled” label is not enough if long-lived tokens, cached sessions, delegated permissions, or automation secrets still function. That gap is where compromise persists. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 71% of NHIs are not rotated within recommended time frames, which makes incomplete shutdowns especially dangerous. The Ultimate Guide to NHIs also reports that only 20% of organisations have formal processes for offboarding and revoking API keys, showing how often deactivation is handled inconsistently.
For governance, effective deactivation supports least privilege, incident response, evidence retention, and Zero Trust posture. It also reduces the chance that orphaned identities become unmonitored persistence mechanisms after a breach. This is where deactivation intersects with NIST SP 800-53 Rev 5 Security and Privacy Controls and broader lifecycle controls described in the Ultimate Guide to NHIs.
Organisations typically encounter the real cost of deactivation only after an incident review exposes that an account was “disabled” in name but still functional through a lingering secret or integration path, at which point deactivation becomes operationally unavoidable to address.
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, NIST SP 800-63 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-05 | Deactivation directly concerns NHI lifecycle control and removal of lingering access paths. |
| NIST CSF 2.0 | PR.AC-7 | Identity lifecycle and access revocation map to prompt removal of access when no longer needed. |
| NIST SP 800-63 | IAL/AAL lifecycle | Identity assurance guidance depends on timely suspension and termination of credentials. |
| NIST Zero Trust (SP 800-207) | PA-2 | Zero Trust requires continuous access evaluation and rapid withdrawal of trust on risk change. |
| CSA MAESTRO | Identity lifecycle governance | Agentic systems need lifecycle governance for pausing or disabling agent identities safely. |
Treat deactivation as a credential lifecycle event and invalidate authenticators as needed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
