Microsoft 365 Employee Offboarding: A Practical Checklist for Access, Devices and Company Data

Agree the departure time and time zone with HR and the manager. Name the IT owner, approve the access cutoff, and identify who may receive company information. A planned departure allows preparation; an urgent security incident needs coordinated containment and evidence preservation under the incident process.

Inventory identities, devices, mailboxes, group roles, applications and business-owned data. Ask what the person owns, not just what they use: a scheduled flow or sole administrator role can be missed by an account list. Record retention requirements and legal holds before destructive changes. The Microsoft offboarding overview provides the service-specific starting sequence.

At the agreed cutoff, block sign-in in Entra ID, reset credentials where appropriate, and revoke sign-in sessions. Record each request and verify the account state. For hybrid or federated identities, establish the source of authority, disable the on-premises AD account where applicable, and coordinate synchronization so changes are not undone.

Blocking and revocation do not guarantee every issued access token or independent application session ends instantly. Service behavior, token handling and propagation vary. Check VPN, SaaS, local accounts, privileged memberships, application ownership and non-Microsoft access separately, including application-side session controls. Microsoft's access-removal instructions and Entra revocation guidance explain why disabling identity is not the entire job.

Choose authorized forwarding, delegation or shared mailbox conversion for a defined business purpose. Forwarding handles new messages; it does not hand over the old mailbox. Assign the successor appropriate permissions, review recurring meetings and calendar ownership, and verify mail delivery and access. Never share the former employee's password.

Keep the mailbox licensed through conversion and verify the result before removing a license. A shared mailbox is not always license-free: size, archive, holds and other features can change requirements. Do not delete the account anchoring a shared mailbox or forwarding arrangement. Check Microsoft's mailbox continuity steps and conversion requirements against the actual configuration.

Assign an authorized successor for OneDrive content, then move operational files into appropriate team-owned SharePoint storage rather than leaving them dependent on a former colleague's personal workspace. Review external sharing and permissions as part of the handover.

Check owners of Teams, Microsoft 365 groups and Power Automate flows, including connection identities. Reassign ownership and verify dependent work still has authorized access. Retention, holds and deletion schedules depend on tenant settings and policy; there is no universal deadline for every environment. Review Microsoft's OneDrive and Outlook handover guidance before removing licenses or deleting accounts.

Inventory enrolled devices, identify ownership and arrange recovery of company hardware. Retire or selective corporate-data removal is different from a factory wipe. Choose an action supported by the platform, enrollment and management model; a full wipe of a personal device is not the default.

Use Microsoft's Retire and Wipe documentation to check the exact effect before approval. Offline devices may receive the action later when they check in. A queued command is not completion evidence. Record the pending action, the exposure it leaves and the follow-up owner. Hardware recovery remains a separate task.

Remove or reassign licenses only after mailbox continuity, required records, data access and retention have been checked. Verify group-based licensing and subscriptions separately; unassigning a license is not necessarily the same as reducing a purchased subscription.

Deactivate remaining non-Microsoft access and record the decision. Delete an account only when approved and appropriate, retaining accounts required for shared mailboxes or forwarding. Deletion is not harmless housekeeping. Consult Microsoft's license-removal guidance and account-deletion steps before proceeding.

I would close with evidence, not a list of buttons clicked: sign-in blocked, session revocation requested, access and ownership transferred, mailbox and data controls checked, endpoint action confirmed or explicitly pending, hardware recovery recorded, and the license decision documented.

The editable example below starts with suggested owners and evidence—not completed checks. Replace them with your approved process. Any pending task needs a named follow-up owner and review point; it must not quietly become a completed offboarding.

Start automation with approval, inventory and reversible preparatory steps. Require explicit human confirmation before destructive account or device actions. Log requests and outcomes separately, handle errors, and make repeat runs idempotent so retries do not produce duplicate or contradictory changes.

My preference is a small, reviewable workflow over a bulk destructive script. Test with approved test identities, keep credentials out of logs, and stop for unexpected conditions. Automation should make ownership and exceptions clearer—not hide them behind a successful job status.