Audit-Proof M365 User Offboarding Checklist

A Microsoft 365 user offboarding checklist that produces evidence at every step — sign-in block, session revocation, MFA removal, mailbox, and the long tail.

Most MSPs can offboard a Microsoft 365 user. Almost none can prove they did, a year later, to an auditor's satisfaction. This distinction is the whole game, and practitioners know it:

"We disable sign-in, revoke sessions, remove licenses, strip roles, convert mailbox, etc… but at the end of the day the 'proof' is basically just ticket notes and screenshots."

— r/msp, February 2026

Ticket notes and screenshots are actually the right raw material — the problem is that they're unstructured. Nobody can tell whether the screenshots cover every step for every departed user, or just the steps someone remembered that day. The fix isn't software. It's a checklist where every step defines the artifact it produces, plus a ledger that indexes those artifacts per user.

Here is that checklist, in execution order, with the evidence each step files.

Step 1 — Cut authentication first (the first fifteen minutes)

Order matters here more than anywhere else. Everything else can wait an hour; live sessions can't.

1. Block sign-in. Microsoft 365 admin center → user → Block sign-in (or in Entra, set account status to disabled). This stops new sign-ins only — existing sessions keep working until their tokens expire, which is why the next two steps exist.
2. Reset the password to a long random value nobody records. Kills cached credentials on devices and anything doing legacy authentication.
3. Revoke sessions. Entra admin center → user → Revoke sessions, or Revoke-MgUserSignInSession in Graph PowerShell. This invalidates refresh tokens. Where Continuous Access Evaluation applies — Exchange Online, SharePoint Online and Teams with current clients, on by default in newer tenants — revocation propagates as a critical event and access drops within minutes. Everywhere else, already-issued access tokens survive until they expire, typically 60 to 90 minutes, so an app may keep working briefly after revocation. Brief is expected; an hour later still working means CAE isn't covering that app, and it's the sign-in test in Step 6 that catches it.
4. Delete registered MFA methods. Entra → user → Authentication methods → delete each registered method individually. Note what "Require re-register MFA" does not do: on its own it does not remove FIDO2 security keys, passkeys, Windows Hello for Business, or certificate-based methods — a hardware key the user registered would survive it. Delete the methods; confirm the list is empty.

Evidence: one screenshot of the blocked account status, one of the empty authentication-methods list, and the PowerShell transcript of the revocation. Timestamped filenames, attached to the offboarding ticket.

Step 2 — Strip authorization

5. Remove admin roles and group memberships. Export the user's role assignments and group list before removing them — that export is your before-state evidence, and it's also the list a re-hire or replacement will need.
6. Check for sole-owner problems. Any Microsoft 365 Group or Team where this user is the only owner needs a new owner assigned now, or the group becomes unmanageable-by-anyone except admins.
7. Remove mailbox delegations pointing the other way. If the departing user had Full Access, Send As, or Send on Behalf over other mailboxes, remove those grants (Get-MailboxPermission / Get-RecipientPermission filtered to the user). These survive as orphaned ACLs if you skip them.

Evidence: the role/group export CSV, plus a screenshot per ownership transfer.

Step 3 — Mailbox disposition

The order here saves licenses and prevents data loss:

8. Convert the mailbox to shared (Exchange admin center → mailbox → Convert to shared mailbox) while the user is still licensed. After conversion, the license can be removed — a shared mailbox under 50 GB needs no license, but one over 50 GB, or one with an In-Place Archive or litigation hold, still requires one — an Exchange Online Plan 2 license, or Plan 1 with the Archiving add-on.
9. Set the auto-reply and forwarding per the client's instruction — in writing. Who receives this person's mail is a business decision, not a tech's judgment call.
10. Decide retention explicitly. If the mailbox is simply deleted with the account, it's recoverable for 30 days and then gone. If the client needs it longer, the shared-mailbox conversion (or a hold, where licensed) is the deliberate choice. Record which option the client picked and who picked it.

Evidence: conversion confirmation screenshot, the client's written instruction, license removal shown in the admin center.

Step 4 — Data and device custody

11. OneDrive. On account deletion, the user's OneDrive is retained for a configurable window — 30 days by default, adjustable in the SharePoint admin center — and access can be granted to a manager or designated user. Confirm anything business-critical is moved or delegated before deletion, and record where it went.
12. Devices. Company-owned: wipe or reset through Intune and record the action per device. Personal devices under BYOD enrollment: retire (which removes company data and profiles) rather than wipe. Collect hardware per the client's asset process and note serials against the ticket.

Evidence: OneDrive delegation screenshot, per-device wipe/retire confirmations from Intune.

Step 5 — The ownership long tail (the steps every checklist misses)

Some things silently belong to a user account and die with it. This is where "we followed the checklist" offboardings still lose data:

13. Microsoft Forms. There is no admin API or report for Forms ownership — the only reliable check is signing in as the user (before deletion, while you still can) and looking at forms.microsoft.com, then transferring anything found via the form's collaboration settings. One sysadmin discovered this the hard way:

    "Then comes the cherry on top: 'Check if they own any Microsoft Forms.' Easy, right? Wrong. Apparently, there's no Graph API, no PowerShell module, no report"

    — r/sysadmin, April 2025

14. Power Automate flows. Flows owned by the user stop running or become orphaned. Power Platform admin center → view flows per user → reassign ownership for anything in production. The classic casualty is the flow that posts invoices to a Teams channel, discovered three weeks after it stops.
15. Power BI, Planner, Bookings. Same pattern, smaller blast radius: check for owned workspaces, plans, and booking pages where the departing user is the sole owner.

Evidence: a one-line note per surface checked — including "checked, nothing found." Negative results are evidence too; they're the difference between verified empty and never looked.

Step 6 — Close with a ledger row, not a vibe

Now the part that makes it audit-proof. Every artifact above gets indexed in one place — a per-user offboarding ledger with a row per step: the action, the date, who performed it, and the evidence filename. The structure that works:

The ledger never contains a password or a token — only what happened and where the proof lives. When an auditor samples a departed user from the HR list, you produce one ledger and its attachments, and you have a complete answer in ten minutes. That is the entire meaning of "audit-proof": not a special tool, just the discipline that done means the evidence is filed, and a completed ledger exists for every name on the leavers list.

Two habits close the loop:

• Trigger discipline. The offboarding starts from a written instruction (HR ticket, client email) with a timestamp — because "how quickly was access removed after termination?" is the first question in both audits and disputes. The gap between instruction and Step 1 should be measured in minutes for terminations, and the ledger should show it.
• Sampling. Once a quarter, pull three departed users from the client's HR list and check them against ledgers — including a live test that the account can't sign in. Finding your own gaps is cheap. Having an auditor find them is not.

The same discipline, one level up

Everything above scales. When it isn't one user leaving a client but an entire client leaving your MSP, the identical logic applies to a much bigger surface: every credential your shop held, every agent you deployed, every portal where your email is the login — each needing a recorded disposition, a receipt, and a named human who confirmed it. The evidence ledger becomes a credential handover register; the closing ticket note becomes a signed certificate. The MSP client offboarding checklist walks that full exit phase by phase.