Skip to main content
Dark green background, "Weak Application Security Can Cost You Millions," 3 slanted images of fingers pointing to digital locks, and a "Learn the Basics" button
Revoke or Rotate? A Decision Tree for Stolen Machine CredentialsPrivileged Access
5 min readFor SecOps Engineers

Revoke or Rotate? A Decision Tree for Stolen Machine Credentials

The Decision You Are Facing

It's 2:00 a.m. An alert fires on a service account. Your human-identity playbook says to message the user and ask whether the sign-in was them. But there's no user to answer.

You're facing a different choice. Do you rotate the credential, revoke it, or contain it some other way? Each option carries a risk. Rotation keeps the integration alive but may leave the attacker in. Revocation cuts the attacker off but may take down a customer-facing service. The wrong call in either direction is costly, and the person on shift usually can't make it alone.

This guide provides if/then logic to settle the choice before the incident, not during it.

Key Factors That Affect Your Choice

Four factors drive the path. Answer them in order.

1. Do you know who owns the identity? CyberArk's research shows there are roughly 82 machine identities for every human identity, so an ownership field that's blank for many accounts is common. If you can't name the owning team in minutes, every path below slows down. Your inventory should record the owner and a brief note on what breaks if the identity is removed.

2. What is the blast radius? A read-only reporting token and a cloud admin service principal should never share a response path. Tier your identities in advance.

3. Is there evidence of an active attacker? Look for privilege escalation, group membership changes, new secrets minted, or newly registered apps. In Cloudflare's Thanksgiving 2023 incident, the alert that finally fired came more than a week after first access, when attackers added a service account to an administrator group. Escalation like that is your strongest signal.

4. Is a pre-staged replacement credential ready? If the owning team has already tested generating a new credential and storing it in their secrets manager, revocation can cost minutes of downtime instead of a day. If they haven't, revocation is a gamble.

Triage questions must be answerable from logs, not from a person. Compare where the credential normally authenticates from against where it's authenticating now. Then compare the permissions it holds against the permissions it has actually used over recent months. High-risk scopes sitting idle are where attackers go first.

Path A: Rotate

Choose this when all of the following are true:

  • The identity is in a lower blast-radius tier, or the evidence is thin.
  • Logs show no escalation, no new secrets, and no newly registered apps.
  • The integration is business-critical and a replacement credential is pre-staged.

Then:

  1. Issue the new credential through the owning team's tested procedure.
  2. Revoke the old credential immediately after cutover.
  3. Audit the identity for persistence anyway. Attackers with a privileged service principal often mint new secrets or register their own app, and none of that disappears when the original credential changes.
  4. Scope backward across the full credential lifespan, not just the window after the alert. The first anomaly you see is rarely the first one that happened.

The trap: Rotation feels safe, but it only works if you're right about the attacker's position. Cloudflare rotated thousands of credentials after the Okta breach and still missed one access token and three service account credentials because the team wrongly believed nothing was using them. Rotate everything you find, then verify nothing was missed.

Path B: Revoke Immediately

Choose this when any of the following are true:

  • You see evidence of an ongoing attack: escalation, persistence artifacts, or access to data the identity never normally touches.
  • The identity sits in your top blast-radius tier.
  • The credential is a static secret with no behavioral baseline to compare against.

Then:

  1. Revoke first. Sort out the outage after.
  2. Invoke the pre-named approver. For top-tier identities, the playbook must name the role that can authorize an immediate revoke even if it knocks something over. If you leave that with whoever's on shift, you get a polite wait for permission while the token stays live.
  3. Hunt for persistence the revocation won't touch: secrets added to the identity, apps registered under it, and any credentials the identity could read.
  4. Check your regulatory clock. For SOCI-regulated entities, the 12-hour window for reporting a significant cyber incident to ASD can run while the approval conversation drags on.

The trap: Microsoft's Midnight Blizzard case turned on a legacy test tenant account with no MFA and an old test OAuth app that still held elevated access to the corporate environment. Revoking the account alone wouldn't have closed that door. Revoke the identity, then follow every grant it ever made.

Path C: Cascade Revoke for OAuth and SaaS Integration Tokens

Choose this when the compromised credential is an OAuth token granted to a third-party integration, or the incident originates at a vendor.

The Drift campaign shows why this path is separate. In August 2025, attackers obtained OAuth tokens that Salesloft's Drift chatbot used to talk to Salesforce, then pulled records from one customer instance after another for roughly ten days. Google's threat intelligence team concluded the attackers were mostly after credentials. They searched stolen data for AWS access keys and passwords to reach the next company.

Then:

  1. Revoke the integration's tokens at your own tenant, regardless of whether the vendor has acted.
  2. Treat everything stored in the affected platform as exposed. Search it for embedded secrets and add each one to your rotation list.
  3. Rotate those downstream credentials in blast-radius order.

The trap: Stopping at the token. The stolen data is the second-stage attack surface.

Summary Matrix

Factor Path A: Rotate Path B: Revoke Now Path C: Cascade Revoke
Typical trigger Suspicious but unconfirmed activity Escalation or persistence evidence Vendor or OAuth integration compromise
Blast-radius tier Low to medium High, or any with active attacker Any; data exposure drives scope
Replacement ready? Required Helpful, not required Rarely applicable
Who approves Owning team Pre-named executive role Pre-named role plus vendor liaison
Main risk Attacker stays in Production outage Secrets harvested from exposed data
Follow-up Persistence audit, lifespan scoping Persistence hunt, grant tracing Secret search, downstream rotation

Before You Need It

Write the triggers into the playbook as separate, unambiguous conditions so nobody debates them at midnight. Then run a tabletop with the application owners in the room. Pick your highest-privilege integration, simulate a stolen token from first alert through recovery, and time one thing: how long it takes the team to identify who can approve the revoke.

If that answer takes more than a minute, you've found your first fix.

Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide

You Might Also Like