Static vs dynamic secrets: a comparison

Should you generate a temporary password, store a token in a vault, or remove the need for a secret altogether? The answer depends on the target system, your infrastructure and your level of maturity. This guide compares three models, static secret, dynamic secret and federated identity, to help you choose the right one for your context. You will see that real progress is not always to make secrets dynamic, but sometimes to reduce the dependence on secrets when possible.

This page compares the models. The lesson why static secrets are a problem explains why the static model hurts, and machine identity and workload identity goes deep into federated identity; here you only get what you need to choose and to migrate.

What you will learn

• The three credential management models: static, dynamic, federated identity
• The benefits, limits and integration constraints of each approach
• The concrete use cases for each model
• The common pitfalls during a migration
• How to choose and migrate progressively

Prerequisites

This comparison assumes that you have read why static secrets are a problem, which explains the limits of persistent credentials, and that you know the secret lifecycle, from generation to destruction, the stages on which the three models differ. A credential here means any secret used to authenticate, such as a password, an API key or a token.

What are the three models?

The common reflex is to contrast "static secret" and "dynamic secret". In practice, you need to distinguish three models of credential management.

Static secret

A secret created in advance, stored somewhere, and reused over a long period.

# Example: a manually defined password
DB_PASSWORD="SuperSecretPassword123!"

Characteristics:

• Exists before it is used
• Stored in a file, a variable or a vault
• Long lifetime (weeks, months, years)
• Manual or scheduled rotation (replacing the secret by a new one at intervals)
• Often shared between several components

Sharing is the direct consequence of a long lifetime: an identifier that must last ends up copied into every component that needs it. Source · SVG

Esc to close, + and − to zoom, scroll to move around. 100 % − Fit + Close

Dynamic secret

A secret generated on demand, with a limited lifetime, and automatically revoked (cancelled) at expiry.

# Example: Vault generates a temporary PostgreSQL user
vault read database/creds/my-role
# Key                Value
# lease_id           database/creds/my-role/abc123
# lease_duration     1h
# username           v-root-my-role-xyz789
# password           A1b2C3d4E5f6G7h8

Characteristics:

• Does not exist before it is requested
• Generated at the moment of use
• Short lifetime (minutes, hours)
• Automatically revoked at expiry
• Unique per requester

One identifier per requester: the audit trail then points to a specific application, and revoking one does not cut off the others. Source · SVG

Esc to close, + and − to zoom, scroll to move around. 100 % − Fit + Close

Federated identity (workload identity)

No shared secret at all. The workload (the application or job that runs) proves its identity through a signed token, validated by the target system without any password exchange. The token comes from an identity provider (IdP), a service that vouches for who the workload is.

# Example: a GitHub Actions pipeline reaches AWS without any secret
# The runner obtains an OIDC token signed by GitHub
# (OIDC, OpenID Connect, is the standard for signed identity tokens)
# AWS validates the token and grants temporary access through STS
# (STS, the Security Token Service, issues temporary AWS credentials)

Characteristics:

• No secret to store, distribute or renew
• Relies on a chain of trust (IdP to target system)
• The workload proves "who it is" rather than "what it knows"
• Depends on the compatibility of the target system

Order of preference

When you need to secure an access, reason in this order:

1. No secret at all, if a federated identity is possible (OIDC, IRSA, workload identity)
2. Temporary credential, if the target system supports short-lived issuance
3. Static secret in a vault, if the system does not allow better
4. Clear-text secret outside a vault, to be avoided in all cases

How do the three models compare?

The eight criteria below are the ones that really weigh in an architecture choice. Two deserve particular attention: compatibility, which is eliminatory if the target system does not follow, and complexity, which determines whether your team will be able to run the solution day to day. The other rows describe the expected security gain.

