API key rotation

what it is

An API key is a credential that grants programmatic access to a system or service. It's typically a long string generated by the platform and used by applications, scripts, or integrations to authenticate without a user login flow.

API keys grant access directly. There's no MFA prompt. There's no session that expires when a browser closes. The key is valid until it's revoked. In many environments, keys generated at setup are still active years later because nobody set a rotation schedule and nothing broke.

The same applies to service tokens, OAuth service credentials, and other long-lived programmatic access credentials. The unifying issue is that they persist, they don't require re-authentication, and they're often not tracked the way user accounts are.

why it accumulates

API keys are created to solve an immediate problem. A developer needs to connect two systems; they generate a key. An integration is configured; it gets a token. A one-off script accesses an API; a key is created and hardcoded.

After creation, the key is either stored somewhere (a config file, an environment variable, a secrets manager if the environment has one) or it's forgotten. In both cases, it runs as long as it's needed and then continues running after it isn't.

The absence of a rotation schedule is the main structural cause. Many platforms don't enforce key expiry by default. There's no prompt to renew, no alert when a key hasn't been rotated in 12 months. Keys that work don't cause visible problems, so nobody touches them.

The lack of an inventory compounds this. Teams may not know how many keys exist, what they're connected to, or who created them. When someone leaves, their keys typically aren't included in the offboarding process because nobody knows they exist.

what it costs you

An exposed API key provides access to whatever system it was generated for. If that key was committed to a public code repository, posted in a chat message, or stored in a shared location with weak access controls, anyone who found it has that access. The key itself doesn't know the difference between the authorized application and an unauthorized one.

Without an inventory, you can't respond quickly. An incident response for a leaked key starts with: which key was it, what did it have access to, and is it still valid? In environments where keys aren't tracked, each of those questions requires significant investigation time.

IBM's Cost of a Data Breach report (2025) puts the average time to identify and contain a breach at 241 days. A leaked API key with no inventory and no rotation policy can be in active use across that entire window.

There's also an offboarding gap. Keys created by former employees don't always appear in the offboarding process. The employee's IdP account is closed. Their API keys, still valid, are not.

what works

Everything starts from an inventory, because a key nobody knows about can't be rotated or revoked. Most cloud platforms and major SaaS tools expose an API key management page listing every active key with its creation date, last-used date, and the account that created it. Pulled together across platforms, that data answers the questions that matter in an incident: how many keys exist, which are actually in use, and who is responsible for each.

Last-used dates do most of the analytical work. A key untouched for months is a revocation candidate; if the system it served still functions, it is either using a different credential path or no longer running at all, and the key can usually be retired after a test. Creator names matter just as much. Keys generated by people who have since left the company sit outside every offboarding process that runs on directory accounts, and a high-privilege key with a departed owner is the most urgent thing this inventory can surface.

Rotation on a schedule keeps the inventory honest over time. Every active key carries a defined rotation period and a named owner, with high-privilege keys, anything holding write access or admin-level permissions, rotating more often than read-only ones. The schedule lives in documentation rather than in someone's memory, which is where the original keys got lost.

Short-lived tokens beat all of this where the platform supports them. A token that expires automatically bounds the exposure window by design, which is why mature environments treat long-lived static keys as the fallback rather than the default.