Joiner, mover, leaver: the offboarding gap in most tenants

The three events, and which one actually hurts

A joiner needs provisioning. A mover needs their old access removed as well as their new access granted — this is the step most often half-done, because adding permissions solves the immediate problem and removing the old ones solves nothing anybody can see.

A leaver needs everything revoked. Not just the sign-in, which is the part everybody remembers, but the sessions, tokens, app passwords, device enrolments and any access granted outside the directory.

What disabling an account does and doesn’t stop

Disabling an account blocks new sign-ins. It does not immediately end sessions that are already active, and refresh tokens can keep an authenticated session working for a period afterwards unless they are explicitly revoked.

This is the gap that surprises people. An account can be disabled in the portal and still have a working mail client on a personal phone for some time afterwards. Revoking sessions is a separate action and it belongs in the process explicitly.

• Block sign-in and revoke active sessions and refresh tokens, not just the first
• Remove the account from groups that grant access, not only from the licence
• Check for mail forwarding rules created by the user before the mailbox is converted
• Wipe or retire company data on enrolled devices, and record which devices were in scope
• Reassign ownership of files, sites, flows and app registrations before the account is removed

The things that outlive the account

A departing person usually leaves artefacts that are not tied to their sign-in. A Power Automate flow running under their credentials. An app registration they created for an integration. A shared mailbox they were the only member of. A guest account in someone else's tenant.

These are the items that break months later, when the account is finally deleted and a process nobody knew existed stops running. Capturing them is part of offboarding, not a separate cleanup project.

Finding the ones you have already missed

Before automating anything, it is worth knowing the size of the existing backlog. Sign-in activity is the fastest way to find it: accounts that are licensed and enabled but have not signed in for ninety days are the shortlist.

Expect the list to include legitimate entries — seasonal staff, long leave, service accounts that authenticate differently. The point is not that every dormant account is a problem, it is that each one should have a reason, and the ones without a reason are the finding.

Making it hold

The durable fix is to stop treating leavers as an IT task triggered by an email. Where the directory can be driven from the HR record, the leaving date does the work and the process runs whether or not anyone remembers to raise a ticket.

Where that is not available, the achievable version is a written checklist with named ownership and a monthly review of dormant accounts. It is less elegant and it still closes most of the gap, which is the part that matters.

Questions we get asked