Aspect	Static	Dynamic	Federated identity
Creation	Manual, in advance	Automatic, on demand	None (signed token)
Lifetime	Long (months/years)	Short (minutes/hours)	Very short (minutes)
Storage	Persistent	Temporary, often cached	None (token in memory)
Rotation	Manual, scheduled	Continuous, automatic	N/A (no rotation)
Revocation	Manual or scheduled	Automatic expiry, sometimes explicit revocation is useful	Token expiry
Attribution	Difficult (often shared)	Easy (unique per workload)	Easy (workload identity)
Complexity	Simple to set up	Central infrastructure required	IdP integration required
Compatibility	Universal	Depends on the target system	Depends on OIDC/mTLS support

Swipe to see more

Storage and revocation: important nuances

A dynamic secret can be cached by the application or end up in logs if the application is badly configured. It is only "ephemeral" if the application respects its lifecycle.

Likewise, the expiry of a secret does not guarantee that all access stops immediately: a connection already open (TCP pool, HTTP session) can outlive the credential that established it.

What are the three sub-families of temporary credentials?

The term "dynamic secret" actually covers distinct mechanisms. Confusing them leads to wrong architecture choices.

Sub-family	Mechanism	Example
Generated secret	The manager creates a temporary account on the target system	PostgreSQL user through Vault Database
Ephemeral token derived from an identity	The workload authenticates and obtains a short-lived signed token	STS AssumeRole, OIDC, JWT
Short certificate	A certificate authority (CA) signs a certificate with a limited lifetime	SSH certificate signed by Vault, short X.509 certificate through PKI

Swipe to see more

The distinction matters: a generated secret implies that the manager has high privileges on the target system (rights to create users). An ephemeral token relies on a pre-established trust relationship. A short certificate relies on a PKI (public key infrastructure, the set of services that issue and verify certificates).

How does a dynamic secret work?

The mechanism relies on a trusted intermediary: the secrets manager holds privileged access to the target system and uses it to create an account on demand, then delete it. The key notion is the lease, a fixed-term contract that ties the issued credential to its deletion deadline. The five steps below describe a full cycle, from request to revocation.

1. The application requests a secret

   The application authenticates to the secrets manager (for example Vault) and requests access to a resource (for example a database).

2. The manager generates the secret

   Vault connects to the database with admin credentials and creates a new user with a random password.

3. The secret is returned with a TTL

   The application receives the credentials and a lifetime, the TTL (time to live, for example 1 hour). A lease identifier makes it possible to renew or revoke the secret.

4. The application uses the secret

   The application connects to the database with these temporary credentials.

5. The secret expires and is revoked

   After 1 hour (or when the application releases the lease), Vault automatically deletes the user from the database.

The sequence diagram below takes up these five steps: follow the temporary user from its creation by Vault in PostgreSQL to its deletion when the lease expires.

Source · SVG

Esc to close, + and − to zoom, scroll to move around. 100 % − Fit + Close

What are the benefits of dynamic secrets?

The five benefits that follow all stem from the same property: the credential is unique and dated. This uniqueness changes the nature of the questions you can answer after an incident, since a suspicious access points directly to one requester and one moment. The short lifetime, for its part, mechanically limits what an attacker can do with an intercepted secret.

Reduced exploitation window

A dynamic secret only exists while it is being used. If an attacker captures it, they only have a few minutes or hours to exploit it, against months or years for a static secret.

Automatic revocation

No need to track where the secret is used. At expiry, the account is deleted on the target system. However, a connection already established can outlive the expiry of the credential: some systems (databases, brokers) keep TCP sessions open even after the user has been deleted. Check the behaviour of your target system.

Precise attribution

Each request generates a unique secret. If suspicious activity is detected, you know exactly which workload used this secret.

# Database logs
2026-03-16 10:00:00 - User v-app1-xyz789 connected
2026-03-16 10:00:05 - User v-app2-abc123 connected
2026-03-16 10:00:10 - User v-app1-xyz789: suspicious query detected
#                     ↑ We immediately know it is app1

