How to Revoke SaaS Access for an Ex-Employee

A practical step-by-step guide for IT operators: how to revoke SaaS access across every app when an employee leaves, including the apps that get missed every time.

Direct-answer block: To revoke SaaS access for an ex-employee, you need to work through three layers in sequence: (1) disable their identity source — the IdP, Google Workspace, or Microsoft 365 account that federates other apps; (2) manually revoke every app that doesn't federate or sync; (3) verify revocation by checking each app's admin console and pulling the evidence. The gap between step 1 and step 2 is where most data-security incidents happen. Industry research puts the median time to full revocation at around 11 days at mid-market companies doing this manually — automated platforms run the same sequence in under 60 seconds.

Someone left on Friday at 4pm. HR sent you the name at 4:45pm. By 5pm you've deactivated their laptop and changed the Slack status to "Former employee." By Monday morning you realise you forgot GitHub, Figma, the billing seat in Notion, and the Salesforce admin role they picked up six months ago during a project nobody documented.

This is the offboarding gap. It's not a process failure — it's a scale failure. Once your SaaS stack crosses 15 apps, manual revocation stops being reliable.

This guide walks through the three-layer revocation process, the apps that get missed every time, and how to close the gap.

The three-layer revocation model

Layer 1 — Disable the identity source (do this first, within the hour)

The fastest thing you can do is kill the central account. Depending on your stack:

• Google Workspace: Suspend the user account (Admin Console → Users → Suspend). This immediately blocks Gmail, Drive, Calendar, Meet. Apps that use Google SSO will also block if they enforce token validation on the next login.
• Microsoft 365 / Entra ID: Revoke sessions and disable the account (Entra ID → Users → Block sign-in + Revoke all refresh tokens). This blocks all M365 apps plus any Azure AD SSO apps.
• Okta or another IdP: Deactivate the user. Okta pushes a deprovisioning event to connected apps via SCIM or API.

What Layer 1 does not cover: apps that don't check back with your IdP on each session, apps where the user authenticated via username/password (not SSO), apps where your company isn't the billing admin (shadow IT), and apps that use personal email accounts.

Layer 2 — Revoke every app that doesn't federate

This is the hard part. For every SaaS app in your stack, you need to check whether the Layer 1 action actually cut access — or whether the app has its own session that's still live.

The rule: if an app supports SSO through your IdP, and the app enforces IdP token validation on every authenticated request, Layer 1 is enough. If it doesn't — if the app has local sessions, API tokens, or its own user management — you need to manually revoke.

Apps that typically require manual revocation even after you've disabled the IdP:

• GitHub — personal access tokens, SSH keys, and OAuth grants all survive account suspension. Remove these separately.
• Figma — admin console seat removal required if the user was invited directly
• Adobe Admin Console — no public API for mid-market plans; requires manual admin console action
• Notion — workspace member removal required
• Loom, Miro, Canva — each has their own admin seat model
• Salesforce — deactivate the user in Salesforce specifically; system admin roles need to be transferred first
• 1Password — suspend in 1Password admin even if they can't log in
• Billing seats (Stripe, Intercom, HubSpot, Zendesk) — the user may have an owner role in the billing system that survives their login being blocked
• CI/CD tokens (GitHub Actions secrets, CircleCI, Vercel) — any deploy key or service account tied to their personal account

The full revocation scope is usually 1.5x to 2x what your software list suggests. The gap is tokens, keys, OAuth grants, and shared credentials that were never formally assigned.

Layer 3 — Verify and capture evidence

After Layer 1 and Layer 2, run a verification pass. For each app:

1. Pull the app's active user list (or last-login audit log)
2. Confirm the ex-employee no longer appears as an active user
3. Screenshot or export the admin console state with a timestamp
4. Log the verification against the offboarding ticket or the HR event

This is the step most teams skip. It's also the step your SOC 2 auditor will ask about — specifically, how long between termination and revocation, and what evidence proves it.

The apps that get missed every time

Five categories that trip up even experienced IT teams:

1. Apps without SCIM or SSO Roughly 40% of mid-market SaaS apps don't support SCIM provisioning, and many don't support your IdP's SSO either. These require manual login-and-remove per app, every time. (Industry research figure — not a KINT metric.) There's no shortcut except knowing which apps they are before the offboarding starts, not during.

2. Personal-email accounts When someone joins a startup, they sometimes get invited to tools under their personal Gmail. When they leave, you have no admin access to that account. The fix is policy-level: only company-email accounts in company tools, enforced at invite time.

3. Shared credentials Any shared password in 1Password or LastPass needs to be rotated after someone with access leaves — not just their individual account revoked. This is especially critical for billing accounts, DNS registrars, and cloud consoles.

