A device offboarding checklist for leavers

Why offboarding is the higher-risk half of the lifecycle

Onboarding failures are usually inconvenient; offboarding failures are usually a security exposure. An account left active after someone has left the organisation is not a hypothetical risk, it is a credential that nobody is watching, attached to a person with no ongoing obligation to the organisation. The same applies to a device that leaves the building and is never chased for return.

The fix is treating offboarding as a defined sequence with a hard deadline, triggered automatically by HR notification of a leaving date, rather than as a task that starts once someone in IT happens to notice the person has gone.

Access revocation on the last working day

Access revocation should be scheduled to take effect on, or before, the person's last working day, not some point afterwards. That includes disabling the primary account, revoking any active remote access sessions, removing multi-factor authentication devices tied to the account, and reviewing every third-party or cloud service accessed through single sign-on, since these are the accounts most likely to be forgotten.

Where the leaver had elevated or administrative access, that revocation is more urgent still and should happen first. It is worth keeping a short standing list of every system a role typically has access to, so revocation does not rely on someone remembering each one individually.

• Primary directory account disabled (not deleted immediately, in case of legal hold or handover needs)
• Active remote access and VPN sessions terminated
• MFA devices and app-based authenticators removed from the account
• Third-party and single sign-on linked accounts reviewed and revoked
• Shared mailbox and distribution list membership removed
• Administrative or privileged access revoked first, and separately confirmed

Recovering the hardware

Device recovery is a logistics task as much as a security one, and it needs a clear owner. For an office-based leaver, recovery on the last day is straightforward; for a remote worker, it needs a courier process with a tracked return and a follow-up date if the device is not received. Chasing a laptop that has not come back should be someone's explicit responsibility, with an escalation point if it drags on.

Where a device cannot be recovered, such as a lost or stolen laptop, the response should shift immediately to remote wipe where the device supports it, and confirmation that disk encryption was active, which limits what is actually exposed.

Data retention and device disposal

Before a returned device is wiped, decide what happens to the data on it. Some organisations retain a backup of a leaver's local files for a defined period in case of handover disputes or legal need; others wipe immediately once any required files are confirmed moved to shared storage. Either is defensible, but it should be a decision made in policy, not improvised device by device.

Once retention requirements are satisfied, the device should be securely wiped to a recognised standard, then either redeployed to a new starter or disposed of through a certified IT asset disposal process, with a certificate of destruction retained for any device holding sensitive data.

Closing the loop in the asset register

The final step is updating the asset register to record what happened to the device: returned and redeployed, returned and disposed of, or not recovered, with the date and the name of whoever handled it. This is what makes the asset register trustworthy the next time someone needs to answer 'who has this device' without guessing.

It is worth a brief periodic reconciliation between HR leaver records and the asset register and identity system, to catch any offboarding step that was missed rather than relying on the individual checklist run being perfect every time.