Continuous rotation

Each issuance produces a fresh credential, which strongly reduces the average age of active accesses. No "forgotten annual rotation".

Natural least privilege

You can create roles with minimal permissions. Each workload receives exactly the rights it needs, for as long as it needs them.

What are the limits of dynamic secrets?

The cost of this model is not paid at set-up time, but in operation. Three obstacles come back systematically: the manager becomes a mandatory crossing point to start your applications, not every target system knows how to create temporary accounts, and above all, your applications must know how to renew a credential while running. This last point is the most often underestimated.

Critical central infrastructure

Dynamic secrets require a secrets manager able to authenticate to the target system, create and delete credentials on demand, and manage expiries.

The secrets manager becomes a critical component of the control plane (the layer that issues and governs access for everything else). Its availability, resilience and observability must be treated like those of a central infrastructure service.

Examples: HashiCorp Vault, AWS Secrets Manager (some features), HCP Vault Secrets.

Limited compatibility

Not every system allows dynamic creation of credentials.

System	Dynamic support
PostgreSQL	Yes, Vault database secrets engine
MySQL	Yes, Vault database secrets engine
AWS IAM	Yes, Vault AWS secrets engine or STS
Third-party API with a fixed key	No support
Legacy application	Often impossible

Swipe to see more

Application integration constraints

The compatibility of the target system is not enough. The client application must also be able to handle the lifecycle of the dynamic secret.

Constraint	Problem if not handled
In-memory renewal	The app tries to use an expired credential
Connection reopening	The connection pool keeps the old user
Lease management	No early renewal before expiry
TTL vs workload duration	A batch job lasts longer than the lease
Manager unavailability	The app cannot start or renew
SDK / middleware	Some libraries do not support credential refresh

Swipe to see more

Fallback strategy

If the secrets manager is unreachable at renewal time, the application must have a strategy: continue with the cached credential (if it is still valid), fail cleanly, or switch to degraded mode. This strategy must be defined before going to production.

Dependence on the control plane

The latency of obtaining the first secret delays the application startup. But the real issue is broader:

• Availability: if Vault or STS is unreachable, the application does not start
• Renewal during the lifetime: you must monitor leases and anticipate renewal before expiry
• Effect on connection pools: renewing a credential may require closing and reopening all connections
• Cache and anticipation: an early renewal (for example at 75% of the TTL) avoids interruptions

When does a static secret remain the right decision?

A static secret is not an anti-pattern by default. It remains the right choice in several concrete situations.

Situation	Why static fits
Third-party API with a fixed key	The provider supports neither automatic rotation nor federation
Master encryption key	The SOPS key, age key or KMS key is a foundational secret that cannot be dynamic (a KMS is a key management service that holds encryption keys)
Initial bootstrap	The first secret to access the vault itself (enrolment token, unseal key)
Air-gapped environment	No network access to a secrets manager
Legacy integration	Application that does not support credential refresh
Degraded recovery	Emergency credentials in case the secrets manager is down

Swipe to see more

Even in a modern architecture, there is almost always an initial secret or an initial chain of trust: machine identity, cloud role, enrolment token, recovery path. The goal is not to reach "absolute zero secrets", but to reduce the surface of static secrets as much as possible and to manage them rigorously (vault, scheduled rotation, audit).

Astuce

A well-managed static secret, stored in a vault, with scheduled rotation, access logging and an alert on abnormal use, is often preferable to a dynamic secret deployed in an infrastructure that is not ready to support it.

Dynamic secrets or federated identity?

When the target system supports it, federated identity is often preferable to dynamic secrets: it eliminates the need to create, distribute and revoke a credential.

Need	Recommended approach
Classic database	Dynamic secret (Vault Database)
CI/CD pipeline to cloud	OIDC / federated identity
Kubernetes service to AWS	IRSA / workload identity
Third-party API with a fixed key	Static secret in a vault
Short-lived admin SSH	Signed certificate (Vault SSH CA)
Internal service mesh (mTLS)	SPIFFE/SPIRE
Application to another internal application	mTLS with short certificates

