Secret Rotation vs Secret Elimination: Which Strategy Fits Each Credential

Rotating a secret shortens how long a leak is useful; eliminating it removes the thing that can leak, and most programmes still spend their effort on the first when the second is now available for many credential types. Rotation keeps a stored credential and replaces its value on a schedule or event. Elimination replaces the stored credential with an identity the platform proves at runtime, so nothing long-lived sits in a file, variable or vault entry. This guide compares the two as strategies: which credential types can be eliminated today, which must keep rotating, how each fails, and the order to migrate in. It is for platform, cloud security and identity teams who own non-human credentials. Rotation mechanics are in the Secrets Rotation Runbook Template; leased credentials are in Static vs Dynamic Secrets.

Where cloud platforms are named, they are listed alphabetically; order is not a ranking.

Key takeaways

• Elimination beats rotation wherever the target accepts a platform identity. Cloud APIs, managed databases, CI/CD publishing and in-cluster service calls can now authenticate without a stored secret.
• Rotation remains the strategy for credentials you do not control. Most third-party SaaS API keys, legacy databases, partner integrations and vendor appliances still issue static secrets.
• Elimination still leaves something to protect. Trust configuration, federation conditions and the identity that mints tokens become the new crown jewels.
• Rotation failures are outages; elimination failures are trust mistakes. The first breaks consumers that cached the old value; the second grants access to the wrong workload through loose federation conditions.
• Migrate by exposure, not by ease. Start with cloud provider keys and CI/CD credentials, then database passwords, and keep rotation for whatever remains.

The short answer

Eliminate when both ends can do it: the workload runs on a platform that can attest its identity (a cloud compute service, a Kubernetes pod, a CI runner with OIDC), and the target accepts that identity (a cloud API, a managed database with identity-based login, a package registry with trusted publishing). Rotate when either end cannot: the target only accepts a key or password, or the workload runs somewhere with no attestable identity. Do both during migration, because you will run old and new paths side by side for months. OWASP's NHI Top 10 reflects the same split: under NHI7 Long-Lived Secrets it recommends automated rotation and short-lived, automatically expiring credentials "where the platform supports them". See the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.

Side-by-side comparison

Credential type map: rotate or eliminate

This is the decision most teams need. "Eliminate" means a documented, generally available path exists; it does not mean every workload in your estate can use it yet.

For the per-type inventory that feeds this map see the API Key Management Guide and the Database Credential and Access Security Guide.

Database passwords: the biggest elimination opportunity

Database passwords are usually the longest-lived and most widely copied secrets in an estate, and all three major cloud providers now document identity-based login for their managed engines. Each needs application and configuration changes, which is why they stay on rotation by default.

• Amazon RDS: IAM database authentication for MariaDB, MySQL and PostgreSQL issues a signed token valid for 15 minutes, used only at connection time. AWS notes that standard password authentication keeps working alongside it, that granting rds_iam on PostgreSQL makes IAM take precedence for that user, that tokens are around 1 KB so drivers must not truncate them, and that the instance needs 300 to 1000 MiB of extra memory.
• Google Cloud SQL: IAM database authentication works in automatic mode, where the Cloud SQL Auth Proxy or a language connector requests and refreshes tokens, or manual mode with OAuth tokens valid for one hour. The cloudsql.iam_authentication flag must be set, read replicas need it separately, SSL is required and Google documents a quota of 12,000 logins per minute per instance.
• Microsoft Azure SQL: Microsoft Entra authentication supports system-assigned and user-assigned managed identities, created as database principals with CREATE USER ... FROM EXTERNAL PROVIDER. Microsoft Entra-only authentication can then disable SQL authentication entirely, including the SA account.

The pattern is the same on each: enable identity login, create the identity-mapped database user, move one application, then disable the password user. The last step is what turns rotation into elimination; leaving the password user active means you still have a secret to rotate.

Rotation: threat model, failure modes and controls

Threat model: a static secret is copied into code, CI variables, tickets or laptops and later found by an attacker through a repository, backup or infostealer. Rotation caps how long that copy works. It does nothing about copies taken minutes after a rotation.

