in one lineAPI keys are long-lived credentials that grant access with no login and no MFA; rotation and an inventory bound the exposure.
the numbers
- 82:1machine identities per human one, nearly half privilegedCyberArk Identity Security Landscape, 2025
- 36%of breaches involved stolen credentialsVerizon DBIR, 2026
- 241 daysdays to identify and contain the average breachIBM Cost of a Data Breach, 2025
1what 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.
2why 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.
3what 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 it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedCash App / Block, 2022howThe person logs back in from home, weeks after leaving.what leavescustomer lists and reportswho ends up with itthe former employee and whoever they work for next
- it happenedColonial Pipeline, 2021howThe forgotten account's password turns up in a breach dump.what leavesa working way into the networkwho ends up with ita ransomware crew
- it happenedCloudflare, 2023howA key or token set up for old work keeps working after everyone forgets it.what leavesinternal systems and documentswho ends up with itwhoever tries the key first
4what 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.
on the record
your turn
what you can do about it
this week
Find your five oldest API keys and check who owns each one.
A key with no owner is the first one to rotate or remove.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →