What happens to a leaver's access on day 31

01 / 11

A Friday afternoon at a fictional brokerage

Consider a fictional 55-person real-estate brokerage. An agent resigns on a Friday afternoon, effective immediately. By Monday, two of her listings are being remarketed under a competitor's name. Nobody stole a file to make that happen. She still had an open session in the CRM, her phone still synced the shared team calendar over the weekend, and a scheduling app she had personally approved eighteen months earlier never noticed she left.

None of that is a dramatic breach. It is a set of ordinary permissions that nobody closed, each one still open past the day she walked out the door — which is the actual shape of most offboarding failures.

02 / 11

Offboarding is a sequence, not a switch

Microsoft's own guide to removing a former employee runs to seven steps, published in a specific order for a reason: skip ahead to deleting the account before saving the mailbox, and there is nothing left to save.

The step numbers hide something the guide never states outright. Each step closes a different kind of access, and each one runs on its own clock. Some finish in an hour. One runs for thirty days. And at least one, as far as we could find, never finishes on its own at all.

• Prevent the user from signing in
• Save the contents of their mailbox
• Wipe and block their mobile device
• Forward their email or convert the mailbox to shared
• Hand their OneDrive and Outlook data to someone else
• Remove and delete the Microsoft 365 license
• Delete the user account

03 / 11

The fast way to end a sign-in, and the slow way people default to

The instinctive first move is Block sign-in, and it is also the slower one. Microsoft is specific about the limit: Blocking an account can take up to 24 hours to take effect.

The fast path is a different pair of clicks: reset the user's password, then select Sign out of all sessions on the Account tab. Microsoft's own description of what happens next: Within an hour, or after the user leaves the current Microsoft 365 page they're on, they're prompted to sign in again. An access token is good for an hour, so the timeline depends on how much time is left on that token, and whether they leave the current webpage.

One exception worth knowing before you assume the leaver is gone: If the user is using their mailbox in Outlook on the web, they might not be signed out immediately. As soon as they select a different tile, such as OneDrive, or refresh their browser, the service signs them out. Someone mid-email does not vanish the instant you click a button.

04 / 11

Why a signed-out laptop can still say yes

Signing a user out is not the same as invalidating every token already handed out. Microsoft's guidance on emergency access revocation states the baseline plainly: By default, access tokens issued by Microsoft Entra ID last for 1 hour.

What happens for that hour depends on how the application was built. Per Microsoft: For applications using access tokens, the user loses access when the access token expires... For applications that use session tokens, the existing sessions end as soon as the token expires. Either way, the token has to run out on its own; disabling the account does not reach back and cancel one already issued.

There is a sharper lever for the refresh token specifically. Microsoft Graph's revokeSignInSessions action invalidates all the refresh tokens issued to applications for a user (and session cookies in a user's browser) — and even that is not instant: After you call revokeSignInSessions, there might be a small delay of a few minutes before tokens are revoked. Minutes, not zero.

• Sign in to the Microsoft Entra admin center
• Open Users, then All users, and select the departed user
• Under Account status, select Edit
• Clear Account enabled, then Save
• On the user's Overview page, select Revoke sessions

05 / 11

Three clocks, one timeline, and one that never closes

Laid end to end, offboarding stops looking like a single switch and starts looking like several countdowns that happen to start at the same moment, at very different speeds.

A checklist item marked done can still be an open door for however long its particular clock allows. The figure below lines up four of them, drawn from the pages quoted through this post.

06 / 11

The phone that never checks back in

A leaver's phone or laptop does not clear on the same clock as their sign-in. Intune's Retire action is the lighter of the two options, built for a device you do not need to reset to factory settings: The retire action in Intune removes company data from a device without performing a full wipe or factory reset... It unenrolls the device from Intune and removes managed apps, settings, and profiles deployed through mobile device management (MDM), while preserving personal data.

Wipe is the harder version, for company-owned hardware you want back to zero: Use the Wipe action in Intune to factory reset a device, restoring it to its default settings. This action removes all personal and organizational data, apps, and configurations.

Both actions share the same catch, and it is the one that matters for a leaver who keeps the laptop over a long weekend: The action is triggered the next time the device checks in with Intune. Until then, the device might still appear in the admin center. Our reading, not a sentence Microsoft states outright: a device that never reconnects keeps whatever company data it already had, for as long as it stays offline.

