Most key rotation policies exist only on paper. A team writes "rotate every 90 days" into a security document, then forgets the keys until an audit or a leak forces a scramble. The real problem is not the policy, it is the schedule behind it: one calendar date applied to every key, regardless of what that key can reach. A workable key rotation schedule sorts keys by risk, automates the routine swaps, and reserves manual attention for the credentials that can actually hurt the business.
Why calendar-only key rotation falls apart
Picture a team that sets one reminder: rotate every API key on the first of the month. That reminder covers a live payment key, a read-only analytics token, and a forgotten webhook secret from a vendor nobody uses anymore. One date cannot serve three risk levels at once, so rotation either arrives late for the key that matters most, or arrives on schedule for a key that never needed it.
NIST frames this allowed lifetime as a key's cryptoperiod, which it defines as "the time span during which a specific key is authorized for use." Google Cloud takes a different approach and sets no fixed expiry on its API keys at all. Instead it tells teams to "periodically create new API keys, update your applications to use the new API keys, and delete the old keys."
Two major platforms, two different defaults. Neither one answers the scheduling question for you, which is exactly why the calendar alone cannot carry the policy.
Group your keys by what they can reach
A workable split starts with three tiers. Tier one covers keys that reach production or move money, such as a live payment key or a database credential with write access. Tier two covers keys with read-only or narrow scope, such as an analytics dashboard token. Tier three is anything unused, which should be deleted rather than rotated.
One security guide turns the first two tiers into concrete numbers, recommending teams "rotate API keys on a fixed schedule (90 days for sensitive, 365 for less)." That split only holds if the scope matches the tier. A scoped key that only works for specific operations from specific IPs limits the damage when leaked, while an unscoped key behaves like a root credential. A key with no boundary belongs in tier one, whatever list it currently sits on.
Shared keys complicate the picture further. When one consumer is compromised, all consumers lose access during rotation, since per-consumer keys add operational overhead but enable surgical revocation while shared keys make rotation an all-or-nothing event. That overhead is the price of being able to revoke one customer's access without taking down the rest. It is worth paying for anything in tier one. For tier three, it rarely is.
One more detail belongs in this section rather than a separate checklist: GitHub, AWS, Stripe, and most modern API platforms display the key once and never again. If your own key storage still shows the full value on every page load, that is a tier-one gap regardless of how often you rotate.
Automate the swap with a secrets manager
AWS Secrets Manager shows what automation looks like once the tiers are set. Rotation is the process of periodically updating a secret, which means you update the credentials in both the secret and the database or service, and Secrets Manager lets you set up automatic rotation for your secrets.
The service offers two paths depending on what you are rotating. For common database engines, managed rotation configures and manages the process for you and does not require a Lambda function. For anything else, rotation runs through a Lambda function that updates both the secret and the service it belongs to.
The practical difference matters for planning. Database credentials and a growing list of partner services rotate themselves on schedule, with no script to maintain. A custom API key from a smaller SaaS vendor usually needs the Lambda path, which means someone writes a small function once and tests it. That upfront work is the real cost of automation, and it pays for itself the first time a 90-day deadline would otherwise slip past a distracted engineer.
The real objection: rotation breaks things in production
The strongest argument against frequent rotation is operational, not theoretical. Swap a key badly and a service goes down at an inconvenient hour, which feels worse than the leak the rotation was meant to prevent. That fear is not misplaced: a rotation that changes a key everywhere at the same instant leaves no room for a misconfigured service to fail quietly before anyone notices.
The documented fix treats rotation as a cutover rather than a single flip of a switch. The practical answer is to treat rotation as a controlled cutover, not a simultaneous swap. The new key should be deployed everywhere first, traffic should be verified on it, and the old key should remain valid until the change has propagated.
That overlap window is what makes scheduled rotation safe to automate. It also explains why the Secrets Manager Lambda function described above runs a test step before the old secret is ever invalidated, not after.
When a key rotation schedule should bend
A schedule is a default, not a ceiling. One practitioner guide states the override plainly: if the key can authenticate to production or sign trusted material, rotate first and investigate second, but if the key is low impact and tightly scoped, a scheduled rotation window can be enough, provided the rollback path is already tested.
The cost of waiting is measurable, not hypothetical. GitHub reported that more than 39 million secrets were leaked across GitHub in 2024 alone. Separate research found that 74% of all leaked keys were still live and valid 31 days after being leaked, which means most teams rotate on a calendar date rather than on discovery, if they rotate the leaked key at all. Truffle Security's 2025 revocation program exists precisely because of that gap: it reports that it launched a free program to get leaked API keys revoked rather than just reported, after finding that 1.4 million of those keys were still live.
The lesson is not that scanning tools replace rotation. A leak alert, a departing contractor, or a vendor breach notice should always jump the queue ahead of whatever date sits on the calendar.
Accepting this argument changes the first hour after a security review, not just the calendar on the wall. Instead of one rotation date for every key, the list gets sorted by what each key can reach, with production credentials on a 90-day cycle and low-risk tokens on a longer one. Automation handles anything that fits a secrets manager's rotation function, while a short list of high-value keys stays on manual review with a tested rollback path.
When a leak alert arrives, it skips the schedule entirely, because the exposure clock started the moment the key left your control, not on the date your calendar had planned for it.