Architecture in words: the secret lives in a store; a scheduled or event-driven function creates a new value at the target, updates the store, verifies, then retires the old value after an overlap window. Consumers fetch at runtime or reload on change.

• Failure mode, the rotation outage: a consumer cached the value at start-up and fails when the old one is revoked. The Secret Rotation Outage Troubleshooting Guide covers diagnosis.
• Failure mode, stuck legacy: a credential is marked "cannot rotate" because nobody knows every consumer, and it ages for years.
• Failure mode, rotation without revocation: the new value is issued but the old one is never disabled, so the leak window never closes.
• Failure mode, privileged rotator: the rotation function holds admin credentials to the target, becoming a higher-value secret than the one it rotates.
• Controls: dual-credential or alternating-user patterns, runtime fetch instead of baked-in values, verified revocation of the old value, secret age monitoring and leak scanning.

Elimination: threat model, failure modes and controls

Threat model: no stored secret means no leak of a long-lived credential, but an attacker who can run code as the workload, or who can satisfy the federation conditions from elsewhere, can mint tokens. Token theft from a running workload still works for the token's lifetime.

Architecture in words: the platform proves the workload's identity (instance metadata, a projected Kubernetes token, a CI OIDC token, a SPIFFE attestation), an identity service exchanges that proof for a short-lived credential scoped to the target, and the SDK or connector refreshes it before expiry. Kubernetes documents this for its own tokens: since v1.22 pods receive a short-lived, automatically rotating TokenRequest token, and the kubelet rotates it before expiry.

• Failure mode, loose trust conditions: a federation rule matches an issuer but not a specific repository, branch, namespace or service account, so other workloads from the same issuer qualify.
• Failure mode, the password user left behind: identity login is enabled but the old password account remains active and unrotated.
• Failure mode, hidden bootstrap secret: the app authenticates with a stored private key to get its short-lived tokens; that key is the real secret and still needs rotation. See the Secrets Zero Problem Guide.
• Failure mode, identity provider as single point of failure: token service or metadata outages stop every workload at once, where rotation failures affect one secret.
• Controls: precise subject and audience conditions, audience checks on every token, removal of fallback passwords, issuance logging and alerting on unexpected subjects, and resilience planning for the identity service.

Decision criteria and trade-offs

• Choose elimination when: the target supports identity-based login or federation, the workload runs on an attestable platform, and you control both the code and the target configuration.
• Choose rotation when: a third party issues the credential, the target only accepts a static key, or the change would require rewriting an application you cannot modify.
• Choose dynamic secrets as the middle path when: the target cannot federate but a broker can create per-workload credentials with a lease, such as self-managed databases.
• Trade-off, outage profile: rotation fails one secret at a time; elimination concentrates risk in the identity service, which needs high availability.
• Trade-off, engineering cost: rotation is mostly an operations change; elimination needs application changes (SDKs, connectors, drivers that accept large tokens).
• Small against large organisations: a small team on one cloud can often eliminate most workload keys in a quarter using native managed identities; a large estate will run rotation for legacy and third-party credentials for years and should measure the eliminated share as a programme metric.

Migration order

1. Inventory and classify: list every non-human credential with type, owner, target, consumers and age. Mark each with the default strategy from the credential type map. See How to measure secret age and rotation coverage for the measurement side.
2. Eliminate cloud provider keys first: they usually carry the widest permissions and are the most targeted. Move in-cloud workloads to attached identities, then external callers to federation.
3. Eliminate CI/CD and publishing credentials: switch pipelines to OIDC federation and registries to trusted publishing; see the GitHub Actions OIDC Federation Hardening Guide.
4. Replace legacy Kubernetes token Secrets: move consumers to projected tokens with explicit audiences.
5. Move managed databases to identity login: pilot one application per engine, confirm connection pooling and token refresh, then disable the password user.
6. Put service-to-service traffic on workload certificates: introduce mTLS with short-lived certificates where a service mesh or SPIFFE deployment exists; see the SPIFFE and SPIRE Guide.
7. Automate rotation for what remains: third-party API keys, self-managed databases and bootstrap keys get automated rotation, leak scanning and owners.
8. Test and roll back: run old and new authentication in parallel, switch one consumer at a time, and keep the old credential disabled but recoverable for a defined window before deletion. Roll back by re-enabling it, not by recreating it.

