Dynamic Secrets vs Leased Credentials: What's the Difference?

The same destination by two different roads

A standing database password is a liability. It sits in a config file or an environment variable, it rarely changes, and everyone who has ever touched the deploy has probably seen it. The better answer is to issue a short-lived login on demand: created when a workload needs it, removed when it is done.

Two features aim at that outcome. HashiCorp Vault calls it dynamic secrets. SikkerKey calls it leased credentials. Point either at your database and the result looks the same: an application asks for access, a fresh login appears with a limited lifetime, and it disappears on its own.

The destination is the same. How a machine is allowed to mint that login is not, and that is where leased credentials pull ahead.

How dynamic secrets work (HashiCorp Vault)

Vault's database secrets engine generates credentials on the fly. You configure it with an admin connection and a role describing what a generated user may do. When an application requests credentials, Vault connects to the database, creates a user with a random password, and hands it back.

Every dynamic secret carries a lease: a time to live, a maximum time to live, and the ability to renew or revoke. By default the lease is an hour and the maximum is a day. When it ends, Vault runs its revocation statements and drops the user.

Infisical offers the same feature under the same name, minting database users with a TTL and tearing them down on expiry.

Dynamic secrets shrink the standing password on the database side. What they leave in place is the credential a machine used to ask for one.

The token in the middle

Before an application can read a dynamic secret, it authenticates to the vault. Vault supports strong methods for this: AppRole, Kubernetes, cloud IAM. They all resolve to the same thing. In Vault's own words, "tokens are the core method for authentication," and every auth method "maps down to dynamically created tokens." The client gets a Vault token and presents it on every request afterward, in the X-Vault-Token header or as Authorization: Bearer <token>.

The managed service is no exception. HCP Vault Dedicated runs the cluster for you, but a machine still authenticates and receives a token to carry on each call. (HashiCorp's multi-tenant SaaS, HCP Vault Secrets, was retired in July 2026, leaving Dedicated as the managed option; both use the same token model.) Infisical is the same: a machine identity trades a Client ID and Client Secret for a short-lived access token, then sends that token on each call.

That token is a bearer credential. Whoever holds the string can use it. The dynamic secret it fetches might live an hour, but the token that fetches dynamic secrets is a reusable key in its own right: lift it from a log line, a crash dump, or an environment variable, and you can mint fresh database logins for as long as it stays valid. The strong authentication at the front door hands off to a copyable string for everything after it.

That is why token-based systems accumulate so much machinery: short token lifetimes, rotation, revocation lists, and the problem of delivering the first token to a machine safely, which Infisical calls the "secret zero" problem.

How leased credentials work (SikkerKey)

SikkerKey issues the same short-lived login without that token. You connect a database once, set a lease policy, and grant machines access to the leased secret. When a machine reads it, SikkerKey mints a fresh login in your database, scoped to the access you defined, and returns the full connection. When the lease ends, the login is removed. Each machine gets its own login.

The difference is how the machine proves it is allowed. When you enroll a machine, it generates an Ed25519 key pair locally. The private key never leaves the host; SikkerKey stores only the public key. Every read is a request the machine signs with that private key, carrying a timestamp and a one-time nonce. SikkerKey rebuilds the request it received and verifies the signature against the public key on file. The request that proves the machine's identity is the same request that mints the credential.

A bearer token and a private key both sit on disk, but they are not the same kind of thing. A token is built to be shared: minted to be copied to whatever needs it and presented on every call, so it collects in environment variables, config files, CI logs, and crash dumps, and any one copy works from anywhere until it expires. A machine's private key is an identity file that was never meant to be copied. It is generated on the host, stays there, and is never transmitted, not at enrollment and not on a single request. What crosses the network is a signature, and a captured one is spent the moment its nonce is used. Taking over a machine's identity means compromising that host and lifting its key file, not grabbing a string from a log line.

The lease policy

Both systems govern a minted credential's life with a lease, and the dials are similar. In SikkerKey the lease policy is set per leased secret:

• Credential lifetime: how long a login stays valid.
• Renew on read: extend a login while a machine keeps using it, so an active workload is not cut off mid-run.
• Hard maximum: force a brand-new login after a ceiling, even under constant use.
• Database-native expiry: give each login an expiry the database enforces on its own.
• Revoke when machine disabled: drop a machine's login the moment you turn the machine off.
• Mint fresh on every read: hand out a new login on every fetch.

Vault's lease is the same shape: a TTL, a maximum TTL, renewal, and revocation. The vocabulary matches because the goal matches. What a lease policy cannot change is the identity model underneath it, and that is where the two diverge.

What an attacker walks away with

The honest way to weigh two systems is to ask what a break-in yields.

With dynamic secrets, the prize is the token. It authenticates as the machine and mints database logins from anywhere, until it expires or someone notices and revokes it. The dynamic secret expiring does not help here; the token outlives any single credential it fetches.

With leased credentials there is no token to find where tokens leak, and a captured request is spent once its nonce is used. The one reusable artifact is the machine's private key, and reaching it means compromising that specific host and reading its identity file, a higher bar than lifting a string a token-based system has already copied into logs, environment variables, and config. Even then, what you hold is one machine's identity, revoked by disabling that machine, rather than a token that works from anywhere. To be exact about the claim: it concerns how machines authenticate. The database connection you configure is encrypted at rest and used only to mint and remove logins.

Leased credentials are the simpler answer

Removing the token removes what came with it. There is no token lifetime to tune, no rotation schedule, and no revocation race on the read path. Enrolling a machine uses a token, but its only job is registering the machine to your vault; no token reads a secret, and none is accepted on the path that serves them. To cut a machine off, you disable it and its signature stops being accepted.

Both features hand your applications the same thing: a short-lived database login, minted on demand, gone on expiry. Leased credentials get you there without putting a copyable credential on the path in between. That is the reason to use them.

Set one up from the leased credentials documentation, see the machine authentication page for the signed-request model in depth, and read traditional vs modern secrets management for the broader version of this argument.

FAQ

What's the difference between dynamic secrets and leased credentials? Both mint short-lived database logins on demand and revoke them automatically. The difference is authentication. A dynamic secret is fetched with a bearer token the machine holds after it authenticates; a leased credential is fetched with a request the machine signs using a private key that never leaves it, so nothing built for sharing is issued or transmitted.

Do I need HashiCorp Vault to issue short-lived database credentials? No. SikkerKey's leased credentials give you the same on-demand, self-expiring database logins, minted directly in your database and governed by a lease policy, without a bearer token on the retrieval path and without a Vault cluster behind them.

Are leased credentials the same as Vault dynamic secrets? They produce the same result, a temporary database login governed by a lease. They differ in how a machine proves it may mint one. Vault issues a client token presented on every request; SikkerKey verifies a fresh Ed25519 signature per request and keeps only the public key.

What is a lease policy? The rules that govern a minted credential's life: how long it lives, whether it renews while in use, an optional hard maximum, whether the database enforces the expiry itself, and whether it is revoked when its machine is disabled. In SikkerKey you set a lease policy per leased secret.

Does SikkerKey use bearer tokens? No. A machine authenticates by signing each request with its Ed25519 private key, and SikkerKey verifies the signature against the stored public key. The private key stays on its host as an identity file and is never sent, so there is no shared token to copy, leak, or replay.