Vault Leases: Renew and Revoke Dynamic Secrets (2026)

Vault leases are the ephemeral lifeblood of dynamic secrets, and understanding their lifecycle is key to using Vault effectively.

Let’s see what happens when Vault issues a dynamic secret. Here, we’re requesting a PostgreSQL database credential:

vault write pg/creds/user-read

And here’s a typical response:

Key                Value
---                -----
lease_id           pg/creds/user-read/qj6z5z9yYmE2fD3gH7k
lease_duration     768h
lease_renewable    true
password           aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789
username           user_qj6z5z9yYmE2fD3gH7k

Notice the lease_id and lease_duration. This isn’t just a password; it’s a leased password. The lease_id is Vault’s handle for this specific credential, and lease_duration is how long it’s valid for. After this duration, Vault will automatically revoke the secret.

The core problem dynamic secrets solve is eliminating the need to hardcode or manually manage credentials for services that need to authenticate to other services. Instead of a static password that lives forever (and thus needs to be rotated manually and often forgotten), Vault generates short-lived credentials on demand. This drastically reduces the attack surface.

Internally, when you request a dynamic secret, Vault’s secret engine for that service (like pg for PostgreSQL, mysql for MySQL, database for generic DBs, aws for AWS IAM users, etc.) performs the following:

1. Generates Credentials: It talks to the target service (e.g., the PostgreSQL database) and creates a new user/role with specific permissions.
2. Stores Lease Information: It records the generated credentials, their associated lease_id, and the lease_duration in its own internal storage.
3. Returns Credentials: It returns the generated credentials along with the lease_id and lease_duration to the client.

The lease_renewable flag is crucial. If true, it means the client can ask Vault to extend the life of this lease before it expires. This is the primary mechanism for managing dynamic secrets in applications.

Here’s how an application would typically use this:

1. Request Secret: The application requests a secret from Vault (e.g., vault read pg/creds/user-read).
2. Receive and Use: It receives the username, password, and lease_id. It uses these credentials to connect to the database.
3. Schedule Renewal: The application must schedule a renewal request to Vault for this lease_id before the lease_duration expires. It uses the lease_id to tell Vault which lease it wants to renew.
4. Renew or Re-request: If renewal is successful, Vault extends the lease_duration and returns a new lease_id (which may or may not be the same). The application updates its stored lease_id and continues using the same credentials (the password usually doesn’t change on renewal). If renewal fails, or if the application missed the window, it must go back to step 1 and request a brand-new secret.
5. Revoke (Optional/Automatic): When the application no longer needs the secret, or if it successfully obtained a new secret after a renewal, it can explicitly revoke the old lease_id using vault lease revoke <lease_id>. If it doesn’t, Vault will revoke it automatically when the lease expires.

The actual renewal process looks like this:

vault lease renew pg/creds/user-read/qj6z5z9yYmE2fD3gH7k

And the response might look like:

Key                Value
---                -----
lease_id           pg/creds/user-read/qj6z5z9yYmE2fD3gH7k
lease_duration     768h
lease_renewable    true
password           aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789
username           user_qj6z5z9yYmE2fD3gH7k

Notice the lease_id is the same, the password is the same, and the lease_duration has been extended. The application can continue using the existing credentials.

The most surprising thing about Vault leases is that renewing a lease doesn’t necessarily mean the credentials are re-generated or changed. For many secret engines, renewal simply extends the time that the existing, already-generated credential is valid. The underlying username and password remain the same. This is a critical distinction: your application doesn’t need to re-fetch the password on renewal, only the lease ID needs to be updated if Vault issues a new one.

The flip side of renewal is revocation. When a lease expires, Vault automatically revokes the associated secret. This is the default behavior and the primary security guarantee. However, you can also manually revoke a lease at any time:

vault lease revoke pg/creds/user-read/qj6z5z9yYmE2fD3gH7k

This immediately invalidates the username and password associated with that lease_id, preventing any further use.

The next concept you’ll grapple with is understanding how different secret engines manage lease renewal, especially when the underlying credentials do need to be rotated.