When someone leaves, access should leave with them. Yet in many teams, the “account” gets disabled while the sessions, tokens, and shared logins keep working.
That leftover access is ghost access. It’s like collecting keys at the door but forgetting the spare under the mat.
This 2026-ready saas offboarding checklist focuses on speed, proof, and the parts most teams miss, especially OAuth grants, API keys, and service accounts.
Why ghost access is worse in 2026 (and harder to spot)
SaaS offboarding used to mean email, VPN, and a few core apps. Now it’s hundreds of app connections, browser-based logins, automation bots, and vendor portals. As a result, “disabled in one place” often means “still active somewhere else.”
Three patterns cause most misses:
- Token-based access outlives passwords. OAuth grants and long-lived refresh tokens can keep pulling data even after a password reset.
- Admin sprawl hides in plain sight. People get temporary admin to “fix one thing,” then keep it for months.
- Non-human access multiplies. Service accounts, shared inboxes, and integration users rarely follow HR events.
If you rely on SCIM, understand what it does and doesn’t cover in your stack. Vendor explanations like how SCIM deprovisioning works help clarify the boundary between IdP actions and app-side cleanup.
The 2026 SaaS offboarding checklist (timeline, owners, evidence)
Offboarding works best as a timed runbook with named owners. Use this table as your default flow, then attach app-specific steps.
| Time window | Primary owner | What “done” means | Evidence to save |
|---|---|---|---|
| Pre-offboarding (planned exit) | HR + Manager + IT | Inventory apps, data owners, and handoffs confirmed | Ticket ID, app list export, manager approval |
| T0 (notification to IT) | IT/Identity | Central identity disabled, sessions revoked, high-risk secrets rotated | IdP audit event IDs, screenshots, timestamps |
| T+24 hours | App owners + Security | App accounts disabled, OAuth grants removed, API keys rotated | Admin logs, key rotation record, exports |
| T+7 days | Security + RevOps/FinOps | Access review complete, licenses reclaimed, exceptions closed | Final checklist sign-off, exception register |
Use these checkboxes as the core “T0 to T+24” pass. Keep them in one ticket so nothing gets scattered.
- Confirm legal name, username, primary email, aliases, and employee ID match across systems
- Disable identity at the source (IdP or directory), then revoke sessions
- Remove from privileged groups and admin roles first, then general groups
- Transfer ownership of critical assets (mailbox, Drive, CRM objects, code repos)
- Rotate shared secrets the person could access (password vault items, shared inbox passwords)
- Revoke OAuth grants and third-party app connections tied to the user
- Identify and rotate API keys, PATs, SSH keys, and CI tokens owned by the user
- Disable or re-key service accounts and automation tied to the user
- Verify access removal in top systems (email, chat, CRM, finance, cloud)
- Save audit evidence, then close with approver sign-off
Stop Ghost Access (what your IdP won’t fully clean up)
Most teams disable a user and assume SSO handles the rest. That’s only partly true. This section is the “ghost hunt” for access paths that survive a normal disable.
Enforce SSO and MFA (so you can actually revoke)
If an app allows local passwords, a user can often keep logging in after the IdP is disabled. In 2026, treat SSO enforcement as an offboarding control, not a convenience.
- Require SSO for all supported SaaS apps, block local auth where possible
- Enforce MFA at the IdP, and prefer phishing-resistant methods for admins
- Separate admin roles into dedicated admin accounts, with stronger MFA
For teams building SCIM and lifecycle automation, a current view of providers can help you standardize, see best SCIM providers for automated provisioning in 2026.
SCIM deprovisioning: verify, don’t assume
SCIM often disables the app user, but it may not remove tokens, API keys, or app-level roles.
- Confirm the SCIM action landed in the app (disabled or deactivated)
- Check for app-side admin roles that SCIM doesn’t map
- Confirm group-to-role mappings didn’t leave “shadow admin” access
Shared inboxes and shared logins (the quiet back door)
Shared mailboxes and “team” accounts are where ghost access hides best, because nobody expects them to be personal.
- Remove the user from shared mailbox delegation and shared calendar access
- Rotate passwords for shared accounts, then store in a vault with access logging
- Review mail forwarding rules, delegated send-as, and third-party mailbox add-ons
API keys, tokens, and OAuth app grants
Tokens don’t care about HR dates. If a token exists, it works until you revoke it or it expires.
- Revoke OAuth grants for the user in major apps (CRM, support desk, file storage)
- Rotate API keys created by the user (especially “personal” tokens used in scripts)
- Invalidate personal access tokens (Git, CI, data tools), then re-issue under a team-owned identity
Gotcha: disabling an account rarely kills every token. Plan for explicit revocation in each high-risk SaaS app.
Service accounts and automation users
If a departing person “owns” a service account, your choice is simple: re-home it or replace it.
- Change service account owner to a team mailbox and document it
- Rotate credentials, update apps and scripts, then confirm last-run success
- Remove the departed user from being the only admin who can manage that identity
Device and session revocation (close active doors)
Even with perfect identity steps, active sessions on devices can stay open.
- Revoke IdP sessions and app sessions for high-risk tools
- Remove registered MFA factors and trusted devices where your IdP supports it
- If managed devices exist, trigger a device check-in and access cut (or wipe when required)
If you don’t have an IdP: manual fallback that still holds up in audits
Some SMBs still run without Okta, Entra ID, or a formal IdP. You can still prevent ghost access, but you must be disciplined and consistent.
- Start with the email account because it resets everything else. Reset password, kill sessions, and remove recovery options.
- Pull an “apps used” list from finance, browser password managers, and email invites.
- Disable accounts in your top 10 SaaS apps by risk (email, storage, chat, CRM, finance, cloud, password manager).
- Rotate shared credentials and shared inbox passwords the same day.
- Revoke OAuth connections inside core apps, then check “connected apps” pages.
- Search for API keys and tokens by username and email, then rotate or delete.
- Transfer ownership for data and automation, then test critical workflows.
- Document every action with timestamps and a single ticket number.
If Google Workspace is your “directory by default,” use vendor-aligned guidance like offboarding accounts from Google Workspace to avoid missing Drive ownership, devices, and recovery settings.
Evidence to collect, common failure points, and a copyable policy snippet
Audits and incident reviews punish vague statements like “disabled user.” Collect proof as you go, then attach it to the offboarding ticket.
Here’s a simple evidence map for your saas offboarding checklist.
| Control area | Evidence to attach | What it proves |
|---|---|---|
| IdP disable + session revoke | Audit event ID, screenshot, timestamp | Central access was cut at T0 |
| SCIM deprovision results | App user export before/after | Account status changed in SaaS app |
| OAuth grant removal | “Connected apps” export or log reference | Tokens and third-party access removed |
| API key rotation | Key inventory export, rotation record | Old secrets can’t be used |
| Shared access cleanup | Delegation list screenshot, vault record | Shared inboxes and accounts were secured |
Two failure points cause repeat incidents:
- You offboard the user, not the access paths. Fix it by standardizing token revocation and key rotation in your runbook.
- Exceptions live forever. Fix it with a short exception SLA and monthly review.
For a broader SaaS-first view of what teams often forget, compare your process to Nudge Security’s IT offboarding checklist, then adapt it to your toolset.
Copyable offboarding policy snippet (2026)
Offboarding SLA and timelines: IT disables central identity within 1 hour of HR notification for involuntary exits, and within 4 business hours for planned exits. High-risk access (admin roles, finance, cloud, password manager) must be removed within 4 hours. All other SaaS access must be removed within 24 hours.
Evidence requirement: Each offboarding ticket must include timestamps, admin log references (or screenshots), and exports for IdP status, key/token actions, and shared access changes.
Exceptions: Any exception needs Security approval, an owner, a written reason, and an expiration date no more than 7 days out. Security reviews exceptions weekly until closed.
Conclusion
Ghost access isn’t mysterious, it’s just unfinished offboarding. When you treat tokens, shared access, and automation identities as first-class risks, the process becomes predictable. Start with the timeline table, enforce SSO where you can, and keep evidence in a single ticket. Then ask one final question after every departure: what access could still work tomorrow if nobody touches it today?
