# What are dynamic secrets?

> Dynamic secrets are credentials a vault creates on request, with a lease, and revokes when it ends. How they work, what they require, and why Crunu has none.

URL: https://crunu.com/learn/dynamic-secrets
Language: en
Updated: 2026-10-30

Dynamic secrets are credentials that a secrets server generates at the moment a client asks for them, such as a database user created for one application instance, and that come with a lease after which the server revokes them, so that no long-lived shared password exists in the first place.

## How they work

HashiCorp Vault is the best-known example. Its database secrets engine "generates database credentials dynamically based on configured roles" ([HashiCorp](https://developer.hashicorp.com/vault/docs/secrets/databases)), and "all dynamic secrets in Vault are required to have a lease"; "when a lease is expired, Vault will automatically revoke that lease" ([HashiCorp](https://developer.hashicorp.com/vault/docs/concepts/lease)).

A typical flow:

1. An application authenticates to the vault.
2. It asks for credentials for a role, for example `payments-readonly`.
3. The vault logs in to the database with its own administrative credential, creates a new user with the role's permissions, and returns the username and password.
4. The application uses them, and renews the lease while it runs.
5. When the lease ends, the vault deletes the user.

## Why teams want them

- **No shared password.** Every instance has its own credentials, so a leak points to one consumer.
- **Short life.** A stolen credential stops working when its lease ends.
- **Revocation is a feature, not a project.** Revoking a lease removes the user.

The OWASP Secrets Management Cheat Sheet recommends them where possible: "Dynamic secrets should be used where possible to reduce the surface area of credential reuse" ([OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)).

## What they require

The same cheat sheet names the catch: to create dynamic secrets, "we usually require long-term static secrets to create the dynamic secrets themselves." The vault must hold a powerful credential for each system it issues accounts on, and must be able to use it unattended. That means the server holds usable keys and decrypts on its own, which is the [server-side](https://crunu.com/learn/server-side-encryption) model. Whoever controls the running vault controls the issuing credential.

They also work only for systems the vault has an integration for, such as the databases its plugins support. A key issued by a third-party service often can't be created on demand at all.

## Common mistakes

- **Long leases** that turn dynamic secrets back into long-lived ones.
- **Weak protection of the vault's own credential,** which is now the most valuable secret you have.
- **Expecting them everywhere.** Static secrets remain for anything the vault can't issue.

## Why Crunu has no dynamic secrets

**Crunu has no dynamic secrets, and won't add them.** Issuing credentials needs a server that holds a usable administrative credential and can decrypt without anyone present. Crunu's server is built so that it holds no key that decrypts values, at any point. Adding dynamic secrets would mean putting such a key on the server, which would undo the property the product is built around.

What Crunu offers instead is narrower: limits on access to the vault itself (leases that end after a period of inactivity for machines and service tokens, usage limits for service tokens, OIDC binding for CI), per-environment keys, and a reissue checklist when someone leaves. If you need dynamic database credentials, a server-side vault such as HashiCorp Vault is the right tool, and the two approaches can coexist. The trade-off is laid out in [who can decrypt your secrets?](https://crunu.com/guides/who-can-decrypt-your-secrets) and argued at length in [why blind-server vaults skip dynamic secrets](https://crunu.com/blog/why-blind-server-vaults-skip-dynamic-secrets).

## Sources

- [HashiCorp Vault: Database secrets engine](https://developer.hashicorp.com/vault/docs/secrets/databases), checked October 30, 2026.
- [HashiCorp Vault: Lease, renew, and revoke](https://developer.hashicorp.com/vault/docs/concepts/lease), checked October 30, 2026.
- [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html), checked October 30, 2026.