Skip to content
Let’s talk
GREY WING SECURITY
All guides
Guide
Corporate security

Employee Offboarding Checklist: Remove Access the Same Day

Cut sign-in, keep the data and legal holds, close the accounts single sign-on does not reach, recover devices, and keep a dated record of each step.

Updated 10 min read

At a glance

Who it is for
Whoever runs IT at a company of 10 to 200 people, plus the HR or ops lead who tells them someone is leaving.
Time needed
A few hours to build the system list and checklist the first time, longer if many apps sit outside single sign-on. After that, each departure runs from the same ticket.
What you end up with
A reusable offboarding ticket, a list of every system that needs a step, and a dated record for each person who leaves.

When someone leaves, their accounts do not leave with them. A forgotten admin login or an old API key can stay live long after the person is gone.

NIST lists the basics in control PS-4, Personnel Termination. Disable system access within a set time. Revoke the person's credentials. Get company property back. Keep access to the information they controlled. This guide turns that list into a ticket you can run the same way every time.

1. Build the system list once

You cannot remove access you do not know about. Before the next departure, list every system with its own login.

  • Start with the app list in your identity provider, such as Okta, Google Workspace, or Microsoft Entra ID.
  • Add the apps that sit outside single sign-on. Check your password manager's shared folders and the software charges on company cards.
  • Add the places people get keys and tokens: cloud consoles, code hosting, CI tools, and anything that issues API tokens.
  • Name an owner for each system. The owner is the person who can remove a user from it.

Save the list as a template ticket. Each row is one system, its owner, and a box to tick with a time.

2. Agree on the trigger and the time

Agree on the handoff in advance, so IT never hears about a departure after the fact.

  • Agree that HR or the manager opens the ticket as soon as a last day is set.
  • For a planned exit, schedule the cutoff for the end of the last working day.
  • For an exit the person does not see coming, block sign-in, end sessions, and revoke their keys and tokens before or during the conversation. Then do step 3, and deactivate only after it is done (see step 4).
  • Write down who can approve an exception, such as a contractor who stays on for a week.

Do this before you deactivate, deprovision, or delete anything. In Okta, deactivating a user deprovisions them from each app where deprovisioning is turned on, so check what each connected app does on deprovision. If Okta provisions Google Workspace, deactivating in Okta suspends the Google user by default; your settings can instead leave the Google account active, or remove its licenses and roles. Google warns that removing a user's license can lose their data, and suggests archiving the user instead. In Entra ID, if you use app provisioning, check what it does when the account is disabled. Microsoft recommends setting it to deprovision or deactivate users in those apps.

Then move what the team still needs to a new owner, and confirm any legal holds.

  • Google Workspace. Transfer Drive files to another user. Google warns that data you do not transfer is deleted with the account, and that a deleted user can only be restored for 20 days. If you need to keep the data longer, Google says you can suspend or archive the user instead. If you use Google Vault, deleting the user ends any holds or retention rules on their data, and the data can be purged right away.
  • Microsoft 365. Microsoft's former employee steps cover saving the mailbox, forwarding mail or converting it to a shared mailbox, and giving another user access to OneDrive. After you delete the account, OneDrive and Outlook content is kept for 30 days.

Then forward email or set an auto-reply, so customers who write to the old address still reach someone. Also remove any forwarding rules the person set up, and any mailbox or calendar delegates they added or held.

4. Block sign-in, then deactivate

The identity provider is the front door. Block it first, keep the data, then deprovision.

  • Okta. Suspending a user blocks sign-in and ends their Okta sessions right away. Suspend keeps app assignments (and admin roles), so it does not deprovision anything. Once step 3 is done, deactivate the user. That ends their access to assigned apps, and deprovisions them from apps where deprovisioning is turned on.
  • Google Workspace. Suspend the user. Google says that for a suspended user, Gmail, Drive and other Workspace services are unavailable. Google's checklist for a departing employee also says to revoke app passwords, security keys, and OAuth access, and to remove their recovery email and phone.
  • Microsoft Entra ID. Disable the account, revoke its sign-in sessions, and disable its registered devices. Revoking blocks new tokens, but an access token already issued can keep working until it expires, by default for up to about 90 minutes. Microsoft's token lifetimes page says a default access token lasts a random 60 to 90 minutes (75 on average), and its revoke-access page rounds this to about an hour. Apps that support Continuous Access Evaluation can cut access off in near real time.

