An exposed API key is a race against time: every minute it stays valid is a minute an attacker can use it. But rotating in a panic often causes the very outage you're trying to avoid. Here's a safe, repeatable sequence.
1. Contain first, rotate second
Before touching the key itself, check if the exposure is still live — a public GitHub repo, a build log, a Slack message. Remove or restrict access to the exposure immediately. This buys you time to rotate properly instead of rushing.
2. Map every consumer of the key
A key rarely lives in one place. Check:
- Application config and environment variables
- CI/CD pipeline secrets
- Infrastructure-as-code (Terraform, CloudFormation)
- Any secret manager or vault
- Third-party integrations that may have been given the same key
Rotating without this step is how teams break a payment integration they forgot existed.
3. Issue the replacement first
Generate the new key while the old one is still active. Deploy it to every consumer identified in step 2. Confirm each service is authenticating successfully with the new key before moving on.
4. Revoke the old key
Only after every consumer is confirmed on the new key should you revoke the old one. Watch error logs for a few minutes afterward — a service you missed in step 2 will start failing immediately.
5. Audit for misuse
Check the API provider's access logs for the period the key was exposed. Look for requests from unfamiliar IPs, unusual volume, or actions outside your normal usage pattern.
6. Prevent recurrence
If the key leaked from a git commit, it's still in your git history even after rotation. Combine key rotation with history scanning to make sure the old key value doesn't sit there indefinitely as a red flag for anyone scanning your public repo later.
Rotation isn't just an emergency procedure — teams that treat it as a routine, low-drama process (rotating keys on a schedule, not just after a leak) are far less likely to be caught off guard.