Few emails make a developer’s stomach drop like one from a hosting or deployment platform saying there’s been a security incident and you should rotate your credentials. The message might be vague, and the work it implies is not. Every service your app talks to, every database, payment provider and email service, may depend on secrets stored in that platform. Here’s a practical checklist for what to do when you need to revoke secret keys after a platform-side breach, written so you can follow it calmly rather than in a panic.
First, understand what a secret is
In software, a secret is any value that grants access: API keys, database passwords, tokens, signing keys, webhook secrets, SSH keys and cloud credentials. Developer platforms often store these as environment variables so applications can read them at runtime. That convenience makes the platform a high-value target, because one compromise can expose keys for many connected services.
Step 1: Read the notice carefully
Find out what the provider says was affected. Was it environment variables, build logs, source code access, or only some accounts? Verify that the message is real by going to the provider’s official site or status page directly, not by clicking links in the email. Attackers often send fake incident emails to harvest credentials.
Step 2: Make an inventory
List every secret stored in the affected platform. Check production, staging and preview environments, build settings, CI variables and team-level shared variables. Don’t forget secrets that were once stored there and later removed, since logs or history might still hold them. A spreadsheet works fine. For each secret, note which service it unlocks and who owns that service.
Step 3: Prioritize by blast radius
Rotate in order of danger. A typical ranking:
- Cloud provider credentials and anything with broad administrative rights.
- Database credentials, especially for production data.
- Payment and financial service keys.
- Authentication secrets such as session signing keys and OAuth client secrets.
- Email, messaging and analytics keys.
- Low-privilege or read-only tokens.
Step 4: Rotate properly
Rotation means creating a new secret, updating your applications to use it, then revoking the old one. The order matters. If you revoke first, you cause an outage. If you never revoke, the old key stays dangerous. Where a service supports two active keys at once, use that overlap to switch without downtime.
Generate new values on the issuing service, not by editing the old one. Avoid reusing passwords or deriving new secrets from old ones. Store new secrets in a dedicated secrets manager where possible rather than scattering them across dashboards.
Step 5: Check for signs of misuse
Rotation closes the door; now check whether someone already walked through. Look at:
- Access logs on your cloud accounts, databases and APIs for unfamiliar IP addresses or unusual times.
- Unexpected spikes in usage or billing.
- New users, keys, roles or deployed resources you didn’t create.
- Changes to code repositories or deployment settings.
- Outbound emails or messages that weren’t sent by your team.
If anything looks wrong, treat it as an incident: preserve logs, limit access, and bring in your security contact or an outside responder.
Step 6: Secure the account itself
Change your platform password, make sure two-factor authentication is on, and review team members and connected integrations. Revoke any personal access tokens you no longer use. Check which third-party apps have permission to your repositories and remove the ones you don’t recognize.
Step 7: Tell the right people
If customer data could have been exposed, you may have legal and contractual duties to notify customers or regulators within set timeframes. Talk to your legal or compliance team early. Even when no obligation exists, clear and honest communication builds trust. Keep it factual: what happened, what you did, what customers should do.
Step 8: Reduce the damage next time
Every incident is a chance to improve. Consider these changes:
- Use short-lived credentials that expire automatically.
- Grant least privilege, so each key only does what it must.
- Keep secrets out of build logs and source code, and scan repositories for leaked keys.
- Use a dedicated secrets manager with audit trails.
- Document a rotation runbook and practice it, so the next one takes an hour, not a weekend.
- Separate environments so a staging leak doesn’t expose production.
Staying calm
A platform breach isn’t your fault, but the cleanup is your responsibility. The teams that handle it best are the ones with an inventory, a rotation process and monitoring already in place. If you don’t have those today, don’t wait for the next notice. Spend an afternoon listing your secrets and writing down how to replace each one. Future you will be grateful.
Featured image: Circa 1950 ABUS No 508 30 mm padlock marked Ges Gescht made in Germany.jpg by R. Henrik Nilsson, CC BY 4.0, via Wikimedia Commons.
