A checklist that disables the main account can still miss groups, connected applications, service integrations, API keys or tenant administration. The risk is not only a malicious former employee; it is an orphaned credential that remains valid because no process owns it.
Start with an access inventory
Include direct roles, inherited group permissions, application assignments, active sessions, API keys, tenant memberships and credentials created for integrations. Record which controls are automated and which depend on a person. A central identity record helps, but it may not show every downstream grant.
Reconcile the identity provider’s view with the systems that consume its decisions. Flag integrations that lack a reliable deprovisioning signal or depend on a human to clean up access. Those gaps should remain visible after the offboarding ticket is closed.
Remove authority in a safe order
Some access can be disabled immediately; other changes require a planned transfer. A production automation account should not be tied invisibly to a departing individual’s personal credential. Move legitimate workloads to an owned service identity, then verify the old token no longer works.
Revoke sessions and long-lived credentials according to policy. For sensitive roles, consider whether the departure should trigger a review of recent activity, related credentials or delegated permissions. The sequence must protect the organisation without leaving critical services dependent on the former employee.
Prove the outcome, not just ticket closure
A ticket marked “complete” records a workflow state, not necessarily the security result. Capture what was revoked, what could not be removed automatically, who accepted the exception and when follow-up is due. Unresolved access should not disappear into a closed request.
Test the former identity against representative paths: sign-in, application launch, API use, administrative pages and tenant-scoped operations. Confirm that sessions and tokens stop working where revocation is expected to invalidate them.
Make exceptions accountable
Some grants legitimately survive a staffing change because they belong to a workload or continuity process. Transfer ownership, document the reason and review the permissions. Avoid retaining personal access because it is operationally convenient.
Repeated manual cleanup often points to an architecture gap: a missing provisioning integration, an unclear resource owner or a service identity that should exist. Offboarding is both a security control and a diagnostic for identity governance.
Four questions for your stack
Inventory direct and inherited access, sessions, tokens and tenant memberships?
Transfer legitimate automation to service identities before removing personal access?
Record unresolved exceptions with an owner and deadline?
Test that removed access no longer works downstream?