Rotation replaces a credential while preserving the identity or workflow, which reduces exposure but does not remove trust relationships. Revocation removes the ability to authenticate or authorize altogether. Good NHI governance needs both, because an unused secret and an unneeded identity are different risks.
Why This Matters for Security Teams
Rotating a secret and revoking access solve different problems, and confusing them creates blind spots in NHI governance. Rotation is about limiting how long a credential can be abused if it leaks; revocation is about ending a trust relationship that should no longer exist. In practice, teams often rotate passwords, API keys, or tokens because it is operationally familiar, then leave the underlying service account, pipeline, or integration alive with the same privileges. That leaves dormant access paths behind, especially in environments with weak inventory and poor offboarding discipline.
The scale of the issue is not theoretical: Ultimate Guide to NHIs reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. That means many teams can replace a secret but still fail to remove the identity that was using it. The difference matters because an old secret may expire, but an unnecessary identity can continue to authorise new activity indefinitely. Current guidance from OWASP Non-Human Identity Top 10 treats lifecycle control as a separate risk from credential hygiene. In practice, many security teams discover the gap only after an integration outage, a leaked token, or an audit uncovers access that should have been removed months earlier.
How It Works in Practice
Rotation changes the secret material. Revocation removes the authority behind it. A practical NHI control model usually treats them as paired but independent actions: rotate when exposure, age, or reuse risk increases; revoke when the workload, vendor, pipeline, or service account is no longer needed. The most effective programs tie both actions to inventory, ownership, and lifecycle state, which is why the NHI Lifecycle Management Guide and Guide to NHI Rotation Challenges both emphasise offboarding as much as rotation.
Operationally, the choice depends on the asset and the trust model:
- Rotate secrets when a credential is exposed, nearing expiry, or shared across multiple systems that still need the same identity.
- Revoke access when the identity is no longer required, ownership is unknown, or the integration has been decommissioned.
- Use short-lived credentials where possible so rotation becomes routine rather than emergency remediation.
- Pair revocation with entitlement cleanup in PAM, RBAC, and secrets managers so inactive identities cannot be silently reactivated.
The difference is especially clear in supply chain and CI/CD environments. A leaked token can be rotated, but a compromised pipeline service account may also need its role removed, its issuer disabled, and any downstream trust relationships reviewed. Guide to the Secret Sprawl Challenge shows why secret sprawl often hides these residual paths, while 52 NHI Breaches Analysis and the Ultimate Guide to NHIs — Static vs Dynamic Secrets reinforce that long-lived credentials magnify the cost of delayed action. These controls tend to break down when identity ownership is unclear across federated SaaS, legacy automation, and ad hoc service accounts because no one can prove what should be revoked versus merely reissued.
Common Variations and Edge Cases
Tighter rotation often increases operational overhead, requiring organisations to balance lower exposure against downtime, coordination cost, and application fragility. The tradeoff becomes sharper when a secret is embedded in code, cached in multiple services, or used by a vendor integration that cannot tolerate immediate change. In those cases, current guidance suggests using phased rotation first, then revocation once dependencies are confirmed.
There is no universal standard for this yet, but a useful rule is to ask two separate questions: can the current credential still be abused, and should the identity exist at all? If the answer to the first is yes, rotate. If the answer to the second is no, revoke. That distinction matters for service accounts, API keys, certificates, and delegated access, especially when one identity supports several workflows. The Top 10 NHI Issues and Shai Hulud npm malware campaign both show how secret compromise can coexist with persistent identity trust. For that reason, best practice is evolving toward continuous entitlement review, not just periodic password changes. In mature programmes, revocation is treated as lifecycle closure, while rotation is treated as ongoing hygiene.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Rotation and revocation are core NHI lifecycle controls. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management underpins revocation decisions. |
| NIST AI RMF | Governance and accountability help distinguish credential rotation from trust removal. |
Assign owners for NHI secrets and identities so lifecycle actions are approved, tracked, and auditable.
