Key takeaways
- Credential rotation is the scheduled replacement of long-lived keys so a leaked or stale credential stops working within a bounded window.
- Match rotation intervals to blast radius: 30 days for root and management keys, 30-60 for production API keys, 90 for low-risk internal credentials.
- Automate rotation for machine-to-machine credentials via STS roles, Secrets Manager lambdas, or OIDC federation; track manual-only SaaS keys with expiry metadata and a named owner.
- Use dual-key overlap windows and verify every consumer with a cheap read call before deleting the old credential.
- Vaults store and sometimes rotate secrets, but none own the coordination layer of ownership, expiry dates, and deadline sign-off.
Credential rotation is the scheduled replacement of long-lived API keys, access keys, and tokens before they become stale or compromised. Your vault stores the secret value, but nothing answers who owns each key, when it expires, or whether anyone rotated it. This guide gives you a decision framework for mapping each workload type to a rotation method and interval, so you can commit to a 30/60/90-day policy instead of guessing.
What is credential rotation and why does it matter?
Credential rotation is replacing an existing credential (an AWS access key, a Stripe API key, a GitHub PAT) with a new one on a schedule, so a leaked or stale key stops working within a bounded window. If you already run a vault like AWS Secrets Manager, Vault, or Infisical, rotation is the operational layer on top: deciding who owns each credential, when it expires, and what happens at the deadline.
Rotation vs expiration vs revocation
Expiration is when a credential dies on its own; revocation kills it immediately; rotation replaces it before either happens. Long-lived IAM access keys never expire on their own, which is why AWS recommends regular rotation and supports two active keys per IAM user so you can swap without downtime (AWS IAM documentation on rotating access keys). Without a lifecycle layer, ownership and deadlines live in someone's head, and secrets sprawl follows.
That gap is what alternatives to manual credential rotation tracking addresses: metadata-only monitoring of expiry and ownership, without holding secret values.
How does AWS credential rotation work for IAM users, roles, and access keys?
AWS handles three credential types differently, and knowing which one you're dealing with determines your rotation method.
IAM users and access keys
IAM user access keys are long-lived and never expire on their own. AWS lets each user hold two keys so you can rotate one while the other stays active, but nothing enforces the swap. Someone has to create the new key, update every consumer, and delete the old one. AWS's own IAM best practice is to avoid these keys entirely in favor of roles, but most shops still have a handful for legacy integrations.
Roles and short-lived STS credentials
Assumed roles issue temporary credentials through STS that expire automatically, typically within minutes to hours. There is no rotation step: the SDK or tooling requests fresh credentials before expiry. This is why the standard advice is to move workloads to roles and let AWS handle expiry for you.
Secrets Manager automatic rotation
Secrets Manager can rotate supported secret types on a schedule using Lambda rotation functions, replacing the stored value without human hands. It covers RDS, some SaaS integrations, and custom secrets via a Lambda function you write. What it does not do is track the credentials that live outside it: the Stripe keys and GitHub tokens humans pasted into Postman collections, or the IAM access keys with no expiry date. For those, you need a separate inventory of what exists, who owns it, and when it lapses, which is the gap credential expiration reminder tools for IT teams fill (https://keyguardrail.com/blog/credential-expiration-reminder-tools-for-it-teams).
How often should you rotate each type of credential?
Match the interval to blast radius, not to a single policy for everything.
The 30/60/90-day rule of thumb
The common pattern: high-privilege and customer-facing credentials rotate every 30 days, standard service credentials every 60, and low-risk internal ones every 90. AWS Secrets Manager supports rotation for supported secret types, including IAM user access keys and RDS credentials, so at least part of this can run without human transport (AWS Secrets Manager documentation). Stripe and GitHub keys have no native rotation engine, so those deadlines need tracking and owners.
| Credential type | Suggested interval | Why |
|---|---|---|
| Root/management keys | 30 days | Highest blast radius |
| Production API keys (Stripe, GitHub) | 30–60 days | Customer money and code |
| CI/CD deploy keys | 60 days | Broad write access |
| Internal service creds | 90 days | Contained blast radius |
What the intervals actually buy you
Shorter windows shrink the usable lifetime of a leaked key, nothing more. An interval without a named owner and a deadline is a policy nobody executes. Inventory each key, assign an owner, and set the expiry date explicitly: the credential inventory template covers the fields you need.
When is automated rotation better than manual rotation?
Automated rotation wins whenever the credential is machine-to-machine: IAM roles with STS short-lived creds, database users wired into AWS Secrets Manager rotation, CI/CD tokens scoped to one pipeline. If no human ever reads the secret value, a human in the rotation loop is just a failure mode. The 30/60/90-day policy you write on paper only holds if the rotation happens on schedule, and humans miss schedules.
Where automation wins
Anything with a native rotation endpoint: Secrets Manager rotation lambdas for RDS, OIDC federation for GitHub Actions instead of long-lived AWS keys, Stripe restricted keys regenerated on a calendar trigger. The goal is that humans don't handle secrets at all, not that they handle them faster.
Where manual rotation is still the honest answer
Third-party SaaS keys without rotation APIs, vendor credentials tied to a portal login, anything a human must click to generate. Track those with expiry metadata and an owner instead of pretending they're automated. KeyGuardRail covers the tracking layer; it does not rotate secrets for you, so manual rotations still need an owner and a deadline.
Which rotation method fits each workload type?
Human credentials
Human access keys are the ones that leak through Postman collections and Slack threads, so treat them as the shortest-lived credentials you own. AWS IAM users should use short-lived sessions via STS instead of static access keys, with session durations you can configure down to 15 minutes or up to hours depending on your role trust policy (AWS STS documentation). Where a static key must exist, put it on a 30-day rotation with a named owner and a deadline, not a "when someone gets around to it" policy.
CI/CD and pipeline credentials
Pipelines are the easiest win: they run on a schedule, so they can fetch short-lived credentials on every job. Use OIDC federation or STS-assumed roles where your CI provider supports it, and reserve static keys for the few integrations that cannot federate. Those exceptions go on a 60-day rotation with the pipeline owner accountable.
Service-to-service credentials
Workloads talking to each other should use short-lived tokens issued at connection time, not shared secrets. External SaaS credentials like Stripe and GitHub tokens are the exception, since those providers control expiry, so track their deadlines and rotate on a 90-day cycle with a fallback plan for the swap.
The honest gap: KeyGuardRail monitors ownership, expiry, and rotation deadlines across all three workload types, but it does not rotate credentials for you. Vault, Infisical, and Doppler each handle some rotation natively; if you want execution, not coordination, start there. Our resources cover the coordination layer in detail.
How do you rotate credentials without breaking running workloads?
Dual-key overlap windows
Keep the old and new credentials valid at the same time. AWS supports two active access keys per IAM user, so create the second key, deploy it everywhere, then retire the first. For Stripe and GitHub, create the replacement key before the old one expires, since neither lets you "pause" a key in use. The overlap window is your rollback room: if the new key fails somewhere, the old one still works.
Verifying the new credential before killing the old one
Do not delete the old key on a schedule. Verify the new one first with a cheap read call against each consumer: an sts get-caller-identity for AWS, a minimal API request for Stripe and GitHub. Only after every consumer proves it can authenticate should you deactivate the old key, then delete it after a grace period.
The failure mode this prevents is real: a secret updated in Secrets Manager but never redeployed to the one service that reads it at boot. That service keeps the old credential in memory until its next restart, which may be weeks away. Track which consumers exist and when they last pulled the secret, so you know when it is safe to kill the old key.
How do you start a rotation program if you have never had one?
Step 1: inventory and assign owners
List every credential your teams hold: IAM user access keys, Stripe API keys, GitHub PATs, and the secrets sitting in Postman collections and laptops outside your vault. For each one, record an owner (a team, not a person), where it lives, and where it is used. NIST's SP 800-53 guidance on managing authenticator lifecycle is the reference point for what a defensible policy looks like: NIST SP 800-53. You will miss some keys on the first pass; that is expected, and the inventory is a living document.
Step 2: set deadlines and monitor
Apply the 30/60/90-day rule from the community: short-lived creds where possible, 90-day maximum for the rest, tighter for high-blast-radius keys like production Stripe. Assign each credential a deadline and a next-rotation date, then monitor against those dates. KeyGuardRail does this with metadata only: it tracks expiry, owner, and rotation status without ever holding the secret value, so your vault (Secrets Manager, Vault, Infisical) stays the system of record. Where it falls short: it will not rotate keys for you, so execution still depends on whoever owns each credential.
How do vaults and lifecycle monitoring tools compare on rotation?
Vaults handle the storage and, in some cases, the mechanics of rotation. HashiCorp Vault, Infisical, and Doppler can rotate credentials or hand you the plumbing to script it. AWS Secrets Manager can rotate secrets for supported services on a schedule. What none of them own is the coordination layer above the vault: which team owns each key, when it expires, whether the 30/60/90-day deadline was actually met, and who signed off.
KeyGuardRail does the opposite. It monitors credential lifecycle metadata (owner, expiry, rotation deadline) across AWS, Stripe, and GitHub without taking custody of the secret value. Your vault stays the vault; KeyGuardRail tells you what is expiring and who is on the hook.
Where KeyGuardRail falls short on purpose
It will not rotate anything for you, and it does not store secrets, so it cannot replace Secrets Manager, Vault, or Infisical. If you want rotation execution, pick a vault. If you want to know what expires next and who owns it, that is the gap it fills.
FAQ
Do IAM roles need rotation if they already use short-lived credentials?
No. STS credentials expire on their own, usually within minutes to hours, so there is nothing to rotate: the SDK requests fresh credentials before each expiry. Rotation applies to long-lived secrets like IAM user access keys, Stripe keys, and GitHub PATs. If a workload can assume a role, migrate it and drop the static key entirely.
What happens if I rotate an access key while a Lambda function is using it?
If the function reads the new secret from Secrets Manager on each invocation, nothing breaks. If it cached the old credential at cold start, it keeps authenticating with the stale value until the next restart, which could be weeks away. Use the dual-key overlap window: deploy the new key, verify every consumer, then retire the old one.
Is a 90-day rotation policy still acceptable, or should I go shorter?
Ninety days works for low-risk internal credentials with a contained blast radius. Go tighter for anything touching customer money or production code: 30 days for root and management keys, 30 to 60 for production Stripe and GitHub keys. An interval only matters if a named owner and a deadline are attached to each credential.
Can I rotate Stripe and GitHub API keys automatically like AWS Secrets Manager does?
Not natively. Secrets Manager rotates supported secret types, including RDS credentials and IAM user access keys, through Lambda rotation functions. Stripe and GitHub have no built-in rotation engine, so those deadlines need explicit tracking and a named owner. The practical workaround is creating a replacement key on a calendar trigger, then swapping consumers.
How do I find out who owns a key before I rotate it?
Build a credential inventory first: list every key, record an owning team rather than an individual, where the credential lives, and where each consumer uses it. Most shops discover keys nobody documented, so expect gaps on the first pass and treat the inventory as a living document you update with every rotation.