Because removing a user from a directory or vault does not invalidate a copied password, token, or certificate that already exists elsewhere. Rotation changes the credential value itself, which is what cuts off reuse after departure or compromise. Without that step, the old secret can continue to work even after the account owner is gone.
Why offboarding has to do more than remove access
Offboarding is not complete when an account disappears from a directory, vault, or IAM tool. If the underlying secret is still valid, the departed user, a copied integration, or anyone who recovered the credential can continue to authenticate. Rotation changes the credential value itself, which is what actually breaks reuse after departure or compromise.
That distinction matters because access removal and secret invalidation solve different problems. Removing the account stops the current path through your control plane, but it does not neutralise material already copied out of band, cached in a script, stored in a personal password manager, or embedded in a client application. Rotation is the step that closes the residual trust gap.
What still works after an account is deleted
Many offboarding failures happen because teams treat a secret like a permission record instead of a reusable authentication artifact. A password, API key, token, or certificate can outlive the human or system account that once owned it, especially when the secret was shared, hardcoded, exported into logs, or distributed across multiple runtimes. The result is a credential that remains operational even after the owner is gone.
That is why offboarding should be paired with a search for every place the secret may exist, not just the primary system of record. If the same value was used by an application, a pipeline, or a partner integration, removing one account does not remove those other copies. Rotation is what forces every holder to re-establish trust with a new value.
Why rotation is the control that actually ends reuse
Rotation changes the secret material itself, so the old value stops working even if it has been copied elsewhere. That matters for both departure and suspected compromise, because an attacker only needs one surviving copy to retain access. If you want a deeper lifecycle view of this control, the NHI Lifecycle Management Guide explains why rotation and offboarding have to move together.
The same logic appears in broader identity practice. The Joiner-Mover-Leaver (JML) Guide ties leaver handling to revocation of the tokens, keys, and agents that remain behind, while the Secrets Management Guide shows why centralised secret control, rotation, and dynamic secret are the practical way to reduce reuse risk.
Risk and Threat Considerations
Offboarding that only removes directory access leaves a window for persistent reuse. The risk is highest when the secret has broad scope, long lifetime, or multiple hidden copies, because the departing user or an attacker who already obtained the value can keep authenticating after the account owner is removed.
Failure mechanism: The organisation revokes the named account but does not invalidate the credential value, so any copied password, token, or certificate continues to authenticate until the secret itself changes.
Impact: Access can survive termination, compromise, or role change, which extends blast radius, delays containment, and can turn a routine leaver event into an active compromise.
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, NIST SP 800-57 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Offboarding must retire non-human secrets so old credentials cannot still authenticate. |
| NHI-07 — Long-Lived Secrets | Old secrets remain usable after access removal when they are not replaced promptly. | |
| Recommendation — Rotate and revoke every surviving NHI credential path during leaver handling. Replace long-lived secrets with short-lived or rotated equivalents. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding needs authenticator lifecycle control, including replacement and invalidation. |
| AC-2 — Account Management | Account disablement alone does not retire copied credentials tied to the account. | |
| Recommendation — Enforce authenticator rotation, revocation, and lifecycle tracking for departing users. Disable accounts and coordinate credential invalidation for all associated authenticators. | ||
| NIST SP 800-57 | Key Management | The question hinges on retiring cryptographic material and ending reuse through rotation. |
| Recommendation — Set cryptoperiods and rotate keys before they can outlive their intended trust boundary. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control must be complemented by credential retirement when users leave. |
| A.8.5 — Secure authentication | The answer is about invalidating reused authenticators, not only disabling accounts. | |
| Recommendation — Pair access removal with secret rotation to prevent residual access. Retire and reissue authenticators when departure or compromise is possible. | ||
| CIS Controls v8 | CIS-5 — Account Management | Leaver handling needs account and credential removal as one control activity. |
| CIS-6 — Access Control Management | Residual access exists when copied secrets are not rotated after deprovisioning. | |
| Recommendation — Automate offboarding so accounts and their secrets are removed together. Revoke access paths and rotate surviving secrets immediately on departure. | ||
Practitioner Guidance
What to prioritise: Treat rotation as mandatory whenever a secret may have been exposed, shared, or used outside a tightly controlled vault. If you cannot prove that a credential never left its intended control path, assume it needs replacement.
What to verify: Confirm that the old secret is no longer accepted anywhere it could be used, including application clients, automation jobs, partner integrations, and fallback credentials. A successful directory disable is not enough evidence that reuse has ended.
Common mistake: Teams often revoke the human account and stop there. That is acceptable only when no reusable secret exists. Once a password, token, key, or certificate has been distributed, offboarding is incomplete until the value itself is retired and reissued.
Practitioner takeaway: Offboarding must invalidate the thing that authenticates, not just the account that once owned it, because attackers and former holders do not need the directory entry if the secret still opens the door.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org