Secret revocation is the process of invalidating exposed credentials so they can no longer be used. In practice, it must include every system that trusts the secret, because a credential that remains valid after disclosure is still an active attack path.
Expanded Definition
secret revocation is the operational act of making an exposed credential unusable across every trust point that can accept it. In NHI security, that usually means API keys, bearer tokens, certificates, signing keys, or service-account credentials, plus any downstream caches, brokers, CI/CD jobs, or federated services that still recognise the secret. This is broader than rotation: rotation creates a replacement, while revocation removes trust in the compromised value itself. The distinction matters because a secret can remain dangerous even after a team has issued a new one.
Industry usage is still evolving for adjacent terms such as invalidation, deactivation, and quarantine, but the governing principle is the same: once disclosure is suspected, the old credential must no longer authenticate anywhere. Guidance from the OWASP Non-Human Identity Top 10 aligns closely with this model because exposed secrets are only contained when every acceptance path is removed, not just the source record. The most common misapplication is treating revocation as a single-system change, which occurs when teams delete the secret from a vault but leave caches, replicas, or integrations still trusting it.
Examples and Use Cases
Implementing secret revocation rigorously often introduces service-disruption risk, requiring organisations to weigh faster containment against the operational cost of breaking live integrations.
- A GitHub token is exposed in a public repository, and the security team revokes it in the source system, then verifies no build runners, deployment scripts, or third-party apps still accept it.
- A compromised API key used by a service account is invalidated while a replacement key is issued, as described in NHIMG’s Guide to the Secret Sprawl Challenge, because scattered copies often outlive the original leak.
- An mTLS certificate is revoked after misuse is detected, and relying services are forced to check the updated trust state rather than continuing to accept the old certificate chain.
- A CI/CD pipeline credential is pulled after a supply-chain compromise, similar to the patterns documented in the CI/CD pipeline exploitation case study, where pipeline secrets can be reused quickly if not invalidated everywhere.
- An OAuth refresh token is revoked after anomalous use, and the identity provider, resource server, and session layer are checked for stale trust.
For implementation detail, the OWASP Non-Human Identity Top 10 is useful because it treats exposed secrets as a lifecycle failure, not merely a storage problem.
Why It Matters in NHI Security
Secret revocation is a containment control, not a housekeeping task. When NHI credentials leak, attackers often move faster than the organisation can coordinate response, and every minute that a secret remains valid expands blast radius. NHIMG research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, which is a strong signal that revocation workflows are still too slow, too manual, or too narrowly scoped. That lag is especially dangerous in environments where service accounts, tokens, and automation credentials are reused across pipelines, cloud workloads, and third-party integrations.
Proper revocation also supports zero trust because trust must be continuously revalidated after disclosure, not assumed until the next scheduled rotation. The governance failure usually appears only after a compromise has already been confirmed, at which point secret revocation becomes operationally unavoidable to stop further abuse, prove containment, and restore confidence in connected systems.
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 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-02 | Covers improper secret management and exposed credential lifecycle failures. |
| NIST CSF 2.0 | PR.AC-1 | Access control must disable compromised credentials before they can be reused. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires continuously revalidating trust after credential compromise. |
Remove compromised secret access immediately and verify no dependent system still authenticates it.
