Rotation replaces a credential while preserving the identity and its approved use, which helps reduce exposure during normal operations. Revocation removes the credential entirely because the workload, integration, or relationship is no longer trusted or needed. Both matter, but offboarding is the stronger control when an identity is retired, decommissioned, or handed to another team.
When Should You Rotate a Non-Human Credential Instead of Revoking It?
Rotation is the right move when the credential is still needed, but the value of that secret has changed, for example after routine age-out, suspected exposure, scope expansion, or a planned maintenance cycle. Revocation is the right move when continued use is no longer justified. The difference is not cosmetic: rotation preserves operational continuity, revocation terminates trust.
For a workload, integration, or automation path that is still in service, rotation reduces exposure without breaking the dependency. For a retired system, completed migration, or abandoned third-party relationship, revocation removes the access path entirely and avoids leaving a valid secret behind.
Practitioners often treat the two as interchangeable because both involve “changing a secret”, but the security outcome is different. Rotation keeps the identity alive and resets the credential state; revocation removes the credential as an authorisation artifact and should be the default when the identity no longer has a business owner or approved purpose.
Why Offboarding Usually Requires Revocation, Not Just Rotation
Offboarding changes the trust relationship, not just the password-equivalent. When a workload, API client, or partner integration is decommissioned, handed over, or replaced, rotating the credential alone may leave the same access path available to a process that should no longer exist. That creates unnecessary residual access and can delay detection if the old secret is still valid somewhere.
Revocation is especially important where the credential can authenticate broadly, reach production systems, or be reused across environments. In those cases, the strongest control is to remove the credential, then confirm the related identity, keys, tokens, or certificates are also removed from inventory and distribution points. For lifecycle discipline, the Joiner-Mover-Leaver (JML) Guide is the clearest operational reference for treating offboarding as a deprovisioning event rather than a simple rotation task.
Where the identity is retired but the secret is still functional, revocation closes the gap between “no longer needed” and “still technically valid.” That distinction matters most when access is delegated through automation, service-to-service calls, or vendor connectivity, because those paths can continue quietly unless they are explicitly torn down.
How to Decide Between the Two in Practice
The clean rule is simple: rotate when the identity remains legitimate, revoke when the identity or relationship is ending. If you are preserving the same approved use, rotation is appropriate; if you are ending the use, revocation is the correct control. If you cannot identify a current owner, purpose, or renewal path, treat the secret as an offboarding candidate rather than a rotation candidate.
Two practical checks help avoid mistakes. First, verify whether the credential is still referenced by any active workload, pipeline, or partner contract. Second, verify whether the new secret will actually replace every existing copy before you retire the old one. That is why lifecycle guidance such as the NHI Lifecycle Management Guide is useful: it links rotation, offboarding, and inventory control as one governance problem, not three separate tasks.
For secrets specifically, the API Key Management Guide reinforces the same decision pattern: rotate for routine hygiene or suspected exposure, revoke when the key is no longer supposed to work at all. That prevents teams from using rotation as a substitute for decommissioning.
Risk and Threat Considerations
The main risk is residual validity. A rotated credential may still exist in old deployments, scripts, or vendor systems, while a revoked credential can fail fast if something was missed. If offboarding is incomplete, the remaining secret becomes a standing access path that attackers can abuse after the relationship was supposed to end.
Failure mechanism: rotation updates the secret value but does not necessarily remove the old credential from every place it was distributed; revocation removes the trust anchor entirely, which is what you need when the identity is no longer entitled to access.
Impact: using rotation when revocation is required can leave orphaned access, enable reuse of stale credentials, and extend the blast radius of a decommissioned workload, partner, or integration.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Offboarding is the core distinction between revoking and rotating non-human credentials. |
| NHI-07 — Long-Lived Secrets | Rotation versus revocation directly affects how long a secret remains usable. | |
| Recommendation — Revoke credentials when the NHI is retired or decommissioned. Shorten secret lifetime and remove credentials that no longer need to exist. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and revocation are authenticator lifecycle controls. |
| AC-2 — Account Management | Offboarding requires removing or disabling accounts tied to the credential. | |
| Recommendation — Manage authenticators through issuance, change, and invalidation. Disable or remove accounts when the associated role or relationship ends. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity lifecycle governance covers who remains entitled to use a credential. |
| Recommendation — Maintain identity records and remove entitlements when they are no longer justified. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential lifecycle management underpins safe offboarding. |
| Recommendation — Remove access and credentials promptly when they are no longer needed. | ||
Practitioner Guidance
Decision rule: If the credential still maps to an active, owned, and approved workload, rotate it. If the workload is retired, the integration is replaced, or the relationship has ended, revoke it and validate that no fallback path remains.
What to verify: Confirm the identity owner, current dependency list, and distribution points before choosing the action. If you cannot prove continued business need, do not keep the credential alive by default.
Practitioner takeaway: Rotation manages exposure during continuity; revocation ends trust during offboarding. When the use case is gone, preserving the secret usually preserves unnecessary risk.
Related resources from NHI Mgmt Group
- What is the difference between rotating a secret and revoking access?
- What is the difference between rotating secrets and governing non-human identities?
- What is the difference between governing AI agents as users and governing them as non-human identities?
- What is the difference between governing non-human identities and simply discovering them?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
