API Key Rotation Best Practices: Cadence, Overlap, Leak Response (2026)

Most teams adopt key rotation as a calendar ritual: someone remembers every ninety days, generates a new key, pastes it into the deployment config, and hopes nothing was still using the old one. That version of rotation produces outages without meaningfully reducing risk. The useful version is narrower and more boring — a rehearsed procedure that shrinks the blast radius of a leak and can be run on demand rather than on a schedule.

What API key rotation is actually for

A key is a bearer credential: whoever holds it is you. Rotation does not prevent a leak. It bounds the window during which a leaked key remains useful, and — more importantly in practice — it gives you a tested way to invalidate a credential right now, on the day you need it.

That framing changes the priorities. A team that rotates religiously every quarter but takes six hours of panicked debugging to revoke a compromised key is in worse shape than a team that rotates rarely but can cut a key over in four minutes with confidence.

The three situations that actually demand rotation are: a credential that may have been exposed, a person or vendor losing their need for access, and a key whose scope was always too broad. Everything else is hygiene.

API key rotation best practices, in order of value

Scope keys so that rotation is cheap. One key per service, per environment, per integration. A single shared key across staging, production and three internal tools guarantees that rotating it is a cross-team event, which guarantees it will be postponed. Narrow keys can be rotated by one person without a meeting.

Rotate with overlap, never with a swap. The pattern that avoids downtime is: issue a new key while the old one still works, deploy the new key, verify real traffic is using it, then revoke the old one. The overlap window is where safety lives. A hard swap — revoke and replace in one step — is how rotation earns its reputation for causing incidents.

Verify before revoking, using traffic rather than intent. "I updated all the configs" is not evidence. Where the provider exposes per-key usage or last-used timestamps, watch the old key go quiet before you revoke it. If it will not go quiet, something you forgot is still holding it, and that is exactly what you wanted to discover before the revoke rather than after.

Set an expiry at creation time. A key with an expiry date rotates itself, and it converts a silent indefinite risk into a scheduled, visible one. Quotas serve the parallel purpose of capping what a leaked key can cost you before anyone notices — the mechanics of both are covered in setting quotas and expiry on API keys.

Keep keys out of the places they leak from. Not in source control, not in client-side code, not in a shared document, not in chat history. Environment variables injected at deploy time are an acceptable floor; a secret manager with access logging is better, mostly because it answers "who read this and when" during an incident.

Write down the rotation procedure before you need it. Which key, which systems consume it, who can issue a replacement, how to verify, how to roll back. An incident is a bad time to discover that only one person knows where the key is set.

Choosing a cadence

Fixed calendars are popular because they are auditable, not because ninety days is a meaningful number. A defensible approach is risk-based:

Immediately, on any suspicion of exposure — a key in a commit, a screenshot, a support ticket, a departed contractor's laptop.
On access change, when someone leaves the team or a vendor relationship ends. This is the rotation most often skipped and most often regretted.
On a slow schedule for everything else — quarterly or semi-annually is fine, provided the on-demand path is rehearsed. If your only rotation muscle is the annual one, the emergency rotation will not go well.

Rotating a well-scoped key more often than you can verify it is not a security improvement. It is a source of outages that trains people to dread the procedure.

When a key leaks

Revoke first, investigate second. The instinct to understand the scope before acting is backwards for bearer credentials — every minute of analysis is a minute the key still works.

Then: check usage on the leaked key for calls you did not make, rotate any key that shared its storage location, and look for the systemic cause. A key in a public commit is rarely a one-off; it usually means keys live somewhere the repository can see them.

Automating rotation without new failure modes

Automation is worth it once you have more keys than you can track by hand, but it introduces its own risk: the automation itself holds credentials with the power to issue and revoke. Keep it narrow, log every action it takes, and make sure a human can perform the same rotation manually — an automated system that is the only path to rotation becomes a single point of failure during exactly the incident where you need it most.

What the standards actually say about rotation cadence

The most common follow-up question here is what the standards require, and the answer tends to surprise people. NIST's Digital Identity Guidelines (SP 800-63B, §5.1.1.2) tell verifiers not to require secrets to be changed arbitrarily — periodically, for example — and to force a change only when there is evidence that the authenticator has been compromised. Expiry on a calendar is not the control that document leans on; evidence of compromise is.

The caveat matters, and it is the part most summaries drop. That clause is written about memorized secrets — passwords a person types — not about API keys. An API key is never memorized: it is copied into deployment configs, CI variables, container images and laptops, so it accumulates exposure in a way a password does not. What transfers is the reasoning rather than the letter of the rule. Rotation does its real work when an event triggers it, and a slow calendar rotation earns its keep as a backstop for the exposure you never found out about — not as the thing standing between an attacker and your account.

A defensible policy therefore reads as two lists rather than one number: hard triggers that force rotation the same day (a key in a commit, a key in a screenshot or support ticket, a vendor breach notice, someone leaving the team), and a background cadence for everything else, set at whatever interval you can actually verify without breaking deploys. If you are audited against a control that names a fixed interval, treat that interval as a compliance floor and keep the trigger list as the part doing the security work.

How rotation works on the providers people actually ask about

