A revoked secret is a credential that has been intentionally invalidated and should no longer work. Revocation lowers exposure, but organisations still need visibility into when the change happened, which systems depended on it, and whether controls, audit trails, or downstream processes must be updated.
Expanded Definition
A revoked secret is a credential that has been intentionally invalidated so it should no longer authenticate, authorize, or unlock a protected workflow. In NHI security, revocation is not just removal from a vault or registry. It is a lifecycle event that should cut off practical use across applications, pipelines, and integrations, while preserving enough evidence to prove when the change occurred and what depended on it.
Definitions vary across vendors on how revocation is enforced. Some systems treat deletion as revocation, while others require explicit state changes, key rollover, or downstream policy updates to make the secret unusable in practice. That distinction matters because a secret can be “revoked” in an administrative console yet still remain valid in caches, replicas, CI/CD variables, or embedded config. NHI Management Group treats revocation as effective only when the credential can no longer be used by any authorised path, and when the event is observable in audit records. The OWASP Non-Human Identity Top 10 places secret handling and lifecycle control in direct scope for this reason. The most common misapplication is assuming a secret is dead after it is deleted from one vault, which occurs when dependent systems keep stale copies or cached tokens alive.
Examples and Use Cases
Implementing revocation rigorously often introduces operational friction, because the security benefit of immediate invalidation must be balanced against service continuity, rollback complexity, and dependency discovery.
- An API key used by a production service is revoked after suspected exposure, and the owning team uses NHI Lifecycle Management Guide practices to rotate adjacent credentials and verify all consumers switched successfully.
- A build token in a CI/CD system is revoked after a supply chain incident, with validation against the OWASP Non-Human Identity Top 10 guidance to ensure the old token cannot be reused in pipeline steps.
- A database secret is revoked during decommissioning, but the application team first confirms no cache, job runner, or sidecar still holds the credential, following the concerns outlined in Guide to the Secret Sprawl Challenge.
- A third-party integration key is invalidated after vendor offboarding, and the organisation verifies downstream alerting, retries, and audit trails reflect the revocation event.
Why It Matters in NHI Security
Revoked secrets are only effective when the surrounding identity fabric is visible and controlled. NHI failures often persist because organisations cannot tell where a credential was copied, which workload still trusts it, or whether the revocation reached every consumer. That is why revocation must be paired with inventory, dependency mapping, and post-revocation validation. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why expired or invalidated credentials so often remain operationally relevant longer than expected.
The security impact is immediate: an exposed secret that is not truly revoked can still enable lateral movement, pipeline abuse, or unauthorised service-to-service access. Practical revocation work often depends on guidance from the Ultimate Guide to NHIs — Static vs Dynamic Secrets and the patterns in Top 10 NHI Issues, because static credentials tend to outlive the systems that issued them. Organisations typically encounter the operational cost of revoked secrets only after an incident report reveals the old credential still worked somewhere, at which point revocation 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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) 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-02 | Covers secret lifecycle failures and the need to invalidate credentials across all consumers. |
| NIST CSF 2.0 | PR.AC-1 | Access enforcement depends on credentials being invalidated when no longer allowed. |
| NIST SP 800-63 | Digital identity guidance supports lifecycle invalidation of authenticators and secrets. | |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous validation, including removal of trust in revoked credentials. | |
| NIST AI RMF | AI risk management depends on controlling the credentials that let agents act. |
Use revocation procedures that reliably terminate authenticator use across all relying systems.
