After a zero-day exploit, rotate every credential the affected system could read or use: secrets in configuration files and environment variables, service account passwords, API keys, tokens, TLS private keys and any stored user credentials. Start with the ones that grant the widest access.
Why rotation is part of the fix
An attacker who ran code on a host can copy whatever it can read. Patching removes the flaw but does not invalidate stolen keys. If you skip rotation, the attacker may return with a valid login.
Find what the host could read
List secrets by where they live.
| Location | Examples |
|---|---|
| Config and environment | Database passwords, API keys, cloud access keys |
| Key stores and files | TLS private keys, SSH keys, signing keys |
| Memory and sessions | Active session tokens, cached credentials |
| Connected services | OAuth grants, service accounts used by the host |
| Stored user data | Password hashes, API tokens issued to customers |
If the host was a gateway, it may also hold VPN or directory credentials. Edge devices and stored credentials covers why those are high value.
Order of rotation
- Privileged and cloud credentials. Anything that can create or change infrastructure.
- Credentials to data stores. Databases, object storage, queues.
- Keys that sign or encrypt. Certificates, signing keys, token secrets. Rotating these may need coordination.
- Service-to-service tokens.
- User credentials. Force resets or session invalidation when user secrets were reachable.
Rotate safely
Create the new secret first, deploy it, then revoke the old one. Revoking first causes an outage. Log each rotation with a time stamp. Check access logs for use of the old secret before you revoke it, because use from an unfamiliar address is evidence of compromise.
When you cannot rotate quickly
Some secrets are embedded in devices or partner systems. For these, add monitoring on their use, restrict by network address where possible, and put the rotation on a dated plan.
Prevent the next one
Prefer short lived credentials and a secrets manager over long lived keys in files. Then a stolen secret expires on its own. Safeguard has an agent identity capability for managing credentials issued to AI agents.
Document what you did
Keep a table of each secret, where it lived, when you rotated it and who confirmed the old one no longer works. This is useful for the review and for auditors, and it shows which secrets were hardest to rotate so you can fix that before the next event.
Quick check
Do we rotate if we found no evidence of compromise?
If the host was exposed and held broad secrets, yes, as a precaution. Document the decision either way.
What order do we rotate in?
Start with privileged and cloud credentials, then data store access, then signing keys, then service tokens, then user credentials.
Last reviewed: 19 October 2026.
