How to Rotate Sessions and Secrets After a Third-Party Provider Leak

Retrospective: this article looks back at events from February 2017, written in 2026 with the benefit of hindsight.

When a provider you depend on — a CDN, identity platform, CI/CD service or SaaS tool — announces that tokens or secrets may have leaked, speed matters more than certainty. Here is how to rotate sessions and secrets in an orderly way.

Step 1: Scope what the provider could see

List what flows through or is stored with the provider: user session cookies, API keys, OAuth tokens, database credentials, signing keys. If in doubt, include it.

Step 2: Invalidate user sessions

• Microsoft 365 / Entra ID: revoke sign-in sessions for affected users (or all users if scope is unclear) and require re-authentication.
• Your own applications: rotate the session signing key or bump a session version so existing cookies become invalid.

Step 3: Rotate machine secrets

Prioritize by blast radius:

1. Cloud provider credentials (AWS access keys, Azure service principal secrets).
2. Database and storage credentials.
3. Third-party API keys (payment, email, monitoring).
4. Signing keys and certificates.

Use your secrets manager — Azure Key Vault or AWS Secrets Manager — so applications pick up new values without redeployment where possible.

Step 4: Watch for misuse

Review sign-in logs, CloudTrail and Azure activity logs for use of old credentials after rotation. Failed attempts with revoked keys are a strong indicator someone had them.

Step 5: Reduce the next blast radius

• Replace long-lived keys with short-lived tokens and federated identity (OIDC) where possible.
• Keep an inventory of where every secret is used.
• Practice a rotation drill twice a year.

Common mistakes

Rotating the obvious keys and forgetting the ones embedded in scripts, mobile apps or partner integrations. The inventory is what makes rotation possible.