A leaked secret can stay live long after someone finds it, waiting on one question: what will break if this is turned off? Until someone can answer it, the ticket sits, and the secret keeps working.

That question has an answer, and the steps below get to it. They let a team replace an exposed secret, switch it off in a way that can be undone, and confirm afterward that the old value no longer works.

Why revoking feels risky

Revoking a key takes one click. The risk is everything that click touches. A key that has been in use for two years can sit in a cron job, a deployment pipeline, a partner integration, and a service that has not been opened since its original owner moved teams.

The team that receives the alert is rarely the team that runs those systems. They can see the key. They cannot see what depends on it, and revoking without that answer is a guess. A wrong guess is an outage.

So the work is answering that question first, then changing the order of operations so a wrong answer is cheap to undo.

1. Find out what still uses it

Start with the provider’s own record of use. AWS shows when each access key was last used and for which service. Google Cloud reports activity for service account keys. Most SaaS providers keep an audit log of API calls. If the key has not been used in months, there is nothing to break, and it can be revoked now.

If it is in use, the same logs tell you where from: source addresses, user agents, the services being called. Pair that with a search of the places the secret would be configured, such as vault entries, CI variables, and deployment manifests, and you have a list of consumers to move.

This is also the moment to check what the key can reach. A key that can write to production storage and has been public for a week cannot wait for a rotation window. A read-only key in an internal system usually can.

2. Issue the replacement before you pull the old one

The safest rotations overlap. Many providers let a single identity hold more than one active secret at a time, which is exactly what you need:

• An AWS IAM user can have two access keys at once.

• A Google Cloud service account can hold several keys.

• A GitHub App can have more than one private key registered.

• Stripe can roll an API key and keep the old one working for a period you choose.

Create the new secret, store it in your vault, and move each consumer over. If the services read the secret from the vault at runtime, this is one change. If the value is pasted into configs, it is one change per config, which is worth knowing before the next incident.

Where a provider allows only one secret per identity, create a second identity with the same permissions, move consumers to it, and retire the first.

3. Disable before you delete

Several providers separate turning a secret off from destroying it. AWS can mark an access key inactive. Google Cloud can disable a service account key. Both can be reversed in seconds.

Use that. Disable the old secret, then watch error rates and the provider’s logs for a set period. If something breaks, re-enable it, fix the consumer you missed, and try again. Changes can take a little while to apply across a provider, so give it time before you conclude nothing depends on it.

When the window passes quietly, delete it. A reversible step turns revocation from a gamble into an ordinary change with a rollback plan.

4. Prove it stopped working

Test the exposed value itself, not the replacement. Try to authenticate with the old secret and confirm the provider refuses it. Record the result.

That check is the only evidence the exposure ended. A deploy that rolled out the new key shows the new key works. It says nothing about the old one, which can stay valid if it was disabled on the wrong account, missed in one region, or re-enabled during a rollback.

Retesting works best where the provider gives a definite answer, which is true of most cloud and SaaS APIs: a revoked key gets a specific rejection. Database passwords and internal systems are harder, because a failed connection can mean the secret is dead or that the test simply could not reach the system. For those, run the check from inside the network, or have the system’s owner confirm the old value no longer works.

When it cannot wait

Sometimes the overlap is a luxury. If the secret is public, verified live, and can reach production data, revoke it first and handle the fallout second. An outage you start on purpose, with the on-call team ready, is easier to recover from than access you cannot see.

The same retest applies. Fast revocation still needs proof.

Make the next one easier

Every rotation shows where the next one will hurt. A few habits shrink that list:

• Read secrets from the vault at runtime. Rotation becomes one change instead of a hunt through configs.

• Give each service and environment its own secret. Revoking one key should not take down five systems.

• Use short-lived tokens where the platform supports them. Workload identity and OIDC federation leave less to rotate.

• Keep an owner on every secret. The person who can answer what depends on it should be one message away.

For provider-specific steps, How to Rotate has open-source rotation tutorials for dozens of services.

The worry that revoking will break something is reasonable. The answer is a procedure: know what uses the secret, replace it, disable the old one, watch, delete, and confirm it no longer works.