Secure offboarding in Microsoft 365: a checklist for employee departures

By Kike Gandia · Co-Founder & CEO, OSCP

A poorly managed former-employee account in Microsoft 365 keeps access to email, files and federated applications long after the person has left, if the offboarding process is limited to disabling sign-in. This checklist covers the secure offboarding of an employee in Microsoft 365, step by step.

Block sign-in and revoke active sessions immediately

The first step is to block the account's sign-in and explicitly revoke all active sessions and refresh tokens. Blocking sign-in alone doesn't close already-open sessions: a valid token can keep granting access for hours if it isn't explicitly revoked. This step must run on the same day as the departure, not in the next maintenance cycle.

Review forwarding rules, mailbox delegations and OAuth apps

Before assuming the account is isolated, check whether the user configured automatic forwarding rules in Exchange, whether they delegated mailbox access to someone else (a delegation that can survive the departure), and which third-party OAuth apps have consent over their account. Any of the three can keep an access channel to the account's information even with sign-in blocked.

Transfer the mailbox, OneDrive and Teams ownership

Convert the mailbox to shared or transfer it to a manager so no business-relevant email is lost, and transfer OneDrive file ownership to a manager or another location using Microsoft's migration tool. Also review Teams teams and channels where the user was the sole owner: without a prior transfer, those teams can end up with no administrator after the departure.

Revoke devices and licenses, and apply retention

Unlink or remotely wipe managed devices associated with the account (Intune), remove the user from all security and distribution groups, apply the applicable retention policy (with Purview if relevant) and, finally, free up the Microsoft 365 license. Document every step: it's the evidence you'll need if a dispute or later investigation arises.

Check what the account left behind outside the mailbox

Mail and files are the visible part of the trail an employee leaves in Microsoft 365, but they are rarely the part that causes problems months later. Before closing the offboarding, review what that identity built inside the tenant.

What usually turns up: app registrations or service principals created by the user, with their own secrets that remain valid even though the account is blocked; Power Automate flows and Power Apps they owned, which either stop working and break a business process or keep running under their identity; role assignments in Azure subscriptions that appear in no Microsoft 365 report; credentials stored in a Key Vault only they accessed; and devices registered in Entra still listed as theirs.

What survives blocking sign-in

This is the table worth having in front of you when closing an offboarding, because almost everything on it is assumed to be handled and is not.

FAQ

Is disabling the account in Entra ID on the departure date enough?

It's not sufficient on its own. Disabling the account blocks new sign-ins, but doesn't revoke already-active sessions and tokens, and doesn't remove forwarding rules, delegations or OAuth app consents that can keep access independent of the password or account state.

What if the employee had a Conditional Access exclusion of their own?

You need to review and remove any Conditional Access exclusion associated with the account as part of offboarding, because a forgotten exclusion can leave that identity without the MFA or managed-device protections that apply to the rest of the organization.

When do I convert the mailbox to shared and when do I transfer it?

Converting to shared makes sense when the address still receives business mail somebody must handle: customers, suppliers or a functional alias. Transferring the content to a manager fits better when what matters is the history and the address can cease to exist. What to avoid is the de facto third option: leaving the mailbox intact with the account blocked and nobody owning it, which is how dead identities with live data accumulate.

Does a shared mailbox consume a license?

It depends on the mailbox size and on whether features requiring a license apply to it, such as certain retention or archiving policies. The check is quick and worth doing before converting mailboxes in bulk, because the expected savings from freeing licenses can evaporate if the shared mailboxes end up needing one anyway.

How do we manage this with many departures a year?

By hand it stops being viable quickly, and the failure is one of design rather than diligence: a nine-step checklist executed by different people always misses one. The sensible route is automating the sequence with Graph and PowerShell, leaving a record of each step, and reserving manual intervention for the decisions that genuinely need judgment: what happens to the mailbox, who inherits the Teams teams and which flows need transferring.

What if there is an open investigation or claim?

Then the order changes: before transferring, converting or deleting anything, apply the corresponding hold over the mailbox and OneDrive. Transferring ownership or deleting the account alters the state you would later have to account for. Once the hold is in place, the rest of the checklist runs as normal, but with the guarantee that the original content is preserved.

Related service

Microsoft 365 security audit

Related content

• Malicious Exchange forwarding rules
• Secure offboarding in Google Workspace
• Microsoft 365 hardening checklist

Sources

• Microsoft — Remove a former employee from Microsoft 365
• CIS Microsoft 365 Benchmark
• Microsoft — Revoke user access in an emergency
• Microsoft — Create eDiscovery holds in Purview

Request a Microsoft 365 audit