The Access Someone Keeps After They Leave

Disabling the email account takes a minute and everybody remembers to do it. What survives an exit is the access that never went through your directory at all. The tool signed up for on a personal card. The API key generated during a project. The shared login three people know. The mail profile still syncing to a phone you have never seen.

Most of it keeps working, not because anybody is being malicious but because nobody recorded it when it was created. Offboarding actually fails at the inventory stage, months before anyone hands in a resignation letter.

So this splits into two jobs. The list of things to remove, which is longer than most checklists admit. And the habit of recording access as it is granted, which is the only thing that ever makes the list complete.

The removal work is quick once the list exists. It is the hunting that takes a fortnight, and the hunting is what gets skipped when somebody leaves during a busy month.

You cannot remove access you never recorded, and asking the leaver is unreliable. They are not hiding anything. They simply do not remember the tool they signed up for during a project two years ago.

Pull from sources that keep their own records. The applications list in your identity platform. Sign in logs showing which services accepted this person's account. Their browser saved password list. Expense claims and card statements going back a year. Sign up confirmations sitting in their mailbox. And the list of third party applications that have been granted access to your mail and file platforms.

Then ask the team rather than the person. Colleagues doing the same job know which tools were really used and which shared logins circulate quietly. Ask what would stop working if this person's accounts vanished tonight, and you will hear about systems that appear on no list anywhere.

Write the result down as a permanent register rather than as a one off exercise for this departure. Every new tool gets an owner, a billing contact and a note of who has access. That register is what turns the next exit into a checklist instead of an investigation.

Disable the account. Resist deleting it on the last day, however tidy that feels. Deletion takes the mailbox with it, and with the mailbox go the rules somebody quietly set up, the colleagues they handed access to, and the record of what they opened in their final week. Delete it later, once you are sure nothing was left behind.

The full sequence is longer than most people run. Disable sign in. Reset the password to something nobody knows. Revoke every active session and refresh token. Remove the registered multi factor methods. Remove any application passwords. A password reset on its own leaves live sessions signed in and working.

Then the mailbox. Convert it to a shared mailbox so it stops consuming a licence, delegate it to their manager, and set an automatic reply pointing at a real person. Before you change anything, look at the existing forwarding rules and delegate permissions. A rule set up during the notice period is not unheard of and it is invisible once the mailbox is converted.

Then group memberships, distribution lists, calendar delegation, and anything they owned rather than merely belonged to. An orphaned group or a document library with no owner is what blocks somebody eighteen months later, at which point nobody remembers why.

Every business has tools bought on a card during a busy week. A design tool, a scheduling tool, a survey tool, a monitoring service on a free tier that quietly became load bearing while nobody was watching.

The pattern that hurts most is the account registered under a personal email address. When the person goes, the account is legally theirs, the billing follows them, and the password recovery route runs through a mailbox you do not control. Move ownership to a company address before the exit where you can, and open a support case with the vendor where you cannot.

For each tool, do four things. Transfer ownership. Change the billing contact. Remove their user account. Check whether any automation or integration was configured under their name, because integrations set up personally are the ones that break silently at three in the morning some weeks later. While you are in there, cancel what nobody uses. A departure is the one reliable moment when anybody audits software spending, and the same list serves both purposes without extra effort.

A mail profile on a personal phone holds a token, and a password reset does not reliably kill it. Some platforms drop the token as part of the reset and some leave it alone, so revoke the sessions and the refresh tokens deliberately rather than trusting the reset to have done it. Where somebody is still receiving mail months later, the cause is usually duller than a surviving token, and the forwarding rules and delegate permissions above are the first place to look.

Revoke at the identity platform rather than at the device, because you may never see the device. Sign out of all sessions, revoke refresh tokens, and remove the device from the registered list. Then check the sign in activity a day later to confirm it has actually stopped.

If work data lived inside a managed application container, issue a selective wipe of that container. If it did not, and mail was set up in the phone's own client, revoking the account is the whole of your control. Anything already cached stays on that phone. Say that plainly to whoever asks rather than implying you wiped something you did not.

The same holds for a home computer with a synced drive folder. Removing the account stops future syncing. It does not remove what already synced, and describing it otherwise in a note to a customer is how a small problem grows into a larger one.

Anything shared has to be rotated on departure. There is no record of who holds a shared password, and the person leaving is not necessarily the only one who passed it on.

The keys are the part most checklists miss entirely. API keys and personal access tokens they generated. SSH keys sitting in the authorised keys file on servers. Deploy keys in code repositories. Webhook secrets. Service account credentials created in their name. Certificates they requested. And any credential hardcoded into a script, which tends to be discovered later and in the worst possible circumstances.

Then the accounts that live outside your systems completely. The domain registrar. DNS hosting. The payment gateway. The app store publishing account. The bank. Cloud provider root accounts. Social media. These are usually held by one or two people, usually have no proper record, and are the ones with real commercial consequences.

For anything they administered, check for accounts they created for themselves. A second login under a slightly different name, made for convenience during a project, does not appear when you search for a leaver by name.

The honest position is that you will not get all of it back, and pretending otherwise helps nobody. What you can do is find out quickly what moved and decide whether it matters.

The signals worth checking in the final weeks and the days afterwards: bulk downloads from the file platform, large exports from the CRM, mail forwarding rules and automatic redirects, files copied to removable media where you log that, and sharing links created to external addresses. Most platforms record all of this. Very few businesses ever look.

Where something clearly moved, the response is a conversation with the leaver, a written request to delete it and confirm, and a note in the file. Where it involves customer or employee data, treat it as a potential incident and run the process you already have rather than inventing a quieter one for this occasion.

Most of this is contractual and cultural rather than technical. What the technology gives you is speed. Finding out on the Monday rather than in six months is the whole difference in how the situation gets handled.

The checklist should be triggered by HR rather than remembered by IT, and every line should carry a date rather than a general expectation of promptness.

Split it by urgency. On the last day: directory account, sessions, devices, building access, and the shared credentials they used daily. Within the week: software accounts, keys, ownership transfers and the rotation list. Within the month: tidying up groups, licences and whatever the review turned up.

Then run an access review on a fixed schedule whether or not anybody has left. Each system owner confirms who should have access to their system and signs it off. It is dull, it takes an afternoon, and it catches the accounts no offboarding checklist could ever have found because nobody knew they existed.

Finally, write the sudden exit version. A dismissal, a resignation that turns unpleasant, or a death in service all need the same steps in a compressed and reordered form, with the account suspended before the conversation happens rather than after it. Agree now, while everything is calm, who is allowed to authorise that.