Sign in Subscribe
Identity Security

Secure SaaS Offboarding in Under 24 Hours: The Revocation Sequence IT Teams Actually Need

A step-by-step SaaS offboarding sequence for IT teams: revoke tokens, audit PATs, close SCIM gaps, and collect SOC 2 and ISO 27001 audit evidence.

Secure SaaS Offboarding in Under 24 Hours: The Revocation Sequence IT Teams Actually Need

Secure SaaS Offboarding in Under 24 Hours: The Revocation Sequence IT Teams Actually Need

In 2020, a former Cisco engineer walked out the door and kept access to his cloud infrastructure credentials for five months. He used that access to delete 456 virtual machines running Cisco's Webex Teams service, taking down roughly 16,000 accounts. A federal conviction followed. The gap that made this possible was not a sophisticated exploit. His employer's offboarding process left an administrative access path open long after his resignation was accepted.

Most offboarding failures are quieter than that. An employee leaves, the Entra ID account gets disabled, and IT moves on. Dozens of SaaS sessions, API tokens, and non-federated credentials remain active. Someone else checks the box. Nobody checks the sessions.

This is a 24-hour problem. Here is the sequence to close it.

Account disabled is not the same as access revoked

Disabling an account in Entra ID blocks new sign-ins immediately. What it does not do is kill existing sessions in most SaaS applications.

Access tokens in Entra ID have a default lifetime of 60 to 90 minutes. Until that token expires, a client holding it can still authenticate to any resource that trusts it, regardless of whether the underlying account is disabled. Refresh tokens extend the window further: 24 hours for single-tenant apps, 90 days for persistent sessions. Without additional action, a freshly disabled account can remain operationally active in cached sessions for the rest of the business day.

Continuous Access Evaluation (CAE) narrows this window for Microsoft 365 workloads. When an account is disabled, CAE-capable resource providers like Exchange Online and SharePoint Online receive the event and reject current tokens within roughly 15 minutes, forcing re-authentication. CAE only applies to specific Microsoft 365 applications and CAE-capable clients. Third-party SaaS apps do not participate.

The practical gap: disabling the IdP account stops new logins. Existing sessions in tools like Salesforce, GitHub, and Atlassian keep running until their own timers expire. That is the window this sequence closes.

The revocation sequence: eight steps, in order

Sequence matters here. The first two steps close the Microsoft 365 window fast; the rest smoke out the sessions that survive outside it.

  1. Disable the Entra ID account. This blocks new authentications immediately and triggers CAE for Microsoft 365 workloads. If Lifecycle Workflows are configured (requires Entra ID Governance), invoke the leaver workflow instead — it handles the disable, group removal, license removal, and session revocation as a triggered sequence.
  2. Revoke all refresh tokens. In the Entra admin center or via Graph API (POST /users/{id}/revokeSignInSessions), revoke all active refresh tokens. This forces CAE-aware clients to re-authenticate within minutes rather than waiting for natural token expiry.
  3. Check the SCIM provisioning logs. Do not assume SCIM-connected apps processed the disable event. Open the Entra portal under Monitoring > Provisioning logs and confirm each app shows a completed deprovisioning entry. SCIM calls can fail silently on the receiving app's end. The log is the only way to confirm propagation.
  4. Manually disable accounts in non-SCIM SaaS. Apps not connected to Entra automated provisioning need an explicit admin action. Slack on Pro or Basic tiers, Atlassian without the Guard Standard add-on, and any app never connected to SCIM at onboarding all fall here. Make a list; work through it.
  5. Audit and revoke API tokens, PATs, and SSH keys. This step covers the blast radius beyond web sessions. GitHub classic PATs have no built-in expiry and survive any IdP action entirely. An org owner must review and revoke them manually at the organization level. SSH keys and deploy keys associated with the account are in the same category.
  6. Audit privileged access. Disabling a user account does not remove PIM role eligibilities in Entra ID. A disabled account with an active PIM eligibility is a problem if the account is ever re-enabled during an employment dispute or a re-hire. Also check Salesforce admin profiles, GitHub org owner status, and Zoom admin roles. Remove them all.
  7. Suspend, do not delete, cloud storage accounts. Google Workspace: suspend the account in the Admin Console. Suspension blocks access immediately and retains Drive and Gmail data; it is reversible. For Microsoft 365, the account disable in step one already blocks access; OneDrive data is retained for 93 days after account deletion (configurable). Initiate a data transfer to the manager before deletion.
  8. Post-action access review. Confirm no active sessions remain across the systems you touched and close the offboarding ticket with a timestamp record. This is your audit artifact.