07 / 11

Two different 30-day clocks, easy to confuse

The user account itself gets a recovery window. Delete it, and Microsoft is specific: After you delete a user, the account remains in a suspended state for 30 days. During that 30-day window, the user account can be restored, along with all its properties. After that: the permanent deletion process automatically starts and can't be stopped — and a permanently deleted user can't be restored by anyone, including Microsoft customer support.

Their OneDrive runs on a second clock that happens to default to the same number and is easy to mistake for the first. The default retention period for OneDrive is also 30 days, but you can change this in the SharePoint admin center — anywhere from 30 through 3650 days, an administrator's own setting, unrelated to the account's own recovery window. Change one and the two dates quietly drift apart.

Microsoft also tells someone before that window closes. If the departed user had a manager on file, the manager receives an email telling them that they have access to the OneDrive, and that the OneDrive will be deleted at the end of the OneDrive retention period, with a reminder seven days before the OneDrive retention period expires. No manager on file, and a secondary owner configured in the SharePoint admin center gets the same two emails instead. Set neither, and nobody is told at all.

08 / 11

The mailbox: convert it before the license, not after

Mailbox content does not vanish when sign-in is blocked, but it can vanish when the license does. Microsoft's own sequence saves the mailbox in step 2, before touching the license in step 6, and offers a shared mailbox as the place to land it. Convert it, and all of the existing email and calendar are retained in a shared mailbox that several people can access.

The size ceiling is the detail people miss: Creating a shared mailbox can be a less expensive way to go because you don't have to pay for a license as long as the mailbox is smaller than 50 GB. If it is over 50 GB, you need to assign a license to it. A departing salesperson with years of email can clear that limit before anyone checks. What happens if a license comes off too early, and the short window Microsoft gives you to correct it, is its own topic we have covered elsewhere; the point here is simply to convert before you delete, not after.

09 / 11

The grant nobody remembers approving

Every clock above eventually closes on its own. This one, as far as we could find in Microsoft's own documentation, does not. When a user personally consents to a third-party application — a scheduling tool, a CRM add-in, a meeting note-taker — that consent creates a permission grant that lives in the tenant's directory as its own object, separate from whether the user can still sign in.

Our reading, not something Microsoft states as a warning: blocking sign-in, resetting the password, even deleting the account are not documented anywhere as revoking a grant the person made themselves. We looked for a page that says so and did not find one, which is itself worth knowing before you assume the account deletion handled it.

The fix is a step Microsoft's seven-step guide does not include: on the same day you delete the account, check the tenant's enterprise applications for anything the departed employee owned or personally approved, rather than months later, when someone notices a connector still quietly pulling calendar or mail data.

10 / 11

What a leaver still has, and until when

The clocks above, side by side. Read the middle two columns before the last one — most of this list closes on its own, but only if the matching action actually happens.

11 / 11

Where to start

Today, without buying anything: pull up the last person who actually left, and check two things Microsoft's own guide never prompts you to check. First, open Entra ID's enterprise applications list and look for anything they owned or personally consented to. Second, open the SharePoint admin center's retention setting and confirm what your tenant's OneDrive countdown is actually set to, rather than assuming it matches the 30-day account window.

Disclosure: this is a category we sell into. Avalon CloudSec maps every Microsoft 365 license to the person holding it and their last activity, flags accounts that are disabled but still licensed, and keeps an inventory of enterprise applications and OAuth grants, including ones a former employee approved personally, so a grant that outlived them shows up instead of waiting for someone to notice. It is read-only: every Microsoft Graph permission it holds is a read permission, never a write one, so it cannot block a sign-in, revoke a token, or delete an account itself — every action in this post still happens in Microsoft's own admin screens, done by your team. One honest limit: it shows you that an account is disabled and a grant still exists; it does not confirm that a specific device actually reconnected and retired, or that a token was actually revoked, and that follow-through stays in Intune and Entra. Questions go to email support@awservices.org.

Microsoft, Microsoft 365, Azure, Entra, Intune and Defender are trademarks of the Microsoft group of companies. Avalon CloudSec is an independent service and is not endorsed by Microsoft.