A secret is any value that proves identity or grants access: a password, an API key, a cloud access key, a database credential, a token, or a certificate’s private key. Secret rotation is the practice of replacing a secret with a new one on a schedule or in response to an event. Secret revocation is the act of making an existing secret stop working immediately.
They sound similar, and they are often confused, but they answer different questions. Rotation asks “how do we make sure no secret stays valid forever?” Revocation asks “this secret is exposed, how do we make it useless right now?” A mature security practice needs both.
This guide is about what happens to a secret after it exists. It assumes you already know that secrets can leak. If you want the background on how and why they spread across code, chat, and pipelines, read what is secrets sprawl first. Here we focus on the lifecycle: how to replace secrets safely, how to kill leaked ones, and why the instinct to “just delete it” fails.
The core problem: a secret does not stop working when you stop looking at it
A secret is valid because the system that checks it says so. It is not valid because of where it is stored. This sounds obvious, but it explains almost every mistake teams make after a leak.
Imagine a developer commits an access key to a repository by accident, notices a few minutes later, and deletes the file in a new commit. The repository now looks clean. But:
- The key is still in the history. Version control keeps every past commit. Anyone who can read the history can read the key.
- Copies exist elsewhere. Forks, local clones, CI caches, pull request diffs, and archive services may all hold the old version.
- Automated scanners are fast. Bots watch public repositories for new secrets and may collect one within minutes of publication.
- The key still works. Nothing about deleting a file told the cloud provider to stop accepting the key.
So the secret is exposed, copied, and valid, and deleting it removed none of the risk. The only action that ends the risk is making the secret itself invalid. That is revocation. Deleting from the place it leaked is tidying, not remediation.
Key terms
- Secret rotation. Replacing a secret with a new value, then retiring the old one. Can be scheduled (every 90 days) or event-driven (after a leak or when an employee leaves).
- Secret revocation. Invalidating a secret so it can no longer be used. Takes effect at the system that validates it.
- Expiration. A secret that is built to stop working on its own after a set time. This is rotation by design.
- Regeneration. Generating a new value for the same secret slot. Often used as a synonym for rotation, but it may not retire the old value automatically.
- Exposure window. The time between when a secret becomes exposed and when it stops working. Shrinking this window is the goal of everything in this guide.
- Consumer. Any application, script, or person that uses a secret. You must know all of them before you can change the secret safely.
Why rotation matters even when nothing has leaked
Rotation is not only a reaction. It is a standing control, for several reasons.
- It limits the value of a quiet leak. Many leaks are never noticed. A secret taken from a backup, a log, or a compromised laptop may be used months later. If it has been rotated since, the stolen copy no longer works.
- It limits long-lived access. The longer a secret lives, the more places it has been copied to and the more people have seen it. Rotation resets that.
- It handles people leaving. Anyone who knew a shared secret takes that knowledge with them. Rotating on departure closes it.
- It is expected by auditors. Frameworks and customers ask for evidence that credentials are rotated and that access is revoked when no longer needed. See SOC 2 and PCI DSS.
- It builds the muscle. A team that rotates a secret every quarter can rotate it in an hour during an incident. A team that has never rotated it discovers, mid-crisis, that nobody knows where it is used.
That last point is the most valuable. Practised rotation is what makes emergency revocation fast. Many organizations delay revoking a leaked secret because they fear breaking something. Routine rotation removes that fear.
Rotation versus revocation: when each applies
| Situation | What you do | Why |
|---|---|---|
| Secret has reached its scheduled age | Rotate | Routine hygiene, no known exposure |
| Employee or contractor with knowledge of a secret leaves | Rotate | Remove their access |
| Secret was committed to code, pasted in chat, or printed in a log | Revoke first, then replace | The exposure window is open now |
| A vendor that stored your secret was breached | Revoke first, then replace | You cannot know who has it |
| Suspicious activity using a secret | Revoke, then investigate | Stop the abuse before analysing it |
In an active incident, the order is revoke, replace, then investigate. People often reverse this because they want to understand what happened first. Each hour spent investigating with the secret still valid is an hour the attacker can keep using it.
How rotation works without causing an outage
The fear of downtime is the main reason secrets never get rotated. There are well-established patterns that avoid it.
Pattern 1: Swap in place (simplest, has a gap)
You generate a new secret, update every consumer, and invalidate the old one. If a consumer is missed, or updates later than the swap, it fails during the gap. This is acceptable for secrets with one or two well-known consumers and a maintenance window. It is risky for anything widely shared.
Pattern 2: Overlap (two valid secrets at once)
Many systems allow two active secrets for the same identity. The process is:
- Create the new secret while the old one still works.
- Roll the new secret out to all consumers at your own pace.
- Confirm that nothing is using the old secret any more, using usage logs.
- Revoke the old secret.
There is no moment when a legitimate consumer has no valid secret. This is the safest pattern for access keys and API keys, and it is the one to prefer.
Pattern 3: Alternating users (for databases)
For database credentials, a secrets manager can maintain two database users and alternate between them. While one is in use, the other’s password is changed. Then consumers switch. AWS Secrets Manager describes this approach in its guide to rotating secrets. Azure Key Vault has a comparable rotation tutorial.
Pattern 4: Dynamic, short-lived credentials (best)
Instead of rotating a long-lived secret, issue a new one every time it is needed and let it expire in minutes or hours. The consumer asks for a credential, receives one that is valid briefly, and uses it. There is nothing long-lived to leak, and nothing to rotate on a schedule because rotation is built in. This is how cloud identities such as service principals with managed identities, and instance role credentials, work.
This pattern is the direction to move in. It converts rotation from a recurring chore into a property of the system.
A safe rotation procedure
Whether it is a scheduled rotation or an emergency, follow the same steps. The difference is speed.
- Find every consumer. Search code, configuration, pipelines, secret stores, documentation and chat. If you cannot find them all, use the provider’s usage logs to see who is still using the secret after you change it.
- Create the new secret. Give it the same or narrower permissions as the old one. A rotation is a good moment to reduce scope.
- Store it correctly. In a secrets manager, never in code or a config file.
- Deploy it to consumers. Roll it out and verify each consumer works.
- Revoke the old secret. Do not skip this. A new secret next to a still-valid old one is a second key to the same door.
- Verify. Check that the old secret is rejected and that nothing is failing.
- Record it. Note who rotated what and when, for audit.
Example: rotating and revoking an AWS access key
For an IAM user access key, the overlap pattern looks like this with the AWS CLI:
# 1. Create a second key while the first still works
aws iam create-access-key --user-name build-bot
# 2. Deploy the new key to every consumer, then check last-used time of the old key
aws iam get-access-key-last-used --access-key-id AKIAOLDKEYEXAMPLE
# 3. Make the old key inactive (reversible) to confirm nothing breaks
aws iam update-access-key --user-name build-bot \
--access-key-id AKIAOLDKEYEXAMPLE --status Inactive
# 4. After a safe period, delete it permanently
aws iam delete-access-key --user-name build-bot \
--access-key-id AKIAOLDKEYEXAMPLESetting a key to Inactive before deleting it is a useful safety step. If something breaks, you can set it back to Active in seconds. In a real emergency where the key is known to be exposed, skip straight to making it inactive, then work out the consumers.
What to do the moment a secret leaks
This is the incident runbook version. Keep it short enough to follow under stress.
- Revoke or deactivate the secret now. Do not wait to find out whether anyone used it.
- Issue a replacement and deploy it, using the overlap pattern if you can.
- Check usage back to the earliest possible date. Look at the provider’s logs from the time the secret was created, or at least from when it was first exposed. The question is whether it was used by anyone other than your systems.
- Look for persistence. Attackers who used a credential often create new credentials, roles, or users so access outlasts the revocation. Review recent identity and permission changes made by the compromised identity.
- Assess the scope. What could that secret reach? That is the blast radius, and it decides how far the investigation needs to go.
- Find the root cause. How did it leak? Fix that, or the next secret will leak the same way.
- Clean up copies. Remove it from code and history where practical, but remember this step is housekeeping. Step 1 was the fix.
See also what is incident response for how this fits a wider process.
Common mistakes
- Deleting instead of revoking. Covered above. The most common and most costly.
- Rotating only the secret that leaked. If the same secret is reused elsewhere, such as the same password across environments, all copies need rotating.
- Forgetting the old one. Creating a new secret and leaving the old one active.
- Rotating without knowing the consumers. This causes outages, which then teach the team never to rotate.
- Rotating on a calendar and ignoring events. A 90-day schedule does not help if a secret leaked on day 2.
- Storing the new secret in the same unsafe place. If the cause was a hardcoded key, a new hardcoded key has the same flaw.
- Never testing it. A rotation process you have not practised will fail during an incident.
The best rotation is removing the secret
Rotation reduces the risk of a long-lived secret. Removing the secret removes the risk. Wherever possible, replace stored secrets with identities that issue short-lived credentials automatically:
- Use managed identities and attached roles for workloads in the cloud.
- Use federated authentication for CI/CD pipelines so they do not hold cloud keys.
- Use just-in-time access for humans, so privileged access exists only for the minutes it is needed. See what is JIT access and what is zero standing privilege.
Each secret removed is one fewer to rotate, one fewer to leak, and one fewer to revoke in a crisis. This ties directly to defending against credential theft: a stolen credential that expires in an hour is a far smaller problem than one that works forever. It also applies to newer secret types such as AI provider keys, where fast revocation limits the cost of LLMjacking.
How Cloudanix helps
Cloudanix does not store or rotate your secrets, and it does not replace a secrets manager. It helps you find secrets that need attention, reduces how many long-lived secrets you depend on, and shortens how long a leak stays open.
- Find exposed secrets. Code Security scans repositories and commit history using 2,000+ secret patterns (with support for your own), so you can see what needs revoking, including secrets buried in old commits.
- Block new leaks. Scanning in pull requests and the Coding Agent Firewall stop secrets before they are committed or sent out of a developer’s machine by an AI coding agent.
- Remove standing credentials. Cloud JIT, Agentic JIT and Coding Agent JIT issue scoped, time-limited access to people, pipelines and AI agents, so there is no long-lived key to rotate.
- Know the blast radius. Attack path analysis and CIEM show what a leaked credential could reach, so you can prioritize revocation and scope the investigation.
- Spot misuse during the window. Cloud UEBA and cloud detection and response flag an identity being used from somewhere or in a way it never has been.
What this does not do: revoking a secret happens at the system that issued it, such as your cloud provider or the AI vendor, and you or your automation must do that. Cloudanix finds what to act on and shows what is at stake.
Frequently asked questions
What is the difference between secret rotation and revocation?
Rotation replaces a secret with a new one, usually on a schedule or after an event. Revocation makes an existing secret stop working immediately. After a leak you revoke first, then replace. Routine rotation is the habit that makes fast revocation safe.
Is deleting a leaked secret from my repository enough?
No. The secret remains in version history, forks, caches and any copies already taken, and it still works until it is revoked at the system that issued it. Deleting it from the repository does not end the exposure.
How often should secrets be rotated?
It depends on the secret and your requirements. Many teams use 30 to 90 days for high-risk secrets and rotate any secret immediately after a suspected exposure or when someone with knowledge of it leaves. The more sensitive the secret, the shorter the life it should have. Where possible, use short-lived credentials so rotation is automatic.
How do I rotate a secret without downtime?
Use the overlap pattern: create the new secret while the old one still works, roll it out to all consumers, confirm the old one is no longer used, then revoke it. For databases, a secrets manager can alternate between two users.
What should I do first when a secret leaks?
Revoke or deactivate it immediately, before investigating. Then issue a replacement, review the logs back to the earliest possible date of exposure, and check for persistence such as newly created credentials or roles.
Can rotation stop an attacker who already got in?
Not always. If an attacker used the leaked secret to create their own credentials or roles, rotating the original does not remove those. After revoking and replacing, review what the compromised identity created or changed.
Why not just use a vault and forget about it?
A vault stores secrets securely and can automate rotation, which is a good practice. But a vault does not know about secrets that were never put in it, or copies already leaked, and it cannot revoke a secret at the provider unless integrated to do so. Vault plus scanning plus short-lived credentials is stronger than any one alone.
