A terminated employee's Microsoft 365 access doesn't end when someone clicks "disable account." Sessions can stay live for minutes. Mailbox delegate access, forwarding rules, mobile devices, and third-party app tokens don't touch that button at all. These are the best practices that actually close the gap.
Termination changes the offboarding clock. A planned departure gives you weeks of notice. A termination often gives you none, and the access needs to come down immediately, completely, and in a defensible order, because the risk profile of a terminated employee is different from someone who resigned on good terms.
This guide covers the best practices for handling a terminated employee's Microsoft 365 access. If you're building the broader security policy this sits inside, our Microsoft 365 security best practices guide covers the governance side (reviews, guest access, app consent) that keeps this kind of gap from opening in the first place.
Prioritize by Urgency, Not by Checklist Order
Not every action carries the same urgency, and treating them all as equally time-sensitive slows down the ones that actually are.
Immediate priority (within minutes of termination): revoking active sessions, blocking sign-in, and resetting the password. These stop the employee from acting on any system in real time.
Same-day priority: license decisions, mailbox handling, device actions, and third-party app access review.
Within-the-week priority: data retention decisions, knowledge transfer of owned resources (Teams, SharePoint sites, shared mailboxes), and final confirmation that nothing was missed.
Revoke Active Sessions First
Disabling an account doesn't end sessions already in progress. In the Microsoft 365 admin center, under Users > Active Users, selecting the employee and choosing Sign out of all sessions forces re-authentication everywhere, including mobile apps and any device where they're still logged in.
This can take several minutes to fully propagate, which is exactly why it needs to happen first, before anything else.
Block Sign-In and Reset the Password, Together
Signing a user out doesn't stop them from signing back in. Blocking sign-in status and resetting the password should happen as a pair, not one or the other: a blocked sign-in with an unchanged password still leaves a valid credential that could work again if the block is ever lifted or misconfigured.
Handle the Mailbox Deliberately
There are three common paths, and the right one depends on whether ongoing access to the mailbox's content is needed.
Converting to a shared mailbox makes sense if the role's email needs continued monitoring or historical reference. Shared mailboxes don't require their own license, which also stops billing on that seat.
Setting up forwarding routes incoming mail to a manager or replacement, and can run alongside a shared mailbox conversion or on its own.
Setting an automatic reply noting the person has left the organization matters most for customer-facing roles, so external contacts aren't left waiting on a mailbox nobody's monitoring.
The best practice is choosing one of these deliberately. Leaving the mailbox untouched both wastes a license and leaves an unmonitored account that outside parties may still be emailing.
Remove Delegate and Shared Access, Not Just the Account
This is the practice manual offboarding most often skips, because it isn't visible from the account status screen:
- Mailbox delegate permissions other users hold to the terminated employee's mailbox, and permissions the employee held to others' mailboxes
- Shared mailbox membership, updated if they were a primary contact or approver
- Distribution list and Microsoft 365 Group membership, removed so they stop receiving mail or appearing able to send as any list they belonged to
None of these are touched by disabling the account, and all of them represent standing access that persists silently until someone specifically checks for it.
Reassign Ownership Before You Remove the Account
Identify what the employee owned before removing their account entirely:
- Teams and SharePoint sites where they were the sole owner. Reassign ownership before deletion, or the resource can become orphaned, inaccessible for administration even though its content still exists.
- OneDrive content, which needs a destination. Transfer files to a manager or a designated retention location first.
- Automations and Power Automate flows built under their identity, which break silently once the account is deactivated unless ownership is transferred beforehand.
Handle Devices Based on Ownership
If Intune or another MDM solution is in place:
Corporate-owned devices should get a full wipe, removing everything on the device, not just Microsoft 365 data.
Personal devices under a BYOD policy should get a selective wipe that removes only corporate data and app access, leaving personal data untouched.
Devices outside MDM reach, or apps syncing via ActiveSync, need a mobile device wipe request submitted directly through the Exchange admin center to clear synced mailbox content.
Review Third-Party App Access, Specifically
Check for OAuth app consents and API tokens the employee's identity may have authorized: scheduling tools, CRM integrations, automation platforms, or any third-party app connected to their Microsoft 365 identity. These tokens don't expire automatically when the account is disabled, and they represent a way into Microsoft 365 data that doesn't require the person's own login. Revoke each one specifically rather than assuming account deactivation handles it, since it doesn't.
Reclaim the License Last, Not First
Once the mailbox is handled, ownership is transferred, and access is confirmed revoked, remove the Microsoft 365 license. A converted shared mailbox typically doesn't need a license to remain accessible, but confirm your organization's specific configuration (in-place archiving settings, for example, can affect whether a license is still required) before removing it. Reclaiming the license too early, before the mailbox decision is made, can complicate the very steps meant to preserve continuity.
Confirm and Document Every Time
Close the loop: confirm every practice above was actually applied (sessions ended, sign-in blocked, delegate access removed, ownership transferred, license reclaimed), and log the action with a timestamp. This record matters twice: for internal accountability if anything is questioned later, and as evidence if the termination or its handling is ever audited or disputed.
Why "Disable the Account" Isn't a Best Practice on Its Own
Every practice above exists because disabling an account only stops future logins. It does nothing to sessions already open, delegate access others hold, resources the person owned, devices still synced, or third-party tokens issued under their identity. A terminated employee whose account shows "disabled" in the admin center can, through any of those channels, still have live access to organizational data if the rest of these practices weren't applied.
That gap, between an account that looks offboarded and access that's actually closed, is the same one that shows up across any SaaS application, not just Microsoft 365. It's covered in more depth, including how it compounds across an entire environment rather than a single app, in our guide to Microsoft 365 security best practices.
Where This Checklist Ends, and Where the Real Gap Usually Is
Every practice above uses Microsoft's own tools: the admin center, Entra ID, Exchange, Intune. And within Microsoft 365 itself, those tools are genuinely mature. Session revocation, mailbox conversion, device wipes, delegate access removal: Microsoft gives you what you need to do all of it correctly, if someone applies it consistently.
The honest gap isn't inside Microsoft 365. It's everywhere this checklist doesn't reach. A terminated employee's Microsoft identity was very likely the login for a dozen third-party SaaS apps: Slack, Salesforce, Figma, a CRM, a project tool, anything connected through SSO or through an OAuth grant the employee approved individually. None of Steps like reviewing "third-party app access" inside the Microsoft 365 admin center tell you what that access actually is in each of those external apps, what role or permission level it carried, or whether it was ever revoked on the app's own side after the OAuth token was pulled. Microsoft can tell you a token existed. It generally can't tell you what that token was worth inside Salesforce, or whether Salesforce itself still shows the person as an active user with standing permissions.
This is the part of offboarding that consistently gets missed, not because IT teams are careless, but because Microsoft's own tools were never built to see outside Microsoft's own ecosystem.
How Zluri Closes the Gap Microsoft 365 Can't See
Zluri is an identity security platform for autonomous enterprises, built as four products on one platform: Identity Visibility & Intelligence (IVIP), Identity Governance & Administration (IGA) with its four modules (Access Management, Access Requests, Access Reviews, and SoD), Identity Security Posture Management (ISPM), and SaaS Management (SMP).
Zluri isn't a replacement for the Microsoft-native steps in this guide, and it doesn't need to be; Microsoft's own tools already handle those well. What Zluri adds is the part Microsoft 365 admin tools still struggle with: discovery and governance of the third-party SaaS apps a terminated employee had access to. IVIP's discovery methods find every app the identity touched, including tools adopted outside IT's federation setup entirely, not just what shows up as an OAuth grant inside the Microsoft 365 admin center. IGA's offboarding workflow then revokes access at the app level, in each of those third-party tools directly, so the deprovisioning that ends at "token revoked" inside Microsoft 365 continues into "account actually deactivated" inside Salesforce, Slack, or whatever else the person used.
Run alongside the Microsoft-native practices above, that combination is what makes offboarding complete rather than complete-looking: Microsoft 365 handled correctly through its own tools, and everything outside Microsoft 365 handled by the platform built specifically to see it.
Best Practices Are Only as Good as Their Consistency
Every practice in this guide is straightforward on its own. The risk isn't that any individual one is hard, it's that termination offboarding happens under time pressure, sometimes without warning, and a long manual list applied quickly is exactly where one item quietly gets skipped. Whether these practices are applied manually or automated, the goal is the same: an account disabled in the admin center should mean access is actually gone everywhere, not just at the login screen.
Frequently Asked Questions
What is the most important best practice for offboarding a terminated employee in Microsoft 365?
Revoking active sessions and blocking sign-in immediately, since disabling the account alone doesn't end sessions already in progress. A password reset should follow right away. Everything else (mailbox handling, delegate access, device wipes, license reclamation) matters, but these three stop real-time access and should never be delayed.
Does disabling a Microsoft 365 account end all their access immediately?
No. Disabling stops future sign-ins but doesn't end already-active sessions, doesn't remove delegate access others hold to their mailbox or they hold to others', doesn't reassign ownership of Teams or SharePoint sites, doesn't wipe synced mobile devices, and doesn't revoke third-party app OAuth tokens. Each of these needs a separate, deliberate action.
Should you delete a terminated employee's mailbox or convert it to shared?
It depends on whether ongoing access to the mailbox's content is needed. Converting to a shared mailbox preserves email history and allows continued monitoring or delegate access without requiring its own license. Deleting removes the mailbox entirely, appropriate once any needed data has been retained elsewhere and no ongoing access is required. Many organizations convert first and delete later, once retention requirements are satisfied.
What Microsoft 365 access do IT teams most often forget to revoke after a termination?
Delegate mailbox permissions and third-party app OAuth consents are the two most commonly missed, because neither is visible from the account status screen and neither is touched by disabling the account. Ownership of Teams and SharePoint sites is a close third, since orphaned ownership can leave a resource inaccessible for administration even though it remains fully accessible in content.
Can Office 365 terminated employee best practices be automated?
Yes, and for terminated (as opposed to planned) departures, automation matters more, not less, because the offboarding often happens with no notice and needs to be complete immediately. Identity governance platforms can trigger a full offboarding workflow, covering session revocation, delegate access removal, license reclamation, and third-party app token revocation, from a single HR-triggered event, rather than relying on an IT admin to apply every best practice correctly under time pressure.
.svg)
