IT Offboarding Checklist: The Accounts, Devices, and Access to Revoke

An IT offboarding checklist covers five things: disable the primary identity account at an agreed time on the last working day, revoke credentials and tokens that live outside it, transfer ownership of files and shared resources before anything is closed, recover every issued device, and record what was done so it can be proved later. The step that fails most often is the second one, because single sign-on handles the obvious accounts and quietly leaves the ones nobody registered.

That is the short version. The longer version matters because the accounts that survive an offboarding are never the ones on the list. They are the tool a manager expensed on a company card two years ago, the shared login in a spreadsheet, the API key wired into an automation that still runs, the admin seat on a vendor portal that only one person ever had. Here is the full checklist, the reason each item is on it, and how to stop rebuilding the list from memory every time someone resigns.

What IT offboarding covers, and where it stops

IT offboarding is the technical half of a wider process. The HR half handles the written confirmation, the final pay, the benefits notifications, and the records retention, and it runs on statutory deadlines. The IT half handles identity, data, and hardware, and it runs on a single deadline that everybody agrees on in advance: the moment access ends. Both halves are covered end to end in our employee offboarding checklist. This article is the deep version of the IT part.

The split matters because the two halves fail differently. HR failures announce themselves: a late final paycheck generates a phone call, a missed benefits notice generates a complaint. IT failures are silent. An account left open produces no alert, no invoice, and no complaint. It just sits there, valid, belonging to somebody who no longer works for you, until either nothing happens or something does.

The IT offboarding checklist

Work through this in order. The sequence is deliberate: transfer before you disable, disable before you delete, and log everything as you go.

Step	What it covers	When
1. Inventory	Every account, device, license, and access right issued to this person	As soon as notice is confirmed
2. Transfer ownership	Files, drives, docs, calendars, repositories, automations, admin roles	Before any account is disabled
3. Disable identity	SSO or directory account, email, VPN, MFA enrollments	Agreed time on the last working day
4. Revoke what sits outside SSO	Standalone SaaS logins, API keys, tokens, shared credentials, vendor portals	Same day as step 3
5. Recover devices	Laptop, phone, peripherals, security keys, badges	Last day, or a shipping deadline for remote staff
6. Handle the mailbox	Forwarding or auto-reply, then convert or archive per retention policy	Last day, then per policy
7. Reclaim licenses	Paid seats released or downgraded across every subscription	Within the billing cycle
8. Record it	What was disabled, when, by whom, and what was recovered	As each step completes

Step 2 before step 3 is the ordering people most often get backwards, usually under time pressure. Disable the account first and you have locked the organization out of its own documents, and recovering them ranges from tedious to impossible depending on the platform. Transfer first, verify the transfer landed, then disable.

The accounts single sign-on does not cover

If your identity provider is well configured, the first ninety percent of this is one click. The problem is that the click gives you a feeling of completeness that the last ten percent does not deserve. These are the categories that consistently sit outside it:

• Tools bought on a card, not through IT. Someone needed a transcription service or a design tool, expensed it, and never told anyone. It has its own login and its own password.
• Shared credentials. The social account, the registrar login, the utility portal, the one bank view that only ever had one seat. If the departing person knew the password, the password has to change, not just their access to it.
• API keys, tokens, and service accounts. Personal access tokens created for a script that is still running in production. Revoking these can break things, which is exactly why they need to be found before the last day rather than after.
• Vendor and partner portals. Support consoles, cloud billing accounts, insurance and payroll providers. These are often the highest-privilege access a person holds and the least likely to be in any directory.
• Second factors registered to the person. A phone number or authenticator app tied to a shared account means the account is still reachable through someone who left.
• Forwarding and delegation rules. A mail rule quietly copying messages elsewhere survives the account being disabled in more setups than people expect. Check for them before you close the mailbox.
• Physical and building access. Badges, fobs, door codes, and alarm codes. If a code is shared, rotate it rather than deleting a user.

The honest way to find these is not to interrogate the departing employee on their last afternoon. It is to keep the list current from the day they joined, which is why the IT half of employee onboarding and the IT half of offboarding should be maintained as one document. Every time you grant something, you write it down; the offboarding list is then just that record, read in reverse. Where no such record exists, you are reconstructing it, and the practical starting points are the subscription billing, the expense reports, and a systematic sweep to map where a person's data actually lives across your systems rather than guessing from the tools you remember buying.

What the security standards actually require

This is not just good hygiene, and it is worth knowing the language if you are ever asked to evidence it. NIST SP 800-53 Rev 5 control PS-4, Personnel Termination, states that upon termination of individual employment an organization should disable system access within an organization-defined time period, terminate or revoke any authenticators and credentials associated with the individual, conduct exit interviews that include a discussion of defined information security topics, retrieve all security-related organizational system-related property, and retain access to organizational information and systems formerly controlled by the terminated individual.