On day one, work in this order:

  1. Block sign-in and end sessions now. In Okta and Google Workspace, suspend the user, and in Google Workspace also revoke their app passwords, security keys, and OAuth access, and remove their recovery email and phone. In Entra ID, disable the account and revoke its sessions. Know in advance which apps Entra ID provisions and what disabling does in each (note it on your system list), since disabling can deprovision them (step 3). Revoke their keys and tokens at the same time (step 5), because suspending does not deprovision anything and keys outlive sign-in.
  2. Put the data transfer and legal holds from step 3 in place.
  3. Deactivate the user in Okta. Do not delete the account yet.

In Okta, suspending or deactivating may not end sessions an app already issued. Okta notes that the app session can outlive the IdP session. Neither one stops sessions, passwords, API keys, or tokens that an app issued itself, outside your identity provider; revoke those in each app (step 5).

5. Close what single sign-on does not reach

Microsoft's own guide says Entra ID cannot directly revoke a session token issued by an application. The app has to end it. So a disabled identity account does not always end an open session in every app. Work down your system list and check each one.

  • Apps with their own username and password
  • Shared and break-glass passwords the person could see or hold, including emergency admin accounts and their MFA devices. Rotate them in your password manager.
  • Cloud console users, access keys, and roles they could assume
  • Personal access tokens, API keys, and SSH keys they created
  • OAuth apps they authorized against company data
  • Code hosting. When you remove someone from a GitHub organization, they lose access to private forks of its private repos, but they may still have local copies, and forks held in other organizations can stay reachable. Also remove them as an outside collaborator on any repo, and remove deploy keys and apps they added.
  • Admin roles, billing owners, and domain, DNS, or registrar accounts
  • VPN, Wi-Fi, door badges, and on-call or paging tools
  • Access to customer, partner, and vendor systems: accounts they hold in a client's environment, delegated admin rights, and vendor portals. Ask each owner to remove them and confirm in writing.
  • Company social media accounts and any card issued in their name

If a key was used by a running system, replace it with a new key owned by a team account. Do not leave the old one in place because something depends on it.

6. Get devices and hardware back

  • Collect the laptop, phone, security keys, and badges.
  • If a device does not come back, lock or wipe it through your device management tool.
  • Before you reissue a laptop, wipe it and reinstall it. Do not hand it to the next person as it was.

7. Check the work and close the ticket

A week later, take ten minutes to check.

  • Look at the identity provider's sign-in log for the account, and the last-used date on any cloud keys or tokens they had. There should be no successful sign-ins or key use after the cutoff.
  • Spot-check two or three systems from the list to confirm the account is gone.
  • Close the ticket with the time each step was done.

That ticket is the evidence. When a customer review or an auditor asks how you remove access, you show the template and a few closed tickets. Your quarterly access review then catches anything the ticket missed.

Role changes count too

People who change teams keep old access unless someone removes it. Run the same list when a role changes. Add the new access the person needs, and remove what the old role needed and the new one does not.

The checklist

Copy this into your ticket template.

  • Ticket opened by HR or the manager, with the last day and cutoff time
  • At the cutoff: sign-in blocked and sessions ended (suspended in Okta and Google Workspace, disabled with sessions revoked in Entra ID), and Google app passwords, security keys, connected-app access, and recovery email and phone removed
  • Keys and tokens revoked or moved to a team account
  • Files and mailbox moved to a new owner, Vault or legal holds confirmed, and each connected app's deprovision behavior checked, including apps Entra ID provisions
  • After the data step: user deactivated in Okta, and the account kept for now
  • Each system on the list checked and access removed
  • Shared and break-glass passwords rotated
  • Access to customer, partner, and vendor systems removed and confirmed by each owner
  • Devices, keys, and badges returned, or wiped remotely
  • Sign-in log checked after the cutoff
  • Ticket closed with a time for each step

Where Grey Wing fits

In the IT Program, we build the system list and the offboarding checklist with you, and our team runs it for each departure in your identity provider and device management tool. If you want help setting it up, Let’s talk.

Sources

Not sure where to start?

Tell us about your systems and deadline. We’ll reply within one business day.

From the blog

Corporate security

MFA rollout that actually sticks

The implementation sequence we use to get MFA coverage to 100% without organizational revolt.

1 min read