Most offboarding checklists list what to revoke. Almost none address the order to revoke it in, and the order is where a surprising number of offboarding processes quietly sabotage themselves. Disable the wrong thing first, and you can lose the ability to finish the job correctly.
Here's a scenario that plays out more often than it should. An IT admin offboards a departing employee by starting where it feels obvious to start: the identity provider. Disable the SSO account first, since that's the single source of truth most apps route through. Then work down through the individual applications.
Except the departing employee was the sole administrator on three SaaS tools, purchased with a company card outside the usual procurement process, never fully handed over. With SSO disabled first, the federated login into those apps is gone, and so, in some cases, is the easiest path to administering them. What should have been a clean revocation becomes a support ticket to the vendor, or a scramble to recover admin access to tools the company still needs and still pays for.
This is a checklist built around fixing that specific, common mistake: the order of operations in secure IT offboarding, not just the list of what needs to happen.
The Standard Mistake: Top-Down Deprovisioning
Most manual offboarding, understandably, starts at the top: disable the identity provider account, since it feels like the master switch. It's intuitive, and for many apps it works fine, disabling SSO cuts off login and that's sufficient.
The problem is the apps where it isn't sufficient: apps where the departing employee held sole or primary administrative rights, apps with add-ons or purchased extensions tied to their account specifically, apps where SSO controls login but not the underlying account's administrative privileges. Disabling SSO first, in these cases, doesn't just fail to revoke access, it can actively strand the organization's ability to manage the app going forward, because the person who could reassign ownership is now locked out at the same moment you needed them to still be reachable.
The Fix: Bottom-Up Deprovisioning
Reverse the order. Handle application-level administration and ownership transfers first, while the identity is still active and reachable, and disable the identity provider account last, once everything underneath it has been properly handled.
1. Inventory what the departing employee actually has access to, including sole administration. Before touching anything, identify every app they use, and specifically flag any where they hold sole or primary admin rights, own paid add-ons, or are the only person who has ever configured the account.
2. Transfer or reassign application-level ownership first. For any app where the departing employee is the sole admin, reassign that role to another active employee before revoking their access. This is only possible while their account is still active, which is exactly why it has to happen before, not after, the identity layer is touched.
3. Revoke application-specific access and shared/session credentials. Change shared passwords, revoke API keys or tokens tied to their identity, and remove them from shared accounts, while you still have full visibility into which apps they were part of through the active identity record.
4. Retrieve and secure hardware assets. Collect company-issued devices, and confirm any data on them has been backed up or transferred if needed, before the account tied to that hardware's management profile is disabled.
5. Disable the SSO or identity provider account last. Once every application-level dependency has been handled, disabling the central identity account is safe, because nothing downstream still needs that identity to be active in order to be managed.
6. Remove the account from directory services and confirm full deprovisioning. After SSO is disabled, complete the removal from any remaining directory or user database, confirming no residual entries persist that could be reactivated accidentally or exploited later.
7. Monitor for delayed or buffered account removal. Some applications maintain a grace period before permanently deleting a disabled account. During that window, monitor for any access attempts, since a former employee testing whether old credentials still work is a meaningful signal worth catching, not ignoring.
Why This Order Isn't Obvious, But Matters
The intuition to disable the identity provider first comes from treating it as the most important control, which it is, for authentication. But offboarding isn't only about stopping future logins, it's about completing every administrative action that depends on the departing employee's identity still being valid enough to reassign. Every one of those administrative actions, transferring app ownership chief among them, gets harder or impossible once the identity that could authorize it is gone.
The practical rule: revoke access to individual resources first, then remove the identity that granted access to them. Reversing that order doesn't just risk missing something, it can actively create new administrative problems that outlast the offboarding event itself.
What This Requires: Complete Visibility First
None of this sequencing matters if you don't know what the departing employee had access to in the first place. Sole app administration, particularly on tools purchased outside a formal procurement process, is exactly the kind of access that doesn't show up in a standard SSO-connected app list. A secure offboarding checklist depends on complete visibility into the full SaaS landscape, not just the federated slice, because the sequencing problem above only exists for apps you knew to check in the first place.
How Zluri Supports Bottom-Up Deprovisioning
Zluri is an identity security platform for autonomous enterprises, built as four products on one platform: Identity Visibility & Intelligence (IVIP), Identity Governance & Administration (IGA) with its four modules (Access Management, Access Requests, Access Reviews, and SoD), Identity Security Posture Management (ISPM), and SaaS Management (SMP).
IVIP's discovery methods surface exactly the access this checklist depends on identifying first: sole administrative rights, apps outside formal procurement, and ownership relationships that a standard SSO-connected app list would miss entirely. IGA's offboarding workflows can be sequenced to reflect the bottom-up order this checklist describes, handling ownership transfers and application-level revocation as defined steps before the identity provider account is touched, rather than defaulting to the intuitive but risky top-down order. Every step executes automatically and logs itself, so the sequencing discipline this checklist requires doesn't depend on an IT admin remembering the correct order under time pressure.
The Checklist Is Only as Good as Its Order
A list of what to revoke is necessary but not sufficient. The sequence matters just as much, because revoking the wrong thing first can lock you out of finishing the rest correctly. Bottom-up deprovisioning, application ownership and access first, identity provider last, is the order that keeps every subsequent step actually possible.
Frequently Asked Questions
Why shouldn't you disable the SSO account first when offboarding an employee?
Because for apps where the departing employee holds sole or primary administrative rights, disabling their federated login can also cut off the organization's ability to reassign that admin role or manage the app going forward. The identity account needs to stay active long enough to transfer ownership of anything it uniquely controls, before it's disabled.
What is bottom-up deprovisioning?
An offboarding sequence that handles application-level access, ownership transfers, and shared credential rotation first, while the departing employee's identity is still active and reachable, and disables the central identity provider or SSO account last, once nothing downstream still depends on that identity being valid.
How do you find out if a departing employee is the sole administrator of an app?
Through discovery that covers the full SaaS estate, not just apps connected through SSO. Sole administration issues most often arise with apps purchased outside formal procurement, precisely the apps a standard, federation-based inventory is least likely to include. Dedicated SaaS discovery tools can surface this ownership information more reliably than a manual review.
What happens if you disable an account before transferring app ownership?
Depending on the app, you may lose the ability to reassign administrative rights through normal means, requiring a support request to the vendor, proof of company ownership, and a delay that can leave the app effectively unmanaged in the meantime. This is the specific, avoidable failure that bottom-up deprovisioning is designed to prevent.
Does the deprovisioning order matter for every application, or just some?
It matters most for applications where the departing employee held sole or primary administrative rights, or where the app's SSO integration controls login but not the full underlying account. For apps with straightforward, replaceable user-level access and no ownership dependency, the order matters less, but since it's not always obvious in advance which category an app falls into, treating the bottom-up sequence as the default is the safer practice.
.svg)
