What is the difference between vaulting a secret and revoking it?

Vaulting stores and manages the secret in a controlled system, while revocation invalidates the credential so it can no longer be used. Vaulting improves governance and traceability. Revocation is a containment action. In practice, mature teams use vaulting to make rotation safer and use revocation only when the exposure can be cut off without unacceptable disruption.

Why This Matters for Security Teams

Vaulting and revocation solve different problems, and confusing them creates avoidable exposure. Vaulting is about controlled custody: storing secret in a system that can log access, enforce policy, support rotation, and reduce sprawl. Revocation is about cutting off use immediately, which is often the right response after compromise or misuse. The gap between the two matters because secrets are frequently duplicated, shared, and left active long after they should have expired. Entro Security reports that 62% of all secrets are duplicated and stored in multiple locations in The 2025 State of NHIs and Secrets in Cybersecurity, which means “just revoke it” is rarely a complete strategy on its own.

Practitioners also need to distinguish governance from containment. Vaulting helps teams answer who can retrieve a secret, when, and under what policy. Revocation answers whether that credential should still function at all. In mature programs, the two are linked to rotation workflows, lifecycle events, and incident response. Guidance in the Guide to the Secret Sprawl Challenge and the OWASP Non-Human Identity Top 10 both point to the same operational reality: unmanaged secrets are easier to lose, harder to trace, and slower to contain. In practice, many security teams discover this distinction only after a leaked credential is still live in multiple systems, rather than through intentional lifecycle design.

How It Works in Practice

Vaulting is a control plane decision. A secret is placed in a managed store, then accessed through policy, audit logging, approval, and often rotation automation. That makes vaulting especially useful for long-lived application credentials, shared service accounts, and secrets that must be retrieved by many workloads under controlled conditions. Revocation is a state change on the credential itself: the token, key, or certificate is invalidated so it can no longer authenticate. In incident response, revocation is the faster containment move; in steady state, vaulting is the safer operating model because it reduces direct human handling.

The operational rule is simple: vault first, revoke when exposure or trust is broken. Vaulting supports safer rotation because the old credential can be staged, replaced, and retired with audit evidence. Revocation should be used when compromise is suspected, when offboarding is complete, or when a secret should never have existed outside policy. The NHI Lifecycle Management Guide and Guide to NHI Rotation Challenges show why lifecycle automation matters: without it, rotation becomes manual, slow, and error-prone. That is consistent with the OWASP Non-Human Identity Top 10, which treats secret handling as a recurring identity-risk problem, not a one-time cleanup task.

• Use vaulting for custody, auditability, and controlled retrieval.
• Use revocation when a secret is exposed, misused, or no longer needed.
• Pair both with rotation so the old credential is retired cleanly.
• Prefer short-lived secrets where the workload can support them.

These controls tend to break down when secrets are embedded in CI/CD pipelines, copied into tickets, or reused across multiple applications because revocation cannot reliably reach every hidden copy.

Common Variations and Edge Cases

Tighter secret control often increases operational overhead, so organisations must balance security gain against deployment friction. That tradeoff is most visible in legacy environments, shared SaaS integrations, and build systems where hardcoded credentials are still common. In those cases, vaulting may be feasible but revocation can cause immediate service disruption if the dependency graph is poorly understood. Best practice is evolving, but current guidance suggests mapping dependencies before revoking anything that might still be in active use.

There are also cases where revocation is the wrong first move. If a secret is merely outdated but not exposed, rotation through a vault may be enough. If the secret has been found in source control, chat, or a ticketing system, revocation should usually happen before cleanup, because the exposure window already exists. Research into secret leakage in supply chains, including the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack, shows why exposed secrets should be treated as live liabilities, not just inventory items. For organisations trying to reduce sprawl, the Guide to the Secret Sprawl Challenge is the more realistic starting point than a simple “revoke everything” policy.

Current guidance suggests one more nuance: revocation is a security action, but vaulting is a governance model. Teams that separate the two clearly usually recover faster, rotate more safely, and avoid breaking services unnecessarily. Teams that do not usually discover the difference during an outage.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between rotating a secret and revoking access?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?