Steps 1 through 6 are achievable in under two hours with automation in place. Steps 7 and 8 may extend to 48 to 72 hours in complex environments, but the security window is closed at step 6.

Where sessions survive after the IdP is cut

These are the apps most commonly left running in a manual offboarding process.

Google Workspace: With SCIM provisioning configured via the Entra ID app gallery connector, account suspension propagates automatically. Without SCIM, existing Google session cookies persist up to 14 days after the IdP account is disabled. Explicitly suspend the Google account in the Admin Console regardless. Suspension blocks access and retains data; deletion triggers a 20-day recovery window before data is permanently gone, so defer it.

Slack: On Business+ and Enterprise Grid plans with SCIM enabled, deactivation propagates from Entra ID automatically. On Pro or lower tiers, there is no SCIM. Active Slack sessions persist after the IdP account is disabled. Manual deactivation in the Slack admin center is required.

Salesforce: Salesforce issues its own session tokens independent of the identity provider. A user active in Salesforce when the Entra account is disabled remains active for up to two hours (default session timeout). Use "Freeze User" for an immediate block. Follow with "Deactivate User" after the data handoff is confirmed.

GitHub: SAML SSO for GitHub Enterprise Cloud blocks new authentications when the IdP account is disabled. Classic PATs and SSH keys are not touched. An org owner must review and revoke them explicitly. Full SCIM deprovisioning for organizations not using Enterprise Managed Users may not be available, so verify current GitHub documentation before relying on it.

Atlassian (Jira/Confluence Cloud): Atlassian Guard Standard (formerly Atlassian Access) is required for SCIM-based auto-deprovisioning. Without it, the Atlassian account stays fully active even after the IdP account is disabled. Manually deactivate in the Atlassian Admin console.

Automation is how you hit a 24-hour SLA

Manual offboarding checklists fail under pressure. During a layoff, an acquisition, or a difficult termination, steps get missed or delayed. Automation converts "we have a process" into "we can prove it ran."

Lifecycle Workflows — available with Microsoft 365 E5 or the Entra ID Governance add-on — handle the Entra-side steps automatically: account disable, group removal, license removal, and session revocation triggered within roughly 30 minutes of an HR attribute change. Manager notification emails are included.

SCIM provisioning covers the downstream apps, but only for apps that were connected at onboarding. Deprovisioning is not retroactive. If Slack, Salesforce, or Zoom were never added to the Entra app gallery with provisioning configured, automation will not reach them on the day someone leaves.

The part most teams skip: monitoring. SCIM calls fail silently when the receiving application returns an error the provisioning service does not retry. The Entra provisioning logs surface these failures. Check them after every offboarding event, not just when something looks wrong.

What compliance auditors need to see

Two frameworks show up most often in audits at small to mid-market organizations.

SOC 2 CC6.2 governs logical access and requires a defined, consistently applied process for revoking access on termination. Auditors do not prescribe a specific SLA, but same-day revocation for privileged accounts is the baseline expectation in practice. The process needs to be documented and repeatable, not just described in a policy PDF that nobody runs.

ISO 27001 A.9.2.6 (2013) and A.5.18 (2022) both require access removal at termination across all systems, not just the primary directory. The 2022 revision expands this to include reviewing whether access rights were appropriate when originally granted — folding ongoing access governance into the same control.

Auditors typically ask for:

  • Ticketing system record with timestamp and assigned owner
  • Entra ID account disable event from the audit log
  • SCIM and provisioning logs showing downstream deprovisioning events
  • Manual revocation records for non-SCIM systems, with the approver's name
  • Post-action access review confirming no active sessions remain

Attach this evidence package to the offboarding ticket before closing it. That record closes the compliance loop, not the policy document.

Sources

Revision History

2026-04-20 — published

Initial Publish

Read next

Comments ()