Overview
When a user changes roles or leaves the organization, "remove access" must actually be true. This sounds obvious, but most IAM implementations fail here. Teams disable an account in Active Directory and assume access is gone. In reality:
- SaaS applications may cache sessions for hours or days
- OAuth tokens remain valid until they expire
- Privileged sessions continue until explicitly terminated
- Some apps have local accounts that aren't tied to the directory at all
The result: Terminated employees remain logged into sensitive systems. Role changers retain old access alongside new access. Audit evidence says "access removed" when access very much still exists.
The architectural challenge: Access spans multiple layers, each with different revocation semantics:
- Account layer: Disable/delete the account
- Session layer: Terminate active sessions
- Token layer: Revoke or wait for token expiry
- Credential layer: Rotate passwords/keys the user knew
A robust deprovisioning architecture addresses all layers, with risk-tiered SLAs and verification.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| Time-to-revoke SLA | Same for all / Risk-tiered | Risk-tiered: Tier-0 in minutes; Tier-2 in hours/days | Match urgency to risk |
| Revocation scope | Account only / Account + session / Full stack | Full stack for Tier-0; Account + session for Tier-1 | Credential rotation for high-risk |
| Token strategy | Long-lived / Short-lived + refresh | Short-lived (fewer than 60 min) with constrained refresh | Short tokens limit exposure window |
| Session revocation method | IdP global signout / Per-app API / Implicit (token expiry) | IdP signout + per-app where supported | Many SaaS apps don't support forced session termination |
| Verification | None / Manual spot-check / Automated verification | Automated verification for Tier-0; quarterly drills | Trust but verify |
| Privileged session handling | Standard flow / Immediate termination | Immediate PAM session termination for any term/high-risk event | PAM must be in the deprovisioning flow |
| Emergency procedures | Standard process / Expedited path | Expedited path for security incidents with verification | Different from standard termination |
Architecture & Reference Patterns
Pattern 1: Multi-Layer Revocation Architecture
Diagram
Pattern 2: Risk-Tiered Revocation
| Tier | Target Examples | Time-to-Revoke SLA | Scope | Verification |
|---|---|---|---|---|
| Tier-0 | Domain Controllers, PAM, PKI, core infrastructure | 15 minutes | Full stack: account + session + credential rotation | Immediate automated |
| Tier-1 | Production databases, financial systems, PII systems | 1 hour | Account + session termination | Same-day automated |
| Tier-2 | Standard SaaS, collaboration tools | 24 hours | Account disable; session expires naturally | Weekly sampling |
| Tier-3 | Low-risk tools, informational apps | 72 hours | Account disable | Monthly audit |
Revocation Layer Matrix
| Layer | What to Revoke | Who Owns | Method | SLA Achievability |
|---|---|---|---|---|
| HR status | Employment state | HR | HR system update | Trigger, not enforcement |
| Directory account | AD/LDAP account | IGA | Disable + remove group membership | Minutes (direct control) |
| IdP account | Okta/Entra account | IGA | Disable + trigger signout | Minutes (API available) |
| IdP sessions | SSO sessions | IdP | Global signout API | Minutes where supported |
| SaaS sessions | Individual app sessions | App-specific | Per-app API if available | Hours (often not supported) |
| OAuth tokens | Access/refresh tokens | IdP + App | Refresh revocation; access expires | Minutes to hours (TTL dependent) |
| Privileged sessions | PAM sessions | PAM | Immediate termination | Minutes (PAM controls) |
| Privileged credentials | Vaulted passwords | PAM | Rotation | Minutes to hours |
Session Termination Support by Platform
| Platform | Session Termination API | Token Revocation | Notes |
|---|---|---|---|
| Okta | Yes (Clear User Sessions) | Yes (revoke tokens) | Well supported |
| Entra ID | Yes (Revoke Sign-in Sessions) | Partial | Continuous Access Evaluation helps |
| Google Workspace | Yes (Sign out user) | Yes | Admin API |
| Salesforce | Yes (Session API) | Yes | Enterprise feature |
| Slack | Limited | Limited | May require license tier |
| Zoom | No direct API | Limited | Session persists until idle timeout |
| Generic SaaS | Varies widely | Varies widely | Test per application |
Emergency Revocation Flow
Diagram
Implementation Approach
Phase 0: Discovery (2-3 weeks)
Inputs: Application inventory, current deprovisioning process, session/token architecture Activities:
- Map all access paths (SSO, local accounts, API tokens, privileged paths)
- Document current deprovisioning process and timing
- Inventory session termination capabilities per application
- Document token TTLs and refresh policies
- Classify applications by risk tier
- Identify gaps (apps without termination capability)
Outputs: Access path inventory, session termination capability matrix, gap analysis
Phase 1: Design (2-3 weeks)
Inputs: Discovery outputs, risk appetite, compliance requirements Activities:
- Define time-to-revoke SLAs by risk tier
- Design revocation workflow per layer
- Define session termination approach per app (API, expiry, manual)
- Design verification approach
- Design emergency/expedited procedures
- Document compensating controls for apps without termination capability
Outputs: Deprovisioning design document, SLA definitions, verification plan
Phase 2: Build (4-6 weeks)
Inputs: Design documents, API access Activities:
- Build IGA deprovisioning workflow
- Integrate IdP session revocation APIs
- Integrate PAM session termination
- Build per-app session termination where supported
- Implement verification automation
- Configure token TTLs per policy
- Build emergency revocation workflow
Outputs: Integrated deprovisioning workflows, verification jobs
Phase 3: Validation (3-4 weeks)
Inputs: Built workflows, test accounts Activities:
- Test standard deprovisioning end-to-end
- Test emergency revocation
- Measure actual time-to-revoke per tier
- Verify session termination works as expected
- Validate verification catches failures
- Run deprovisioning drill with security team
Outputs: Validated workflows, measured SLAs, drill results
Phase 4: Operate (Ongoing)
Activities:
- Monitor deprovisioning completion and timing
- Investigate verification failures
- Run periodic deprovisioning drills (quarterly recommended)
- Update workflows as applications change
- Report compliance with SLAs
Deliverables
- Deprovisioning SLA document — time-to-revoke by tier, scope, verification
- Session termination matrix — per-app capability and approach
- Deprovisioning workflow — step-by-step process with ownership
- Verification procedure — how to confirm access is actually removed
- Emergency revocation runbook — expedited process for incidents
- Compensating controls — for apps without session termination
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| SaaS sessions persist after disable | H | H | Terminated user still active in SaaS logs | Short token TTLs; per-app termination where possible |
| Privileged sessions not terminated | M | H | PAM sessions continue post-termination | PAM in deprovisioning workflow; immediate termination |
| Token TTLs too long | M | H | Hours of residual access | Shorten TTLs; continuous access evaluation |
| No verification | H | H | Deprovisioning assumed complete but isn't | Automated verification; drills |
| Emergency process untested | M | H | Incident response fumbled | Regular drills; documented runbook |
| Shared credentials not rotated | M | H | Departed user retains access via shared creds | Identify and rotate credentials user had access to |
KPIs / Outcomes
- Time-to-revoke (p95): Actual time by tier (target: meet SLA per tier)
- Session termination success rate: % of apps with confirmed session termination (target: 100% for Tier-0)
- Verification pass rate: % of deprovisioning events verified successful (target: greater than 99%)
- Deprovisioning drill success: % of drill scenarios passing (target: 100%)
- Token TTL compliance: % of apps with tokens within policy (target: 100%)
- Mean time to detect verification failure: Time from failure to alert (target: fewer than 1 hour)
Workshop Questions
Security / IAM
- What are Tier-0 systems requiring fastest revocation?
- What's the acceptable residual access window by tier?
- How are security incidents handled differently from standard terminations?
Application Owners
- Does your application support session termination via API?
- What are your token/session TTLs?
- What happens when an IdP account is disabled—does access immediately stop?
SOC / Security Operations
- How do you verify access is actually removed today?
- What's the incident response process for compromised accounts?
- What visibility do you have into active sessions across applications?
Requirements Gathering Checklist
- What applications are in scope and what are their risk tiers?
- What's the required time-to-revoke SLA by tier?
- What session termination capabilities exist per application?
- What are token TTLs for SSO and per-app tokens?
- How is PAM integrated into deprovisioning (session termination, credential rotation)?
- What's the current deprovisioning process and how is completion verified?
- What's the emergency revocation process for security incidents?
- What compensating controls exist for apps without session termination?
- How often are deprovisioning drills conducted?
- What shared credentials might a departing user have knowledge of?
- What monitoring exists for detecting incomplete deprovisioning?
- What audit evidence is required for compliance?