Account Suspension vs Session Revocation: Which Action to Use When
Both actions stop attackers — but choosing wrong can either leave gaps or cause unnecessary disruption. Here's how to decide.
The Decision Point Every SOC Faces
An identity alert fires — suspicious sign-in, impossible travel, or MFA fatigue detected. You need to act fast. Your SOAR platform offers two primary response actions: suspend the account or revoke active sessions.
Choose wrong and you either leave the attacker with persistence (revocation when suspension was needed) or cause major business disruption for what turns out to be a false positive (suspension when revocation was sufficient).
This guide provides a clear decision framework for when to use each action, what each actually does under the hood, and how to automate the right choice based on signal confidence.
What Each Action Actually Does
Before deciding which to use, you need to understand what happens technically when you execute each action.
| Aspect | Session Revocation | Account Suspension |
|---|---|---|
| What happens | All active tokens/sessions invalidated | Account disabled, sign-in blocked completely |
| New sign-ins | Allowed (user can re-authenticate) | Blocked until account re-enabled |
| Existing sessions | Terminated within token lifetime | Terminated immediately |
| Business impact | Low — user just needs to sign in again | High — user locked out until IT intervenes |
| Reversibility | Automatic — user self-recovers | Manual — admin must re-enable |
| Attacker persistence | Broken if only session-based | Broken completely (credentials unusable) |
| Service accounts | Safe — will re-authenticate automatically | Dangerous — can break production |
Session Revocation: The Surgical Option
Session revocation invalidates all active refresh tokens and forces re-authentication. It's designed to disrupt an attacker who has stolen a session token without permanently locking out a legitimate user.
When to Use Session Revocation
- Suspicious activity detected but account compromise not confirmed
- Token theft indicators (session hijacking, AiTM phishing)
- User reports device loss or theft
- Impossible travel alert — likely VPN or legitimate travel
- First-stage response while investigation continues
- Service accounts where suspension would break production
What Session Revocation Does NOT Stop
- Attacker who knows the password — they can simply re-authenticate
- Compromised MFA device — attacker completes MFA challenge again
- Persistent OAuth app grants — malicious app retains access
- Inbox rules or forwarding — already configured persistence
- Stolen service principal credentials — separate credential set
Account Suspension: The Nuclear Option
Account suspension disables the account entirely — no sign-ins, no token refreshes, no access whatsoever. It's the definitive containment action when you're certain an account is compromised.
When to Use Account Suspension
- Confirmed account compromise (attacker has credentials)
- Active attacker persistence observed (mailbox rules, OAuth apps)
- Ransomware or destructive activity in progress
- High-value target with multiple compromise indicators
- Password confirmed exposed in breach database
- User confirmed they did not perform observed actions
Suspension Risks to Consider
- Service accounts — Suspending a service account can break production applications, APIs, and automated workflows
- Shared mailboxes — May impact multiple users and business processes
- Executive accounts — Business continuity concerns — ensure backup access exists
- False positive impact — User is completely locked out until manual intervention
Decision Framework: Which Action When
Use this matrix to map alert types and confidence levels to the appropriate response action.
| Scenario | Confidence | Action | Rationale |
|---|---|---|---|
| Impossible travel alert | Low | Revoke sessions | Likely VPN/travel — disrupt without lockout |
| MFA fatigue (< 5 pushes) | Medium | Revoke sessions | May be accidental — monitor for escalation |
| MFA fatigue (5+ pushes) | High | Suspend account | Active attack — full containment needed |
| Successful auth from TOR | High | Suspend account | Strong compromise indicator |
| Token theft / AiTM detected | High | Revoke + password reset | Session stolen — credentials may be safe |
| Password in breach DB | Confirmed | Suspend + password reset | Credentials definitely compromised |
| Malicious OAuth app granted | Confirmed | Revoke + remove app | App has persistent access — revoke both |
| Suspicious mailbox rules | Confirmed | Suspend account | Attacker has established persistence |
| Service account anomaly | Any | Revoke sessions first | Avoid production impact — investigate |
The Layered Response Pattern
For most identity incidents, the optimal pattern is a layered response that escalates based on findings.
Immediate: Revoke Sessions
Disrupt attacker persistence while preserving user access capability
- Revoke all refresh tokens
- Force re-authentication
- Log the action for audit
Investigate: Assess Compromise Depth
Determine if credentials are compromised or just the session
- Check for malicious OAuth apps
- Review mailbox rules
- Analyze sign-in logs for password usage
Escalate if Needed: Suspend Account
If investigation reveals credential compromise, escalate to full suspension
- Disable account
- Reset password
- Remove persistent access
Remediate: Clean and Restore
Remove all attacker persistence before restoring access
- Remove malicious apps
- Delete inbox rules
- Re-enable with new credentials
Automation Decision Matrix
Not all response actions should be automated. Here's guidance on what to automate vs. require human approval.
| Action | Automate? | Rationale |
|---|---|---|
| Session revocation (standard users) | Yes | Low impact, easy recovery, good first response |
| Session revocation (VIPs/executives) | With approval | May need coordination with EA/chief of staff |
| Session revocation (service accounts) | With approval | Risk of production impact |
| Account suspension (confirmed compromise) | Yes | Clear threat — speed matters |
| Account suspension (medium confidence) | With approval | False positive risk too high |
| Account suspension (service accounts) | Never auto | Production impact requires human judgment |
| Password reset | With approval | User coordination usually required |
Platform-Specific Commands
Microsoft Entra ID
# Revoke sessions Revoke-AzureADUserAllRefreshToken -ObjectId <user-id> # Suspend account Set-AzureADUser -ObjectId <user-id> -AccountEnabled $false # Both actions Revoke-AzureADUserAllRefreshToken -ObjectId <user-id> Set-AzureADUser -ObjectId <user-id> -AccountEnabled $false
Google Workspace
# Revoke sessions (sign out all devices) gam user <email> signout # Suspend account gam update user <email> suspended on # Both actions gam user <email> signout gam update user <email> suspended on
Okta
# Revoke sessions
DELETE /api/v1/users/{userId}/sessions
# Suspend account
POST /api/v1/users/{userId}/lifecycle/suspend
# Both actions
DELETE /api/v1/users/{userId}/sessions
POST /api/v1/users/{userId}/lifecycle/suspendCommon Mistakes
Suspending service accounts automatically
Problem: Can cause cascading production failures
Fix: Always require human approval for service account suspension
Only revoking sessions when credentials are compromised
Problem: Attacker simply re-authenticates with known password
Fix: Suspend + password reset when credential compromise confirmed
Suspending on every impossible travel alert
Problem: High false positive rate causes user frustration and alert fatigue
Fix: Revoke sessions first — escalate only if confirmed malicious
Not checking for persistence before re-enabling
Problem: Attacker retains access through OAuth apps or mailbox rules
Fix: Full persistence cleanup before account restoration
Same response for all account types
Problem: VIPs and service accounts need different handling
Fix: Segment response policies by account classification
Key Takeaways
- 1.Session revocation is the low-impact first response — use when confidence is low or medium
- 2.Account suspension is the definitive containment — use when compromise is confirmed
- 3.Layered response is the optimal pattern — revoke first, investigate, escalate if needed
- 4.Service accounts require special handling — never auto-suspend production identities
- 5.Always clean persistence before restoring access — revocation alone doesn't remove OAuth apps or rules
Automate Identity Response with BitLyft AIR®
BitLyft AIR® automatically selects the right response action based on signal confidence and account type — session revocation for low-confidence alerts, full suspension for confirmed compromise.
See It In ActionRelated Articles
How Does BitLyft AIR® Work for Different Industries?
Discover how BitLyft AIR® provides tailored solutions for finance, healthcare, manufacturing, and public utilities
BitLyft AIR® Changes the Game for Cybersecurity
An in-depth look at how autonomous security operations are transforming threat response
SOAR vs Security Automation vs Autonomous SOC: What's the Difference?
Understand the key differences between SOAR, security automation, and autonomous SOC platforms and learn which approach fits your security operations.