Worked scenario

A retailer runs order services on Kubernetes in one cloud, a reporting job on-premises, a CI pipeline that deploys and publishes an internal library, a managed PostgreSQL database and a payment provider integration. The audit finds 14 cloud access keys, one shared database password used by six services, a registry token in CI variables and the payment provider's API key.

The team eliminates the cloud keys used by in-cluster services by binding Kubernetes service accounts to cloud identities, and replaces the CI keys with OIDC federation restricted to the main branch of the deploy repository. The registry token goes once trusted publishing is configured. The database moves to identity-based login service by service; the shared password user is disabled after the sixth service moves, ending the most painful rotation in the estate. The on-premises reporting job has no identity provider to federate from, so its key stays and moves to automated 30-day rotation with an alert on use from unexpected addresses. The payment provider only issues API keys, so that key stays on rotation with an overlap window, IP allow-listing where the provider offers it, and secret scanning. Result: 15 of 17 stored credentials eliminated, two on rotation, each with an owner.

Where identity fits

Elimination is an identity change, not a secrets change: each workload needs a distinct identity with an owner, least-privilege permissions and a lifecycle. Shared identities recreate the shared-secret problem in a new form, because one compromised workload can mint tokens for every service using that identity. Review federation trust policies in access reviews alongside human access. See SPIFFE vs Cloud-Native Workload Identity for choosing the identity layer.

Detection and measurement

• Eliminated share: percentage of non-human credentials replaced by platform identity, tracked by credential type.
• Residual secret age: median and maximum age of the secrets that remain, against the policy for each tier.
• Rotation success rate: percentage of rotations completed without consumer errors or rollback.
• Fallback credentials outstanding: count of password users or keys still active on targets that already support identity login.
• Federation hygiene: count of trust policies without subject, branch, namespace or audience conditions.
• Token anomalies: token issuance for unexpected subjects or from unexpected locations, reviewed weekly.

Attack techniques to monitor for map to ATT&CK T1552.001 Credentials In Files on the rotation side, T1528 Steal Application Access Token on the elimination side, and T1078.004 Cloud Accounts for both.

Common failure patterns

• Declaring victory at "rotated": rotation dashboards show green while the same credentials could have been eliminated, so the leak surface never shrinks.
• Leaving the password user active: identity login is enabled, but the old database user remains and nobody rotates it any more.
• Federating on issuer only: any repository or namespace from the same issuer can assume the role.
• Ignoring the bootstrap key: an app's private key or a broker's admin credential becomes the unrotated master secret.
• Big-bang cutover: every consumer moved at once with no parallel path, turning a migration into an outage.
• No owner for the remainder: credentials that must keep rotating are left unowned once the elimination project ends.

Framework mapping

Practitioner checklist

• Inventory every non-human credential and tag it rotate, eliminate or dynamic using the credential type map.
• Eliminate in-cloud workload keys with attached identities before anything else.
• Replace CI/CD and registry tokens with OIDC federation and trusted publishing.
• Restrict every federation trust by subject, audience and, for CI, repository and branch.
• Move managed databases to identity-based login and disable the password user afterwards.
• Replace legacy Kubernetes token Secrets with projected, audience-bound tokens.
• Automate rotation, with verified revocation, for third-party and self-managed credentials that remain.
• Find and protect bootstrap keys, then rotate them on a cryptoperiod.
• Report the eliminated share and residual secret age every quarter.

Standards and references

• OWASP: Non-Human Identities Top 10 2025, NHI7 Long-Lived Secrets
• Kubernetes: Service Accounts
• SPIFFE: Overview
• AWS: IAM database authentication for MariaDB, MySQL and PostgreSQL
• Google Cloud: Cloud SQL IAM database authentication
• Microsoft Learn: Microsoft Entra authentication for Azure SQL
• PyPI: Trusted Publishers
• GitHub Docs: Generating an installation access token for a GitHub App

Related NHI Mgmt Group resources: Secrets Management Guide · Workload Identity Federation vs Static Cloud Keys · Static vs Dynamic Secrets · Secret Rotation vs Revocation · Kubernetes Service Account Token Guide