An API key is a static credential. It's a string of characters that authenticates a caller to a service. It doesn't have an expiry date unless one was set explicitly when it was created. It doesn't show up in your IDP's user list. It doesn't participate in your SSO flows. It doesn't get deprovisioned when the person who created it leaves the company.
It just works, indefinitely, until someone explicitly revokes it.
The lifecycle problem
When a developer creates an API key for an integration they're building, a few things are true at creation time: they know what it's for, they have the context to set appropriate permissions, and they have a reason to keep track of it.
Twelve months later, when that developer has moved to a different team, or left the company, or just forgotten about the integration: the key still works. The integration might still be running. Or it might be abandoned. Either way, the key exists and is valid.
When the developer offboards, their SSO is disabled, their app accounts are deprovisioned, and their laptop is wiped. The API keys they created over their tenure, in Stripe, in AWS, in GitHub, in Twilio, in Datadog, in your internal services, are not touched. Nobody thought to include "audit API keys this person created" in the offboarding checklist, and nobody would know where to look if they did.
The aggregate risk at scale
At a 100-person engineering team, with an average tenure of 2.5 years and an average of 15 API keys created per engineer over their tenure: you have 1,500 API keys created over the company's history. How many are still active? How many are orphaned? How many have broader permissions than necessary? You probably don't know.
The keys with production access are the ones that matter. An API key with admin access to your cloud provider, write access to your primary database, or full access to your customer data platform is a high-value target. If it's orphaned, if nobody at the company currently knows it exists and tracks it, it's an unmonitored attack vector.
The minimum viable controls
API key governance doesn't require a sophisticated program. It requires three things:
Inventory. Build a list of every system that issues API keys (cloud providers, SaaS platforms, internal services). For each, export the active key list with creation date, creator, and last-used timestamp. This list is your starting point.
Owner attribution. Every key should have a named human or service owner. Keys without owners are immediate candidates for rotation or revocation. If the owner has left the company, rotate the key immediately and assign a new owner.
Expiry enforcement. Keys created going forward should have expiry dates. Most platforms support this; most teams don't configure it. The operational overhead of rotating keys on a schedule is real but manageable. The alternative, indefinite-lived keys with no rotation, is a compounding risk that grows with every engineer who creates one.
API keys aren't going away. They're the most practical way to authorize machine-to-machine access in the systems most companies run. But treating them as outside the governance model, as if they don't count because they're not in the IDP, is a gap that shows up reliably in incident investigations. Add them to the model now.