Why do secrets need rotation even when they are stored in a vault?

Vault storage reduces casual exposure, but it does not guarantee that every application is retrieving secrets from the vault at runtime. Secrets may still be copied into configs, logs, tickets, or code. Rotation is what invalidates the copied value, which is why vaulting and rotation are complementary controls, not substitutes.

Why This Matters for Security Teams

Secrets stored in a vault are safer than secrets left in source code or spreadsheets, but vaulting only changes where the secret lives, not how far it travels. A copied token can still persist in a config file, a build log, a support ticket, or an operator’s clipboard long after the original vault entry is protected. NHIMG research shows the scale of that exposure: 62% of all secrets are duplicated and stored in multiple locations, which makes lifecycle control just as important as central storage, as discussed in the Guide to the Secret Sprawl Challenge.

Rotation matters because it narrows the blast radius of every copy that escapes the vault. If a leaked value is still valid for months, the vault becomes only a control point for the source of truth, not for the compromised instances already in circulation. This is why current guidance aligns with OWASP Non-Human Identity Top 10: secret storage, exposure detection, and revocation need to work together, especially for non-human identities and machine-to-machine access. In practice, many security teams discover that vaulting was implemented, but rotation was never operationalised until a leak had already become a breach path.

How It Works in Practice

Rotation works by invalidating the old credential and issuing a replacement on a controlled schedule or trigger. That may sound simple, but the real requirement is application readiness: the workload must retrieve the secret at runtime, accept a new value without downtime, and fail closed if the old secret is revoked. For secrets used by services and automations, best practice is evolving toward short-lived credentials and workload identity rather than long-lived static values, which is why the Ultimate Guide to NHIs — Static vs Dynamic Secrets is so central to modern NHI design.

Operationally, teams usually need four controls working together:

• runtime retrieval from the vault, not hardcoded environment values
• automated expiry or TTL enforcement for secrets and tokens
• revocation hooks so the old secret stops working immediately after replacement
• continuous discovery for copies in repos, tickets, chat tools, and logs

That model fits the lifecycle view in the NHI Lifecycle Management Guide, because rotation is only one stage in a broader control chain that also includes issuance, monitoring, and retirement. It also matches the operational reality described in the Akeyless survey, where the average time to mitigate a leaked secret is 36 hours, which is far too long if the secret remains valid throughout that window. Where teams pair vaulting with policy-driven rotation and discovery, leaked values become far less useful; these controls tend to break down in legacy apps that cannot reload secrets without a restart because the rotation event and the application state are tightly coupled.

Common Variations and Edge Cases

Tighter rotation often increases operational overhead, requiring organisations to balance security gain against application compatibility and incident response load. That tradeoff is especially visible in environments with brittle legacy systems, third-party integrations, or long-running jobs that cache credentials in memory. Current guidance suggests that when an application cannot refresh secrets dynamically, rotation frequency should be paired with engineering work to remove the dependency rather than treated as a standalone fix.

There is also no universal standard for every secret type. Certificates, API keys, and session tokens behave differently, and some workloads need per-request or just-in-time credentials instead of periodic rotation alone. For teams managing high secret sprawl, the issue is not just the vault itself but duplicated trust paths, which is why NHIMG’s Guide to NHI Rotation Challenges helps separate technical blockers from process gaps. In breach scenarios like the Reviewdog GitHub Action supply chain attack, rotation after exposure only works if the organisation can find every copy fast enough to invalidate it. In practice, the hardest failures appear where secrets are both vaulted and still embedded in automation that was never designed for runtime replacement.

Related resources from NHI Mgmt Group

• When does secrets rotation actually reduce NHI risk?
• What is the difference between rotation and deprovisioning for NHIs?
• Why do secrets stay dangerous even when they are no longer actively used?
• What breaks when JWT key rotation is handled manually?