4. Admin and owner roles An IT manager who's been around for three years has probably been added as an admin, owner, or billing contact in 10 different places. Revoking their seat doesn't always remove their admin role. Check the role separately.

5. Contractor and vendor accounts Contractors added to tools "just for this project" never get formally offboarded. They're not in your HRMS. When the project ends, nobody gets the "revoke access" ticket.

How long should this take?

Manually, for a 200-employee company with 20 active SaaS apps: 4 to 8 hours of IT time spread across multiple systems, usually across multiple days as you discover the apps you forgot.

The 11-day median isn't because IT teams are slow. It's because the process is distributed across memory, Notion docs, email threads, and whoever's available that week.

See the full breakdown of why offboarding takes 11 days →

Automated platforms (KINT and others in the category) run the same sequence in under 60 seconds — HR event fires, every connected app revokes in parallel, signed evidence is logged per app. The difference is architecture, not effort.

How to do this faster next time

Three things that cut revocation time before the offboarding event:

1. Maintain a live app inventory You can't revoke access to apps you don't know exist. A live list of every SaaS tool, its admin console URL, and who has access is the prerequisite. If you're doing this in a spreadsheet, keep it current after every new tool is added.

2. Run your offboarding from a single trigger Whether that's an HR event, an IdP deactivation, or a manual ticket — the trigger should fire one process, not require you to remember 20 steps. Even a simple checklist tool is better than relying on memory Friday at 5pm.

3. Separate the apps by revocation method Layer 1 apps (IdP-federated, enforce token validation) → revoke at the IdP. Layer 2 apps (manual, or browser-automation required) → run through a separate app-by-app checklist. Once you know which app is in which layer, the process is predictable.

If you want to see how automated revocation works across both layers — including browser automation for the apps without APIs — KINT runs a 14-day free trial, self-serve, no card. You can connect your existing stack and run a test offboarding against a real app in the first session.

See how KINT handles instant offboarding →

FAQ

Q: How quickly should SaaS access be revoked after an employee leaves? Best practice is full revocation within 24 hours of the termination event for standard accounts, and within 1 hour for admin or privileged accounts. SOC 2 CC6.3 specifically requires evidence that access was revoked after departure — if your SLA isn't documented and enforced, it's a gap. Industry research suggests the median actual revocation time at mid-market companies is around 11 days.

Q: What happens if I only disable the Google Workspace or Microsoft 365 account — is that enough? For apps that strictly enforce IdP token validation on every session, yes. For everything else — apps with their own sessions, API tokens, SSH keys, personal-email invites, shared credentials, or no SSO integration — no. Disabling the identity source is Layer 1. It's necessary but not sufficient.

Q: Which SaaS apps require manual revocation even after the IdP is disabled? GitHub (personal access tokens and SSH keys survive), Figma, Adobe Creative Cloud, Notion, Loom, Miro, Canva, Salesforce, 1Password, and most billing and financial SaaS (Stripe, QuickBooks, Expensify). Any app the user joined via their personal email also requires manual action.

Q: How do I handle offboarding for apps without SCIM? Three options: (1) manual login-and-remove per app (scales poorly past 10 apps), (2) browser automation that drives the admin console headlessly (what KINT does for apps like Adobe), (3) outsource to a managed service. Option 1 is the default at most mid-market teams; options 2 and 3 exist for teams that have hit the manual-revocation wall.

Q: What evidence do I need for a SOC 2 audit? CC6.3 requires proof that logical access was removed promptly after termination. Practically: a timestamped admin console export or screenshot for each app, showing the user's account as deactivated or removed, matched against the offboarding date in your HR system. Auditors sample these — the gap between termination date and revocation date is what they're checking.

Q: What's the fastest way to revoke SaaS access for an ex-employee? Disable the central identity source (Google Workspace, Microsoft Entra, or Okta) first — that covers federated apps immediately. Then work through the manual-revocation list for apps outside the federation scope. With an automated platform running HR-event-triggered workflows, the full sequence completes in under 60 seconds. Manually, expect 4 to 8 hours for a 20-app stack.

Q: What if the employee left access to a shared account or shared password? Rotate the password immediately. Shared credentials are a separate risk from individual account revocation — even if you've removed the user's seat in every tool, a shared password they knew still gives access. Post-offboarding credential rotation should be part of your standard process for anyone who had access to shared admin accounts.

Q: Do I need an identity provider (Okta, Entra, etc.) to automate SaaS offboarding? No. HR-driven platforms like KINT run direct from your HRMS to your SaaS apps — no IdP required in the middle. If you have an IdP, the platform can work alongside it and cover the apps your IdP can't reach. See: Do I need Okta to automate provisioning? →