Three things in that are worth pulling out. First, the standard expects you to define the time period, which means an unwritten "pretty soon" is not a control. Pick a number, write it down, and hold to it. Second, credentials are named separately from access, because revoking a login does not revoke a token. Third, the final clause is about retention, not removal: the organization has to keep what the person controlled. That is the step-2-before-step-3 rule stated as a requirement.

Getting the timing right

Revocation timing is a coordination problem, not a technical one. Cut access before the manager has had the conversation and you have told someone they are fired via a login screen. Cut it days later and you have a live credential belonging to a former employee.

The workable answer is to fix the exact time during the first phase of the process, when the departure is confirmed, and treat it as a scheduled event with a named owner rather than a task somebody eventually gets to. For a resignation with notice, that is usually the end of the last working day. For an immediate termination, IT, HR, and the manager agree the sequence down to the hour beforehand, and IT acts on a signal rather than on a guess. Write the sequence into a standard operating procedure once and it stops being renegotiated under pressure every time. If you have never captured a process this way, the seven-step method for documenting a process is a 45-minute job for something this well bounded.

Devices, data, and the mailbox

Device recovery is mostly logistics, and it is only hard when it was not planned. Log what was issued at onboarding and the return list writes itself. For remote employees, agree the shipping arrangement and a deadline in writing before the last day, and send the label rather than asking someone to arrange it themselves. If devices are managed, confirm the remote wipe or lock actually reported success instead of assuming the command was enough.

The mailbox deserves its own decision because it is both a business record and a live channel. The usual sequence is to disable interactive sign-in, keep the mailbox reachable so client mail is not bounced, forward or delegate it to a named colleague, and then archive or convert it to a shared mailbox under your retention policy. What you should not do is delete it quickly. Mail is frequently the only place a commitment to a customer or a supplier was ever recorded, and its absence is discovered at the worst possible moment.

Reclaiming licenses is the part that pays for the process

Every disabled account usually maps to a paid seat, and seats do not release themselves. Sweep the subscriptions after each departure and either release the seat or downgrade the plan before the next billing date. In an organization with any turnover this is the one item on the checklist with a direct, measurable return, and it is routinely the item that never happens because nobody owns it. Attach it to the offboarding process rather than to a quarterly finance review, and check the renewal terms while you are there, since some contracts only allow seat reductions at renewal. Software subscriptions are vendors like any other, so the renewal dates and seat counts belong on the same review cadence as the rest of your vendor management process.

Frequently asked questions

What is IT offboarding?

IT offboarding is the technical part of separating a departing employee: transferring ownership of their files and shared resources, disabling their identity account, revoking credentials and tokens that sit outside single sign-on, recovering issued devices, handling the mailbox under a retention policy, reclaiming paid licenses, and recording what was done. It runs alongside the HR process, which handles pay, benefits, and records.

What should be on an IT offboarding checklist?

An inventory of every account, device, and access right; transfer of file and resource ownership before anything is disabled; disabling the identity, email, and VPN accounts; revoking standalone SaaS logins, API keys, tokens, shared credentials, and vendor portal access; recovering all hardware and security keys; a mailbox forwarding and archiving decision; license reclamation; and a written log of each action with a timestamp and an owner.

When should you revoke a former employee's access?

At a time agreed in advance with HR and the manager, usually the end of the last working day for a resignation, or immediately after the termination conversation for an involuntary departure. The important part is that it is a scheduled event with a named owner rather than an open task, since revoking too early pre-empts the manager and revoking too late leaves live credentials with a former employee.

Why do former employees still have access after offboarding?

Almost always because the account was never in the identity provider. Single sign-on covers the accounts IT provisioned, so what survives is everything else: tools bought on a company card, shared logins, personal API tokens wired into running automations, admin seats on vendor portals, and second factors registered to a personal phone. These are found by keeping an access record from the day someone joins, not by recalling them on the last day.

Should you delete or disable a former employee's account?

Disable first, and delete only later under a written retention policy. Disabling stops access immediately while preserving the data, the mail, and the audit trail. Deleting early can remove business records you are required or likely to need, and on some platforms it also destroys files the account owned. Transfer ownership of everything the account holds, disable it, then delete on schedule.

Who is responsible for IT offboarding?

IT owns the execution, but it depends on HR for the leaving date and on the manager for the timing and the handover list, which is why this process breaks at the handoffs rather than at any single step. The fix is one checklist with a named owner per line and a single trigger event, rather than HR, IT, and the manager each keeping a separate list and assuming the others are done.