Skip to main content
Identity Authority
Category: Privileged Access

Vault Rotation

Also known as: Secret Rotation, Key Rotation, Automated Credential Rotation
Simply put

Vault rotation is the practice of automatically replacing stored secrets, such as encryption keys, passwords, or credentials, with fresh values on a regular schedule using a secrets management system. Doing this on a recurring basis limits how long any single secret remains valid, reducing the risk if one is ever exposed. Many cloud and secrets management platforms can perform this automatically at a configurable interval.

Formal definition

Vault rotation refers to the scheduled, and typically automated, generation and activation of new secret or cryptographic key material within a secrets management or key management system, superseding the prior active version. In key management contexts, rotation creates a new key version at a chosen frequency (for example, Azure Key Vault auto-rotation or OCI KMS Private Vault, which defaults to a 90-day interval that is customizable). In secrets management contexts, rotated secrets are created on a schedule by the system, with the newly generated credential stored as the active value; this is distinct from dynamic secrets, which are generated on demand and typically short-lived. Platforms such as HashiCorp Vault Enterprise provide centralized, scheduled credential rotation with configurable retry behavior. Exact behavior, supported secret types, versioning semantics, and whether prior versions remain usable during a grace period vary by vendor, engine, and configuration. This entry addresses rotation as a secrets/key lifecycle operation and does not cover runtime token validation or authorization enforcement.

Why it matters

Every stored secret is a standing liability: the longer a credential, encryption key, or password remains valid, the larger the window in which a compromised copy can be used by an attacker. Vault rotation directly shrinks that window by replacing secrets with fresh values on a recurring schedule, so that an exposed secret has a bounded useful lifetime rather than an indefinite one. This is a lifecycle control on the secret itself, and it complements, but does not replace, access controls and monitoring around how secrets are consumed.

