Short answer: every 90 days. That number comes from the CIS Benchmark, lines up with NIST cryptoperiods for authentication keys, and matches the default cadence at most cloud providers. For some keys you should go faster. For some you can stretch. Here's how to decide.
Ninety days is the figure cited by the CIS Google Cloud Foundations Benchmark (item 1.15) and the default cadence AWS, Google Cloud, and Azure all suggest for production API keys. It's short enough that a leaked key has limited useful life. It's long enough that the rotation work doesn't drown your team in operational overhead.
If you don't have a reason to deviate, set every API key to a 90-day rotation cycle and stop thinking about it. The decision fatigue of "should we do 60 or 90 or 180" is itself a security risk, because indecision turns into "we'll figure it out next quarter."
Some keys carry enough blast radius to justify the extra ops cost.
Stripe, PayPal, Braintree live keys. A leak means real money moves to attacker-controlled accounts. Rotate every 30 days.
Read or write access to customer data. The blast radius is your entire user table. 30 days, with a tight transition window.
OpenAI, Anthropic, Replicate keys with no hard spend cap. A scraper running for one day on your key can run up thousands. 30 to 45 days.
AWS root access keys (which should not exist at all), GitHub admin PATs, Cloudflare global API keys. 30 days at most.
A contractor laptop is lost. A wrong commit lands in a public fork. A screenshot in a support ticket shows part of the key. Rotate now, not next cycle.
PCI DSS, HIPAA, FedRAMP, and certain ISO 27001 control sets specify rotation cadences. Match the regulation, not the default.
Not every key needs the 30-day treatment. The cost of rotation is engineering time and deployment risk, and applying a max-frequency policy to low-risk keys is its own kind of sloppy: it dilutes attention and trains the team to treat all rotations as background noise.
Stretch the interval when the key's blast radius is genuinely small. A read-only token to a sandbox account. An internal service account with access only to non-sensitive metrics. A development environment key that touches no production data. For these, 6 months or even 12 months is reasonable. Document the longer cadence and the reasoning, so an auditor sees a deliberate decision rather than neglect.
A starting policy you can edit, not a hard rule.
| Key type | Rotation interval |
|---|---|
| Payment processor live keys (Stripe, PayPal) | 30 days |
| Production DB credentials | 30 days |
| Root and admin tokens | 30 days |
| High-spend AI API keys (OpenAI, Anthropic) | 30 to 45 days |
| Production application API keys (default) | 90 days |
| Third-party service keys (SendGrid, Twilio) | 90 days |
| Staging environment keys | 90 to 180 days |
| Sandbox / dev keys, no real data | 6 to 12 months |
Picking the interval is the easy part. Hitting it ninety days from now, when you're heads down on something else, is the part that fails on every team without a system. A calendar event is fine for the first rotation. By rotation three or four, it's been snoozed twice and dismissed once.
See the full guide on API key rotation reminders, or read through the rotation checklist for what to do once your reminder fires.
Set a 90-day reminder now. Get notified before the date, on the date, then follow-ups until you mark it done.
Done in seconds. No sign-up required.
It's the interval that maps to the CIS Benchmark, NIST SP 800-57 guidance, and the default for most cloud provider rotation policies. It's a balance between security (smaller exposure window) and operations (rotations cost engineering time). High-risk keys go faster, low-risk keys can stretch, but 90 days is the safe default.
AWS KMS rotates customer-managed keys every 365 days by default (configurable to as low as 90 days since 2022). IAM access keys must be rotated manually. AWS recommends every 90 days and surfaces non-compliance in the IAM credential report.
Yes for keys with broad scope or financial blast radius: production database credentials, Stripe live keys, OpenAI keys with high spend limits, root admin tokens. 30 days is reasonable for these. Also rotate immediately after any suspected exposure: a contractor laptop loss, a public Slack paste, a wrong commit pushed to a public fork.
Keys with narrow scope, low blast radius, and no financial cost can stretch to 6 or 12 months: read-only API tokens to a sandbox account, dev environment credentials with no production access, keys tied to non-sensitive third-party services. Document the longer interval and the reasoning so an auditor sees the deliberate choice.
NIST SP 800-57 Part 1 distinguishes cryptoperiods by key type rather than mandating a single number. The 90-day figure for API keys traces to operational baselines (CIS Benchmark item 1.15) and aligns with the lower end of NIST cryptoperiods for symmetric authentication keys. NIST also de-emphasized periodic password rotation in 800-63B, but that guidance does not extend to API keys.
List every key in a spreadsheet with the next rotation date, then set a single reminder per key on that date. A reminder that follows up until you mark it done beats a calendar event you can dismiss. You can also stagger keys so you're rotating one or two per month instead of ten in one week.
Free. No account. The interval is your call. The reminder is what makes sure you actually hit it.
Create API Key Rotation ReminderLast modified: