Security

IT offboarding checklist: how a leaver's account becomes a breach

Every IT offboarding checklist exists because of the same incident, repeated endlessly: months after someone leaves, one of their accounts logs in. Surveys keep finding that around one in four ex-employees can still access something they should not, and a meaningful share of breaches trace straight back to a departure that was never fully closed out. This is a post-mortem of that incident, whether you run IT in-house or look after other businesses' estates, and the checklist that stops it happening to you.

Six months after the leaving card, a login

The incident almost always looks the same. Someone left in the spring: a sales manager, a contractor, a systems administrator. There was a leaving card, a handover document that was mostly links, and a ticket that said "please disable Jane's account", which somebody did. In the autumn, something odd surfaces. A customer list turns up at a competitor. A mailbox rule is quietly forwarding invoices. A VPN session appears from an IP address nobody recognises. The sign-in logs are checked, and there it is: a live login from an account belonging to a person who has not worked there for six months.

Sometimes the leaver themselves is behind it, and disgruntled-insider cases make the headlines because they end in court. More often it is worse in a mundane way: the credentials were reused somewhere that got breached, and an attacker simply tried them everywhere. The account they landed in had no active human watching it, no manager noticing odd behaviour, and often no MFA, because the phone that held the authenticator was handed back months ago while the account stayed live.

The immediate reaction is always to ask who forgot. That is the wrong question, and it is why the incident recurs. Nobody forgot. Everybody did exactly what the process asked of them. The process asked for the wrong things.

Tracing it back: the trigger lived in the wrong department

Run the post-mortem honestly and the first root cause is almost never technical. It is organisational: leaving a company is an HR event, but access is an IT asset, and in most businesses there is no reliable wire connecting the two. HR processes the departure for payroll and paperwork on their timeline. IT finds out by email, by corridor, or occasionally not at all. If you are an MSP, add another hop: your client's HR tells your client's office manager, who may or may not tell you, days later.

So the first failure is the trigger. The ticket that says "disable Jane's account" arrives late, or never, and its timing depends on someone remembering to send it. For resignations with notice that is sloppy; for terminations it is dangerous, because the highest-risk departures are exactly the ones where access must end at the moment the person is told, not at the end of a payroll cycle.

The second failure is the wording. "Disable the account", singular, reflects a mental model in which a person has one account. That was true in 2005. Today the directory account is one door among many, and disabling it closes the biggest door while leaving the side doors not just unlocked but unwatched. The ticket got closed because the thing the ticket named got done. The gap between "the ticket is closed" and "the person has no access" is where the breach lives.

One leaver, a dozen doors

Inventory what a typical employee actually accumulates and the singular "account" becomes obviously inadequate. A leaver commonly walks away still holding some of these:

• SaaS accounts outside single sign-on. The design tool, the expenses app, the CRM seat someone bought on a card. If it was set up with an email address and a password rather than through your identity provider, disabling the directory account does not touch it.
• Active sessions and tokens. Disabling an account stops new logins. Sessions already open on a home laptop, and refresh tokens on a personal phone, can keep working for hours or days unless you revoke them explicitly.
• Mailbox rules and forwarding. A forwarding rule set up years ago, legitimately or not, keeps forwarding after the person leaves. Our Microsoft 365 security checklist covers why forwarding deserves standing scrutiny; offboarding is the moment it bites.
• Shared credentials. The router password, the social media logins, the admin account "everyone" uses. You cannot disable knowledge. Anything the leaver knew has to be rotated, and first you have to know what they knew.
• Remote access. VPN certificates, remote desktop gateways, remote support tools installed during some old troubleshooting session. These are the doors attackers like best, because nobody watches them.
• Devices and data. The laptop in a cupboard at their house, the phone with company email on it, the personal OneDrive the handover files got synced to in the final week.
• Keys they created. Especially for technical leavers: API keys, service account passwords, automation credentials made under their own identity years ago and still in production.

This is the third root cause: the only complete map of a person's access existed in that person's head, and it left when they did. No checklist fixes that on the last day. The fix is keeping the map continuously, which is an inventory problem, not an offboarding problem.

The IT offboarding checklist, in three passes

A checklist that actually prevents the incident is structured by time, because the actions have different deadlines. One pass on the last day is not enough; three passes are.

Before the last day

• Open the offboarding ticket the moment the departure is confirmed, not when it takes effect.
• Build the access map: assets assigned, group memberships, admin roles, SaaS seats, shared credentials known, API keys and service accounts created.
• Agree data handover with the manager: which files, which mail, who inherits what.

Day zero: the last day, or the moment of termination

• Disable the identity in Microsoft Entra ID or Active Directory, and revoke all active sessions and refresh tokens, not just future logins.
• Remove MFA methods and app passwords registered to the account.
• Disable VPN and remote access, and uninstall or disable remote support tools on their devices.
• Rotate every shared credential on the access map.
• Recover the hardware, or remote wipe what does not come back the same day.

The first week and day 30

• Convert the mailbox to a shared mailbox or delegate it. Review it for forwarding rules before anyone relies on it.
• Transfer file ownership, reclaim licences, remove the account from distribution lists and Teams.
• Close SaaS accounts outside SSO, and rotate any API keys and service credentials the leaver had reach into.
• At day 30, verify: check sign-in logs for any successful authentication since day zero, sweep SaaS billing and the password manager for accounts you missed, then archive or delete per your retention policy.

The change that prevents it: a trigger, an owner, and proof

The checklist above is necessary but not sufficient, because the original failure was not a missing list. It was a missing trigger, a singular mental model, and a map that lived in someone's head. The preventive change has three parts, and none of them is glamorous.

First, wire the trigger. Departure confirmed in HR must create the IT offboarding ticket automatically, or by an agreed same-day handoff that someone is accountable for. If you are an MSP, put this in the contract: the client notifies you of leavers within one working day, and immediately for terminations. Then measure it. Time from departure to identity disabled is the one metric that predicts whether this incident can happen to you, and for privileged accounts the acceptable answer is minutes.

Second, give every departure a named owner who closes the ticket only when every task is done, not when the biggest one is. The checklist lives as tasks in the ticket, each with evidence attached: the disabled state, the wipe confirmation, the rotation record. "Done" becomes checkable by someone else, which is the entire point of a checklist.

Third, verify with data rather than memory. The day-30 log review catches what the last day missed. A quarterly sweep comparing your directory and your asset inventory against the actual list of current staff catches what day 30 missed. Stale accounts are findable by machine: no sign-in for 45 days, licence still assigned, owner not in payroll. If your tooling keeps a live inventory of users, devices and installed software, that sweep is a saved report, not an afternoon. And the same discipline applies at bigger scale when an entire client relationship ends; our client offboarding checklist is the estate-sized version of this article.

Do these three things and the opening incident becomes structurally difficult. The account is disabled the day the person leaves because the trigger fired. The side doors are closed because the map existed before the last day. And anything that slipped through is caught within a month by a review that looks at logs, not at recollections.

Where this fits with Helios

Helios does not do your offboarding for you, but it removes the two ingredients the incident depends on: the missing map and the missing verification. The asset inventory ties devices, installed software and users together, so "what did they have" is a lookup rather than an archaeology project. The Microsoft 365 integration surfaces account and licence state alongside the endpoint view, ticket checklists give each departure an owner and an evidence trail, and Helio can flag the pattern that should never occur: activity attributed to a user the estate no longer contains.