Swipe to see more

For the cloud, dynamic credentials are useful, but when a native identity federation exists (GitHub OIDC to AWS, IRSA, GCP Workload Identity), it is often preferable to creating credentials, even temporary ones. IRSA (IAM Roles for Service Accounts) lets a Kubernetes pod take an AWS role without a stored key. mTLS (mutual TLS) is an encrypted connection where both sides present a certificate. SPIFFE/SPIRE is a standard and its implementation that give each workload a verifiable identity.

To go deeper into federated identity, see the guide Machine identity and workload identity.

How do you decide between the three models?

Go through the questions in order and stop at the first clear answer: the bold entry in the table shows the model it points to. The last row is a safeguard: if the application cannot refresh a credential, the dynamic model is ruled out whatever the previous answers.

Criterion	→ Static	→ Dynamic	→ Federated identity
Does the system accept OIDC or a cloud identity?	No	Sometimes	Yes
Does the app need a real credential (user/password)?	Yes	Yes	No
Does the target system create temporary accounts?	No	Yes	N/A
Is precise attribution important?	No	Yes	Yes
Is the environment ephemeral (K8s, serverless)?	No	Yes	Yes
Do you have Vault or equivalent?	No	Yes	Sometimes
Is it a third-party integration with a fixed key?	Yes	No	No
Does the app support credential refresh?	N/A	Required	N/A

Swipe to see more

What does it look like with Vault?

The two configurations that follow illustrate two of the three sub-families seen above: a generated secret on PostgreSQL, where Vault really creates an account, and an ephemeral token on AWS, where Vault only requests a token from STS. The difference shows in the privileges required on the target side: creating roles in the first case, assuming a role in the second.

These configurations are illustrations, not instructions to replay at this stage of the course. The Vault vocabulary (secrets engine, role, lease, policy) is taught in the French modules "Un coffre, et des accès scopés" (a vault, and scoped access) and "Des secrets qui expirent d'eux-mêmes" (secrets that expire by themselves). Read them to see what the vault does on each request, without trying to memorise the syntax.

Dynamic PostgreSQL credentials (generated secret)

This is the most mature use case for dynamic secrets: Vault creates a temporary user directly on the database.

Secrets engine configuration:

# Enable the database secrets engine
vault secrets enable database

# Configure the PostgreSQL connection
vault write database/config/my-postgresql \
    plugin_name=postgresql-database-plugin \
    allowed_roles="my-role" \
    connection_url="postgresql://{{username}}:{{password}}@postgres:5432/mydb?sslmode=disable" \
    username="vault_admin" \
    password="vault_admin_password"

# Create a role with minimal permissions
vault write database/roles/my-role \
    db_name=my-postgresql \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
        GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

Use by the application:

# Request credentials
vault read database/creds/my-role

# Result
Key                Value
---                -----
lease_id           database/creds/my-role/abc123...
lease_duration     1h
lease_renewable    true
password           A1b2C3d4E5f6G7h8
username           v-root-my-role-xyz789

AWS credentials (ephemeral token through STS)

For AWS, the most current model uses STS AssumeRole rather than creating temporary IAM users. STS issues an ephemeral token without creating an IAM account.

# Enable the AWS secrets engine
vault secrets enable aws

# Configure the root credentials
vault write aws/config/root \
    access_key=AKIAIOSFODNN7EXAMPLE \
    secret_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
    region=eu-west-1

# Create a role with assumed_role (recommended)
vault write aws/roles/my-role \
    credential_type=assumed_role \
    role_arns="arn:aws:iam::123456789012:role/my-app-role"

Use:

vault read aws/creds/my-role

