Replacing long-lived secrets with short-lived ones is a large risk reduction, but it is not the same as removing secrets, and teams that stop at ephemeral credentials often keep the stored bootstrap secret that an attacker actually wants. Ephemeral credentials are issued on demand with a short lease, usually by a broker the workload must first authenticate to. Secretless or identity-based access lets the platform vouch for the workload, so nothing is stored at all, yet a short-lived bearer token still exists at runtime. This guide covers the end-state decision, when short-lived secrets are enough and when to go further, and the trust each leaves behind, for architects setting targets for CI/CD, databases and agents.
Key takeaways
- Short-lived is about how long a leak lasts; secretless is about whether there is anything to leak at rest. They solve different halves of the problem, and most mature estates need both.
- Secretless never means credential-free. AWS STS still returns an access key, secret key and session token; a managed identity still receives a token. What disappears is the stored secret used to get them.
- Every pattern keeps a root of trust. Ephemeral issuance keeps a broker login secret (secret zero); identity-based access moves trust to the platform issuer, the metadata endpoint and the federation trust policy.
- The theft window is lifetime plus revocation reach. A 24 hour token that cannot be revoked individually can be worse than a 1 hour credential with a working revocation path.
- Go secretless where the platform can attest the workload; settle for ephemeral where it cannot. CI/CD and cloud workloads should end secretless; legacy databases, third-party APIs and many agent tools will stay on brokered, short-lived secrets for some time.
The short answer
Aim for identity-based access wherever the runtime platform can prove what a workload is: cloud compute, Kubernetes, CI/CD systems with OIDC, and SPIFFE-enabled services. Accept ephemeral issued secrets where the target only understands usernames, passwords or API keys, or where the workload runs somewhere with no trustworthy attestation. In both cases, shorten lifetimes, narrow audiences and test revocation, because a stolen runtime token is the residual risk either way. The Dynamic Secrets and Ephemeral Credentials Guide covers lease mechanics, and the Workload Identity Federation Guide covers federation set-up.
Four patterns, not two
| Pattern | What the workload holds at rest | What it holds at runtime | Who vouches for it | Example |
|---|---|---|---|---|
| Static secret | Long-lived password, key or token | The same secret | Nobody; possession is identity | API key in an environment variable |
| Ephemeral issued secret | A credential for the broker (token, AppRole secret, client secret) | Short-lived target credential with a lease | The broker, after the workload authenticates with its stored credential | Dynamic database user from a secrets broker |
| Identity-based (federated or platform-native) | Nothing | Platform-issued identity token, exchanged for a short-lived access token | The platform issuer (cloud, Kubernetes, CI system, SPIFFE) | CI job exchanging an OIDC token for cloud credentials; managed identity |
| Brokered injection | Nothing in the application | Nothing in the application; a proxy or sidecar adds the credential | The broker, which itself uses one of the patterns above | Database proxy or agent tool gateway that attaches credentials in transit |
"Secretless" in vendor language usually means pattern three or four. The important distinction is where the remaining credential lives and whether the application process can read it. In pattern four the application cannot leak what it never sees, but the broker becomes a high-value target, as the Secrets in Prompts vs Brokered Credential comparison explains for agents.
Is secretless really secretless?
No credential-free authentication exists between a workload and an API; something must be presented. The vendor documentation is precise about this. AWS documents that calling AssumeRoleWithWebIdentity "does not require the use of AWS security credentials", yet the response consists of "an access key ID, a secret access key, and a security token". Microsoft says of managed identities that "Credentials aren't even accessible to you" and that token acquisition "doesn't require any secrets", but the code still receives an Entra token that it presents to the target. Azure Database for PostgreSQL describes the Entra token as "your password for signing in".
The IETF WIMSE working group's Workload Identity Practices draft (draft-ietf-wimse-workload-identity-practices-08, intended status Informational, in IESG processing when checked on 14 November 2026) states the residual risk plainly: for bearer tokens, possession is sufficient to use them. It recommends proof of possession, short lifetimes and narrow audiences. Drafts change, so treat it as guidance.
So the honest definition is: secretless means no long-lived secret is stored, distributed or rotated by people or pipelines. Runtime tokens still exist, and the controls that limit their use, such as audience restriction, sender constraint and short lifetime, still matter.
Residual bootstrap trust: what each end state still relies on
The Secrets Zero Problem Guide covers delivery of bootstrap credentials in depth; this table compares what is left in each end state.
| End state | Residual root of trust | How it is attacked | Control |
|---|---|---|---|
| Ephemeral issued secret | The workload's credential for the broker, and the broker's own privileged credential on each target | Steal the broker login from a config file, CI variable or image (T1552.001); compromise the broker's root account on the database | Authenticate to the broker with platform identity, not a stored secret; rotate the broker's target root credential after set-up so only the broker knows it |
| Identity-based, cloud metadata | The instance or pod metadata endpoint and the role attached to the compute | Request forgery or code execution that reads credentials from the metadata API (T1552.005) | Session-protected metadata access, hop limits, blocking metadata from containers that do not need it, least-privilege roles |
| Identity-based, federation | The external issuer's signing keys and the trust policy conditions | Over-broad subject or audience conditions that accept tokens from other repositories, branches or tenants | Pin subject, audience and environment claims; pool per environment; avoid granting access to every identity in a pool |
| Identity-based, SPIFFE | The SPIRE server's signing keys and the selectors in registration entries | Loose selectors that give one identity to many workloads; compromise of the signing authority | Specific selectors; treat the SPIRE server as tier 0; prefer X.509-SVIDs for proof of possession |
| Brokered injection | The proxy's own identity and its credential store | Compromise of the proxy, or a caller that can make the proxy act for it | Authenticate callers to the proxy by workload identity; per-caller policy; log every injected call |
Two points follow. First, ephemeral issuance does not remove secret zero unless the broker login itself uses platform identity, which is why the strongest designs combine patterns: the workload authenticates to the broker with a platform token and receives a short-lived target credential. Second, identity-based access moves risk from a secret anyone can copy to a configuration few people review, the trust policy. Review it like a firewall rule; see the Workload Identity Federation Trust Review Checklist.
Token theft windows: lifetime plus revocation
A stolen runtime credential is the residual risk in every pattern, so compare patterns by how long a stolen credential works and whether you can stop it early. Lifetimes below are as documented by each vendor, checked in November 2026; platforms are listed alphabetically.
| Credential | Documented lifetime | Early revocation | Theft window note |
|---|---|---|---|
AWS STS credentials from AssumeRoleWithWebIdentity | 900 seconds minimum, 3,600 default, up to the role's maximum session (1 to 12 hours) | Revoke active sessions denies every session of the role issued before a time, using aws:TokenIssueTime; no per-credential revocation is described | Set short session durations on high-impact roles; revocation affects all current users of the role |
| Amazon RDS IAM database authentication token | 15 minutes | Remove the IAM permission or the database user | The token is used to open a connection; AWS notes CloudWatch and CloudTrail do not log IAM authentication, so plan database-side logging |
| Azure Database for PostgreSQL Entra tokens | User tokens up to 1 hour; system-assigned managed identity tokens up to 24 hours | A deleted Entra user can sign in until the token expires unless also removed from the database | Identity-based but long-lived: remove the database role as part of revocation |
| GitHub Actions OIDC to a cloud provider | The cloud issues a short-lived access token valid for a single job | Cloud-side session revocation for the role | Pin trust to repository, environment and workflow claims so a stolen token works only where intended |
| Secrets broker dynamic database user (HashiCorp Vault example) | Default TTL 1 hour, maximum 24 hours, unless the role sets other values | Lease revocation deletes the database user | Per-consumer credentials make the leaked instance identifiable |
The lesson from this table is that "secretless" is not automatically "shorter". A system-assigned managed identity token valid for up to 24 hours has a longer theft window than a 15 minute RDS token or a 1 hour dynamic database user. Decide target lifetimes per use, and treat revocation reach as part of the design. For cloud credentials stolen from runtime, the Capital One Breach 2019 is the reference case: the role's temporary credentials came from the instance metadata service, and the over-broad role decided the damage.
Sender-constrained tokens narrow the window further. RFC 9449 (DPoP, Standards Track, September 2023) binds OAuth access and refresh tokens to a key the client proves it holds, which defeats replay of a leaked token elsewhere. It does not help if the attacker runs code inside the client, which the RFC states directly. X.509-SVIDs used for mutual TLS give the same proof-of-possession property for service-to-service calls, which is why the SPIFFE project recommends them over JWT-SVIDs whenever possible.
Where each fits: CI/CD, databases and agents
CI/CD pipelines
End state: identity-based. GitHub documents that with OIDC "you can configure the OIDC trust on your cloud provider" instead of duplicating cloud credentials as repository secrets, and the cloud checks the token's subject and other claims against the role's conditions. The residual risks are trust conditions that are too broad and code running inside the job: the tj-actions/changed-files Compromise 2025 showed a compromised action reading secrets from runner memory and printing them to logs. Federation removes stored secrets from that blast radius, but a token minted inside a compromised job is still usable for its lifetime, so keep high-impact deployment roles behind protected environments. See the GitHub Actions OIDC Federation Hardening Guide.
Databases
End state: identity-based where the engine supports it, ephemeral elsewhere. Amazon RDS supports IAM authentication for MariaDB, MySQL and PostgreSQL with 15 minute tokens and no stored password; AWS notes it needs 300 to 1,000 MiB extra memory on the instance. Azure Database for PostgreSQL accepts Entra tokens and can be set to Entra authentication only, which removes the password path entirely. Engines or versions without token authentication stay on dynamic users from a broker, with the broker authenticating by platform identity. Per-service connection pools keep attribution. See the Database Credential and Access Security Guide.
AI agents and tool calls
End state: brokered, with identity-based access to the broker. Agents call many third-party APIs that only accept API keys or OAuth tokens, so full secretless access is rarely possible end to end. The practical target is that the agent process holds no secrets: it authenticates to a tool gateway or credential broker with its workload identity, and the broker attaches short-lived, narrowly scoped credentials per call. This also keeps credentials out of model context, where prompt injection can extract them. See the Agent Identity and Access Guide.
Legacy applications and SaaS integrations
End state: ephemeral, often for years. Applications that read a password once at start-up, and SaaS APIs with static keys, cannot consume identity tokens. Use managed rotation or dynamic credentials, deliver them through an agent or sidecar, and put the remaining static keys behind a broker. The Short-Lived Credentials Migration Guide for Legacy Applications covers adapter patterns.
Decision guidance
| Question | If yes | If no |
|---|---|---|
| Can the runtime platform attest the workload (cloud compute, Kubernetes, CI OIDC, SPIFFE)? | Identity-based access is available; make it the target | Ephemeral issued secrets, with the strongest available broker login |
| Does the target accept tokens from your identity provider or cloud IAM? | Direct identity-based access, no broker needed | Broker or proxy that exchanges identity for a target-specific credential |
| Must you attribute each action to one instance? | Per-instance credentials: dynamic users, per-job tokens, SPIFFE IDs | Shared roles may be acceptable for low-impact reads |
| Is replay of a stolen token a serious threat (internet-facing, high privilege)? | Add proof of possession: mTLS with X.509-SVIDs or DPoP where supported | Short lifetime and narrow audience may be enough |
| Can you revoke one credential without disrupting all users? | Longer lifetimes are tolerable | Keep lifetimes short, because revocation is coarse |
Small organisations with mostly cloud-hosted workloads can often skip a separate secrets broker: managed identities, cloud workload identity federation and CI OIDC cover the common cases, leaving a small vault for third-party API keys. Large estates usually run all four patterns at once and need an inventory that records, per workload, which pattern it uses and what its root of trust is.
Migration path
- Inventory by pattern. For each workload, record the credential type, where it is stored, lifetime, and the target's supported authentication methods. Long-lived secrets with platform-attestable workloads are the first candidates.
- Remove secret zero from the broker first. Switch broker authentication from stored tokens or client secrets to platform identity (cloud IAM, Kubernetes, CI OIDC). This turns existing ephemeral issuance into a chain with no stored secret.
- Move CI/CD to federation. Replace cloud keys in pipeline variables with OIDC trust, pinned to repository, environment and workflow. Test in a non-production account, then delete the old keys rather than leaving them as fallback.
- Move cloud workloads to native identity. Managed identities, workload identity on Kubernetes and attached roles replace stored keys; restrict metadata access at the same time.
- Convert databases engine by engine. Enable token authentication where supported, run password and token paths in parallel for one release, then disable password authentication. Keep dynamic users for the rest.
- Front the remainder with a broker. Third-party API keys and agent tool credentials move behind a gateway so applications stop holding them.
- Tighten lifetimes and test revocation. Lower session durations on high-impact roles, rehearse role-wide revocation, and add proof of possession where clients support it.
Rollback: keep the old credential disabled, not deleted, for a short agreed period after each cut-over, then delete it. Never leave a static key active "just in case".
Worked scenario
A payments company runs 300 services on Kubernetes in one cloud, deploys through a hosted CI system, uses a secrets broker for database users, and is piloting an AI support agent that calls a ticketing SaaS and an internal refunds API.
- Starting point: the broker issues 1 hour dynamic database users, but each service authenticates to the broker with a long-lived token stored as a Kubernetes secret. CI holds cloud access keys in pipeline variables.
- Step 1: broker login moves to Kubernetes service account identity. Database credentials stay ephemeral, but no stored broker token remains, so secret zero is gone.
- Step 2: CI moves to OIDC federation with roles pinned to the main branch and protected production environment; the access keys are disabled and then deleted.
- Step 3: the two PostgreSQL clusters that support cloud IAM tokens move to token authentication with password authentication turned off; the older MySQL cluster keeps dynamic users.
- Step 4: the agent authenticates to a tool gateway with its workload identity. The gateway holds the ticketing SaaS key and mints short-lived tokens for the refunds API, scoped per conversation.
- Result: no service stores a secret at rest; the remaining stored secrets are the SaaS key in the gateway and the broker's database root credentials, both owned, monitored and rotated.
Detection and measurement
- Stored secret count: number of long-lived secrets in vaults, CI variables and Kubernetes secrets, trending down per quarter.
- Pattern coverage: share of workloads on identity-based access, ephemeral issuance and static secrets, reported separately.
- Broker login method: share of broker authentications using platform identity rather than stored tokens; target 100 percent for workloads on attestable platforms.
- Median credential lifetime for high-impact roles and database access.
- Trust policy breadth: number of federation trusts with wildcard subjects, missing audience checks or pool-wide grants; target zero.
- Revocation drill time: minutes from decision to effective revocation of a role or broker lease in an exercise.
Signals to alert on: use of a federated role from an unexpected repository, branch or issuer; metadata endpoint access from processes or containers that should not call it; tokens used from network locations unrelated to the workload (T1550.001); and any new long-lived key created for a workload already on identity-based access. AWS notes RDS IAM authentication is not logged in CloudWatch or CloudTrail, so database-side connection logging is required there. Response steps are in the Workload Identity Compromise Response Playbook.
Common failure patterns
- Ephemeral credentials behind a static key. Dynamic database users issued to anyone holding a long-lived broker token; the token is the real secret.
- Fallback keys kept after federation. The old cloud key stays in CI "for emergencies" and is the one that leaks.
- Wildcard trust conditions. A federation trust that accepts any branch or repository in an organisation, or a pool-wide grant, so a pull request job can assume a production role.
- Assuming secretless means short. Managed identity or user tokens with lifetimes of hours, with revocation that relies on deleting a user who can keep signing in until expiry.
- Metadata left open. Identity-based compute with an over-privileged role and unrestricted metadata access, so one request forgery yields live credentials.
- Agents holding raw keys. Tool credentials placed in agent configuration or context instead of behind a broker.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-5 Authenticator Management; IA-5(7) No Embedded Unencrypted Static Authenticators; IA-5(13) Expiration of Cached Authenticators | Removing stored secrets and limiting how long runtime credentials stay valid |
| NIST SP 800-53 Rev. 5 | IA-9 Service Identification and Authentication; SC-23 Session Authenticity; SC-12 Cryptographic Key Establishment and Management | Workload identity, sender-constrained sessions and signing key protection for issuers |
| NIST CSF 2.0 | PR.AA-01 identities and credentials for services managed; PR.AA-03 users, services and hardware authenticated | Programme-level outcomes for NHI credentials |
| OWASP Non-Human Identities Top 10 2025 | NHI7 Long-Lived Secrets | Recommends automated rotation, short-lived credentials, re-authentication for sensitive actions and least privilege |
| MITRE ATT&CK | T1552.001 Credentials In Files; T1552.005 Cloud Instance Metadata API; T1528 Steal Application Access Token; T1550.001 Application Access Token; T1078.004 Cloud Accounts | Stored-secret theft that secretless removes, and runtime token theft that remains |
Practitioner checklist
- Classify every workload credential as static, ephemeral issued, identity-based or brokered injection, and record its root of trust.
- Switch broker authentication to platform identity before converting more targets to dynamic credentials.
- Replace CI/CD cloud keys with OIDC federation pinned to repository, environment and workflow, then delete the keys.
- Restrict metadata endpoint access and scope roles attached to compute to what the workload needs.
- Enable token authentication on databases that support it and turn off password authentication once stable.
- Put agent tool credentials and third-party API keys behind a broker so application processes hold none.
- Set lifetimes per use from the documented ranges, shorter for high-impact roles, and rehearse role-wide revocation.
- Add proof of possession (mTLS with X.509-SVIDs, or DPoP) where replay of a stolen token is a material risk.
- Review federation trust policies and SPIFFE registration entries like firewall rules, with named owners.
Standards and references
- IETF: Workload Identity Practices (draft-ietf-wimse-workload-identity-practices)
- IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- OWASP: Non-Human Identities Top 10, NHI7:2025 Long-Lived Secrets
- SPIFFE: SPIFFE concepts
- AWS: AssumeRoleWithWebIdentity API reference
- AWS: IAM database authentication for MariaDB, MySQL and PostgreSQL
- Microsoft: Managed identities for Azure resources
- GitHub: OpenID Connect in GitHub Actions
Related NHI Mgmt Group resources: SPIFFE and SPIRE Guide, Workload Identity Federation vs Static Cloud Keys, JIT Access Guide, Cloud Workload Identity Guide.