The overlap window described above is easy to write down and awkward to execute, because whether you get an overlap at all is decided by the provider, not by you. Four cases worth knowing, each documented by the vendor:

AWS IAM access keys. An IAM user can hold a maximum of two access keys at once, and that second slot is the overlap window. AWS documents the sequence: create the second key while the first is still active, update every application and tool, check whether the old key is still in use through its Last used information (aws iam get-access-key-last-used), then set the old key to Inactive rather than deleting it, run on the new key alone to confirm nothing breaks, and delete the old key only after that. Deactivating before deleting is what makes the step reversible — if a forgotten job fails, you switch the old key back to Active and fix the caller.
Azure AI services, including Azure OpenAI. Each resource ships with two keys for exactly this purpose, but the mechanics are the reverse of AWS: Microsoft's documentation states that once a key is regenerated, the older version of that key stops working immediately, so any client still holding it receives 401 errors. The supported procedure is therefore to alternate rather than overlap — move all traffic onto key 1, regenerate key 2, move traffic to key 2 and confirm it through logs, then regenerate key 1.
Stripe. Rotating a key in the Dashboard revokes it and issues a replacement, and you choose how long the old one survives: Stripe documents a grace period of up to seven days during which both the old and the new key work, while choosing Now deletes the old key outright. Stripe's own guidance matches the verify-before-revoking rule above — watch the request logs for the old key until its volume has been zero for hours or days before letting it expire, and roll the new key out to a subset of servers first.
Anthropic (Claude) API keys. Keys are created in the Console — the Admin API deliberately cannot create them — but it can read and change the ones you have. GET /v1/organizations/api_keys lists them with a status, an expires_at timestamp (null for a key with no expiry) and a scope object saying whether the key is bound to a single workspace or works across the organization; the update endpoint can flip a key's status to inactive. That status flip is your reversible deactivate step, and the scope field is what tells you in advance whether rotating one key disturbs one workspace or every workspace the account can reach.

Two patterns fall out of that list. Where the provider hands you a second slot or a grace period, the overlap is free and the only discipline required is the one above: verify with usage data before you revoke. Where it does not, the overlap has to live in your own infrastructure — a gateway or proxy layer that holds the upstream credential in one place, so individual applications never carry the key and a rotation becomes one change instead of a fleet-wide redeploy. If you are weighing that up, start with what an LLM API gateway does and when it is worth running one; the same layer is what makes a proxy endpoint for the Claude API a single place to swap credentials rather than a second copy of them.

One practical note for the verification step: a freshly rotated key that answers 401 is not automatically proof that rotation went wrong. The usual causes are mundane — the wrong environment's key, a key scoped to a different workspace, or the wrong key deactivated — and they are worth ruling out before rolling back. The common reasons an Anthropic API key stops working cover most of them, and every one of them is easier to diagnose while the old key is still sitting in the Inactive state rather than deleted.

Frequently asked questions

How often should API keys be rotated?

There is no universally correct interval, and the interval matters less than the trigger. Rotate immediately on suspected exposure and on access changes; for routine hygiene, a quarterly or semi-annual cadence is defensible provided keys are narrowly scoped and the procedure is rehearsed.

Does rotating a key prevent a breach?

No. It limits how long a leaked credential stays useful and gives you a practised way to revoke one. Prevention comes from scoping, storage, and keeping keys out of code and client-side bundles.

How do I rotate without downtime?

Use an overlap window: create the new key, deploy it, confirm through usage data that traffic has moved, then revoke the old key. Never revoke and replace in a single step.

What should I do the moment a key is exposed?

Revoke it before analysing. Then review its usage history for unfamiliar calls, rotate anything stored alongside it, and fix the path that let it escape.

Is an environment variable good enough for storing keys?

It is an acceptable baseline and far better than source control. A secret manager adds access logging and centralised revocation, which mostly pays off during an incident rather than day to day.

Should each service have its own key?

Yes, where the provider allows it. Per-service keys make rotation a local decision instead of a coordinated one, and they narrow what any single leak exposes.

Does NIST require rotating API keys every 90 days?

No. NIST SP 800-63B (§5.1.1.2) tells verifiers not to require secrets to be changed arbitrarily or periodically, and to force a change when there is evidence of compromise. That clause is written about memorized secrets rather than API keys, so it is not a licence never to rotate a key — but there is no NIST requirement setting ninety days for API keys. Ninety days is a convention; where it appears in your policy, treat it as an audit floor and put the effort into the trigger list and the rehearsed procedure.

Which providers give me an overlap window without extra work?

AWS IAM does, by allowing two access keys per user. Azure AI services and Azure OpenAI give each resource two keys, though regenerating one invalidates it immediately, so you alternate between them rather than overlap. Stripe offers a grace period of up to seven days when you rotate a key from the Dashboard. Where a provider only lets you create and revoke, the overlap has to come from your own gateway or secret-manager layer.

The short version

Rotation is not a calendar entry; it is a capability. Scope keys narrowly so rotating one is cheap, always rotate with an overlap window and verify with traffic before revoking, set expiry and quotas at creation, and keep credentials out of repositories and client code. Then rehearse the on-demand path — because the rotation that matters is the unplanned one.