# Result: temporary STS credentials
Key                Value
---                -----
lease_id           aws/creds/my-role/xyz789...
lease_duration     1h
access_key         ASIAXXXXXXXXXXXXXXXX
secret_key         xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
security_token     FwoGZXIvYXdzE...

IAM user vs STS

The example uses credential_type=assumed_role (STS), which is the recommended model. The iam_user type creates a real temporary IAM user, which is slower, consumes IAM quotas, and is only recommended for systems that do not support STS credentials.

When a native identity federation exists (GitHub OIDC to AWS, IRSA), it is preferable to Vault AWS: it removes the need to store root credentials in Vault.

How do you migrate progressively?

No need to change everything at once. Migrate progressively, starting with the most mature cases.

1. Inventory and classification

   List all your static secrets. Classify them by criticality and by compatibility with dynamic secrets or federated identity.

2. Set up observability

   Before migrating, check that you can observe: which workload requests what, which leases expire, which authentication failures occur, what latency is introduced. Without observability, a migration can silently degrade production.

3. Quick wins: databases

   Start with database credentials. This is the most mature use case with Vault, and the one that brings the most value (attribution, automatic revocation).

4. CI/CD: adopt OIDC

   Replace stored CI/CD tokens with OIDC federation. GitHub Actions and GitLab CI support this approach natively.

5. Cloud credentials

   Replace long-lived access keys with STS credentials or workload identity (IRSA, GCP WI, Azure MI).

6. Continuous evaluation

   For each new secret, ask yourself: "Can it be dynamic? Can it be replaced by a federated identity?"

What common pitfalls should you avoid?

These seven mistakes are found in most failed migrations. They share one trait: they cancel the intended benefit while keeping the added complexity. Writing a dynamic credential into a persistent file, for example, turns it into a static secret with a management infrastructure on top.

Pitfall	Consequence	Solution
Migrating all secrets "on principle"	Needless complexity, production incidents	Migrate in order of maturity and risk
TTLs too short without renewal handling	Connections cut in production	Renew at 75% of the TTL, test the behaviour
Vault with too many privileges	Compromising Vault means compromising everything	Partition policies, limit admin roles
Writing a dynamic credential to a file	The secret is no longer ephemeral	Inject in memory, mount a tmpfs volume (a volume held in RAM, never written to disk)
Injecting a secret as an environment variable	Visible in /proc/<pid>/environ and in logs	Prefer mounted files or sidecar injection
Confusing a dynamic secret with a federated token	Wrong architecture choice	Tell the three sub-families apart
Multiplying roles without governance	Uncontrolled proliferation	Name, document and audit regularly

Swipe to see more

When should you not migrate right away?

Migrating to dynamic secrets is not always the next step.

Situation	Why wait
Fragile legacy system	The risk of breaking production exceeds the security gain
No observability in place	You will not see the problems introduced by the migration
Manager without high availability	A single-node Vault is a single point of failure (SPOF) for all workloads
Application incompatible with refresh	The app crashes when the credential expires
Untrained team	Operators must understand leases, TTLs and renewals

Swipe to see more

In these cases, the priority is to secure the existing static secrets: vault, regular rotation, access logging, alerting. Then to prepare the infrastructure for the future migration.

Key points

• Not every secret is meant to become dynamic, the right choice depends on the target system and the maturity of the infrastructure
• When a federated identity exists, it is often preferable, it completely removes the need for a shared credential
• Dynamic secrets strongly reduce the exploitation window and improve the attribution of accesses
• They require reliable central infrastructure, the secrets manager becomes a critical component of the control plane
• Application compatibility is often the real limiting factor, not the target system, but the application's ability to handle refresh
• Expiry does not guarantee an immediate stop, sessions already open can outlive the credential that established them
• The migration must start with the most mature cases: databases, CI/CD, cloud credentials
• A well-managed static secret remains preferable to a dynamic secret deployed in an infrastructure that is not ready

Knowledge check

Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

4 questions

4 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →