Privacy
In 2025, the IBM Cost of a Data Breach Report found that compromised credentials caused 22% of all breaches — more than any other single attack vector. Among those, API keys and service account tokens that had never been rotated were the most common root cause. The average cost of a credential-based breach exceeded $4.76 million globally.
This guide explains why API key rotation is your cheapest, most effective defence against credential leaks, and walks through a practical six-step rotation workflow you can implement today — whether you manage one SaaS account or a multi-cloud infrastructure with hundreds of services. By the end, you will understand exactly which keys need rotation, how to automate the process, and what pitfalls to avoid.
Before automating rotation, make sure your infrastructure itself is secured. Read our guide to self-hosted password security for baseline credential hygiene across your entire stack, and also check our passkeys vs password managers comparison for how modern authentication reduces reliance on traditional keys.
API key rotation is the practice of periodically replacing an API key, access token, or service account credential with a new one and deactivating the old version. Think of it like changing the locks on your office doors every few months — even if someone copied a key six months ago, that key no longer opens anything. The window of vulnerability for any leaked credential shrinks from indefinite to the period between rotations.
The NIST SP 800-63B digital identity guidelines recommend regular credential rotation as a core security control. While NIST no longer mandates arbitrary 90-day password changes for human users (a major 2024 revision that reflected usability research), automated API credentials are a different category entirely. They lack human oversight, can be exfiltrated silently through CI/CD logs and error messages, and often have broad IAM permissions that compound the damage of a single leak.
Key types that need rotation:
Most security teams know they should rotate keys. The policy is in the handbook. The compliance checklist includes it. But in practice, manual rotation rarely happens consistently. The OWASP (Open Web Application Security Project) identifies three root causes:
1. Secret sprawl. The average organisation with more than 500 employees has over 30,000 active API keys and service tokens. Rotating them manually — identifying each one, tracking its dependencies, updating every consumer — would take weeks of dedicated engineering time. No team has that capacity.
2. Blind dependencies. Many teams do not know which services, cron jobs, or third-party integrations depend on which keys. Rotating a key can trigger a cascading production outage if an undocumented service relied on it. A dependency mapping exercise should always precede any rotation rollout.
3. No automated rollback. If a rotation breaks production and the old key is already deactivated, recovery requires generating a brand-new key and redeploying — extending the outage unnecessarily. A proper rotation workflow keeps the old credential available during a transition window.
This workflow works for any key type — AWS IAM access keys, GitHub fine-grained PATs, or SaaS integration tokens. It follows the generate-deploy-verify-deprecate-expire pattern recommended by the CISA (Cybersecurity and Infrastructure Security Agency) in its Zero Trust Maturity Model 2.0.
Create the replacement key before deactivating the old one. This ensures there is never a gap where your application has zero valid credentials:
# AWS CLI — create new access key while keeping old one active
aws iam create-access-key --user-name deploy-bot
# GitHub CLI — create a new fine-grained PAT (expires 90 days)
gh api -X POST /user/personal-access-tokens -f name="deploy-rotation-$(date +%Y%m%d)" -f expiration="90-days" --jq '.token'Update all consuming services with the new key. Use a secrets manager to push the update atomically — no hardcoding credentials into configuration files or environment-specific properties:
# AWS Secrets Manager — update the secret value
aws secretsmanager put-secret-value --secret-id my-service/api-key --secret-string "$NEW_KEY"Run a canary test that uses only the new key to confirm it authenticates correctly against all dependent API endpoints:
# Verify the new key authenticates to the endpoint
AWS_ACCESS_KEY_ID="$NEW_KEY_ID" AWS_SECRET_ACCESS_KEY="$NEW_KEY" aws sts get-caller-identityMark the old key as inactive but do not delete it. This gives you a 24-72 hour rollback window:
aws iam update-access-key --access-key-id "$OLD_KEY_ID" --status InactiveMonitor error rates and authentication failures during the deprecation window. Any service still depending on the old key will produce clear log signals — investigate those before proceeding.
After the monitoring window closes without issues, permanently delete the old credential:
aws iam delete-access-key --access-key-id "$OLD_KEY_ID"For organisations managing keys at scale, manual rotation is not operationally feasible. Use infrastructure-as-code tools to fully automate the generate-deploy-verify-deprecate-expire cycle. Terraform's aws_iam_access_key resource creates a new key on each apply when the pgp_key argument is used, enabling automatic rotation with every infrastructure deployment:
# Terraform — automatically rotate IAM access keys
resource "aws_iam_access_key" "rotate" {
user = aws_iam_user.deploy_bot.name
pgp_key = var.pgp_public_key
}Pair this with a scheduled GitHub Actions workflow that runs monthly, rotates secrets across all environments, runs a full integration test suite against the new credentials, and opens an incident ticket if any test fails. Store every rotation event — timestamp, operator identity, key identifier — in a dedicated S3 bucket with access logging enabled for compliance and audit review.
Do not wait for a scheduled rotation if any of the following occurs. Trigger immediate rotation within minutes, not days:
The ENISA (European Union Agency for Cybersecurity) recommends that emergency rotation workflows be fully automated with a one-click approval — no manual steps that take longer than five minutes should be required to initiate the process.
Rotating without a rollback plan. Always keep the old key in a deprecation window for 24-72 hours before final deletion. Tag it with a deletion date so automated cleanup scripts can verify the window has passed before removing it permanently.
Hardcoded keys in configuration files. If any repository stores API keys directly in config files or .env templates, rotation requires updating every file in every branch. Migrate to environment variables injected by a secrets manager or CI/CD platform before starting any rotation programme.
Ignoring platform rate limits. Some API providers strictly limit how many keys you can create. GitHub allows a maximum of 10 fine-grained personal access tokens per user. Check each platform's documentation before building automated rotation — exceeding the limit causes rotation to fail silently.
No audit trail. Without logging which team member rotated which key and when, post-breach investigation is severely hindered. Enable CloudTrail or equivalent audit logging on all credential management operations, and feed rotation events to your SIEM for correlation with security alerts.
Affiliate Disclosure: This post may contain affiliate links. If you purchase through these links, we may earn a small commission at no extra cost to you. Full disclosure.
How often should I rotate API keys?
Every 90 days for most cloud provider keys, matching industry standards. Emergency rotation triggers should override this schedule when a leak is suspected. The 90-day cadence balances security benefits against operational overhead.
Does rotating keys cause downtime?
Not if you follow the generate-deploy-verify-deprecate-expire pattern. The old key remains active during the verification and monitoring phases, so there is never a moment when no valid credential exists.
Can I automate rotation for all my SaaS tools?
Most modern platforms (GitHub, Stripe, Datadog, AWS) support API-driven key creation and rotation. If a provider supports two simultaneously active keys, full automation is possible through their API endpoints.
What is the difference between rotation and revocation?
Rotation is the planned, scheduled replacement of a credential before it becomes stale or is suspected compromised. Revocation is the emergency deactivation of a known compromised credential and happens immediately with no deprecation window.
Do short-lived tokens need rotation?
No — tokens with lifetimes measured in hours (AWS STS temporary credentials with a default 1-hour expiry) expire naturally. Focus rotation effort on long-lived keys: IAM user access keys, service account tokens, and SaaS integration API keys.