Automation is central to why rotation is practical at scale. Manual rotation tends to be skipped, delayed, or done inconsistently, which leaves long-lived credentials in place precisely where they accumulate risk. Platforms that create a new key version at a configurable frequency (as in Azure Key Vault auto-rotation), or that generate and store a new active credential on a schedule (as with HashiCorp Vault's rotating secrets), remove much of that manual toil and make short secret lifetimes the default operating state rather than an exception.

Rotation intervals are typically a configuration decision that balances operational disruption against exposure risk. Some platforms ship with a default interval that can be customized, for example, OCI KMS Private Vault defaults to a 90-day rotation that operators can adjust. The right interval depends on the sensitivity of the protected resource, the blast radius of a compromise, and the tolerance of downstream consumers for credential changes, so there is no single correct value across deployments.

Who it's relevant to

IAM engineers and platform teams
Teams that operate secrets and key management systems are responsible for configuring rotation intervals, choosing between rotating and dynamic secrets, and validating that downstream consumers tolerate credential changes without outages. Understanding versioning behavior and any grace-period semantics for prior versions is essential to avoid breaking applications during a rotation event.
Security architects
Architects design where rotation fits within a broader secrets lifecycle strategy, deciding which secrets warrant scheduled rotation versus on-demand dynamic generation, and setting intervals proportional to the sensitivity and blast radius of each protected resource. They also weigh centralized rotation capabilities, such as those in enterprise vault products, against operational complexity.
Compliance officers and auditors
Rotation is frequently expected as a control for limiting the lifetime of credentials and keys. Compliance stakeholders care that rotation is automated, occurs at a defined and defensible interval, and produces evidence that secrets are being replaced on schedule rather than remaining valid indefinitely.
System administrators
Administrators managing applications and services that consume secrets need to ensure those consumers retrieve current credentials rather than caching stale ones, and to plan for retry behavior when rotation occurs. Depending on configuration, mishandled rotation can cause authentication failures for dependent systems, so operational readiness matters as much as the rotation policy itself.

Inside Vault Rotation

Secret Rotation
The process of replacing an existing secret (such as a database password, API key, or service account credential) stored in a vault with a new value, typically on a schedule or in response to an event. Rotation reduces the window during which a compromised secret remains valid.
Static vs. Dynamic Secrets
Static secrets are long-lived values rotated periodically, while dynamic secrets are generated on demand for a requesting principal and expire after a short lease. Dynamic secrets effectively rotate on every issuance, whereas static secret rotation is a distinct scheduled operation.
Lease and TTL
Many vault implementations attach a time-to-live or lease to issued secrets, after which the secret is revoked or must be renewed. Rotation policies typically interact with these TTL settings to determine how frequently new material is generated, depending on configuration.
Rotation Trigger
The condition that initiates rotation, which may be time-based (a fixed schedule), event-based (such as suspected compromise or personnel change), or on-demand (manual operator action). The chosen trigger depends on the deployment's risk posture.
Backend/Target Integration
The connection between the vault and the system that owns the credential (for example a database, cloud provider, or directory). Rotation usually requires the vault to update the credential at the target so the new value is accepted, which distinguishes rotation from mere re-encryption of stored data.
Encryption Key Rotation
A related but separate concern in which the cryptographic keys protecting vault-stored data are rotated. Rotating the master or data-encryption key changes how stored secrets are protected but is distinct from rotating the secret values themselves.
Audit and Versioning
Records of when a secret was rotated, by whom or what process, and which version is current. Versioning typically supports rollback and provides evidence for compliance and access reviews, depending on the vendor's capabilities.

Common questions

Answers to the questions practitioners most commonly ask about Vault Rotation.

Is vault rotation the same thing as rotating the vault's own master key or unseal keys?
No. Vault rotation, in the sense most relevant to secrets management, typically refers to rotating the secrets, credentials, or keys that a vault stores and manages on behalf of applications and services. Rotating the vault's own master key, root key, or unseal/recovery keys is a separate operation that re-keys or protects the vault system itself. Depending on the platform, these are governed by different commands, permissions, and operational procedures, and conflating them can lead to mistaken assumptions about what a given rotation actually protects.
Does rotating a secret in a vault automatically authenticate or re-authorize the clients that use it?
No. Rotation changes the credential material; it does not by itself verify who a client is (authentication) or determine what that client may do (authorization). Clients still authenticate to the vault and are authorized to retrieve the rotated secret according to the vault's access policies. Rotation and access control are distinct concerns: rotating a database password does not change which principals are permitted to read it, only the value they receive.
How do applications pick up a newly rotated secret without downtime?
This depends heavily on the vault platform and integration pattern. In many deployments applications retrieve secrets at runtime rather than caching them at startup, or they subscribe to change notifications, use a sidecar/agent that refreshes the value, or re-fetch on a defined interval or on authentication failure. To avoid disruption, many teams design for an overlap window where both the old and new credential remain valid until all consumers have picked up the new value. The exact mechanism varies by vendor and configuration.
What is the difference between scheduled rotation and on-demand rotation, and when is each used?
Scheduled rotation replaces a secret automatically on a defined interval or TTL, which is common for reducing the exposure window of long-lived credentials. On-demand rotation is triggered by an event such as a suspected compromise, an employee departure, or a compliance requirement. Many teams use both: a baseline schedule for routine hygiene and manual or event-driven rotation for incident response. The availability and granularity of each depend on the platform and the secret type.
How should dynamic secrets be handled compared to rotating static secrets?
Some vault platforms can generate short-lived dynamic secrets that are created on demand and expire automatically, which can reduce or eliminate the need to rotate a long-lived static credential because the credential is inherently ephemeral. Static secrets, by contrast, persist until explicitly rotated. Where dynamic secrets are supported for a given backend, they can shift the operational model from periodic rotation toward automatic expiry; where they are not, scheduled or on-demand rotation of static values remains the typical approach. Support varies by backend and vendor.
How can rotation be verified and audited after it runs?
Most vault platforms emit audit or log events recording rotation operations, which teams can review to confirm that a rotation occurred, when, and by which principal or automated process. Verification typically also includes confirming that consuming applications successfully authenticate with the new value and that the previous value has been invalidated once the overlap window closes. The specific audit fields, retention, and verification tooling depend on the platform and deployment configuration.

Common misconceptions

Vault rotation and encryption key rotation are the same thing.
They are distinct operations. Rotating a secret replaces the credential value delivered to consuming systems, while rotating an encryption key changes the cryptographic material protecting stored data. A vault may rotate encryption keys without changing any secret value, and vice versa; the two are governed by separate policies in most deployments.
Rotating a secret in the vault automatically makes the old secret unusable everywhere.
Rotation typically updates the credential at the vault and, where integrated, at the target system. Consumers still holding a cached old value, and any systems not updated by the rotation workflow, may continue to present the stale secret until it is revoked at the target or its lease expires. Effective invalidation depends on target integration and configuration.
Frequent rotation of static secrets is always superior to using dynamic secrets.
Neither approach is universally better. Dynamic, short-lived secrets reduce exposure by expiring on their own, while scheduled rotation of static secrets addresses long-lived credentials that cannot be issued on demand. The right choice depends on what the target system supports and the deployment's operational constraints.

Best practices

Prefer dynamic, short-lived secrets with leases where the target system supports on-demand generation, and reserve scheduled rotation for static credentials that cannot be issued dynamically.
Ensure rotation workflows update the credential at the target system, not just the stored value in the vault, so that old secrets are actually revoked or expired rather than left valid.
Keep secret rotation and encryption key rotation as separately managed policies, and document which one a given schedule or trigger governs to avoid conflating them.
Define event-based rotation triggers (such as suspected compromise or personnel changes) in addition to time-based schedules, matching trigger frequency to the risk posture of each secret.
Enable versioning and audit logging for rotated secrets to support rollback, incident investigation, and evidence for access reviews, depending on your vault's capabilities.
Test that consuming applications tolerate rotation, handling cached or in-flight old values gracefully, before enforcing aggressive rotation intervals in production.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide