How long does it take for Microsoft to delete all trace of an external user after (hard) deletion from Entra?

Question

I've removed my external user from SharePoint, User Profiles and (hard) deleted from Entra.

I've created a new account not long after, the user can access the M365 tenant, however:

• If I add them to the site they get a 'this site has not been shared with you request access', if I approve they still can't access the site.
• If I only add them directly through managed access to a specific folder they still don't have access
• If I only share the specific folder with them they still don't have access
• If I create a unique copy shared URL path they get an error saying 'Sorry, something went wrong. There's is a legacy user account in this site with same email'. There's no trace of this legacy user account.
• I've checked M365 Admin Centre User ID mismatch but it just says the 'user doesn't have Open access'

Any idea where I can go from here?

Answer 1

I raised a ticket with Microsoft, regarding existing guest users unable to re-enter sites / libraries / folders they previously had access to. This is Microsofts' response. (These instructions have fixed the issue):

"Thank you for the detailed summary and for the thorough remediation steps you have already taken — that context is extremely helpful.

Based on the symptoms described and the error message "There is a legacy user account in this site with the same email", this is consistent with a SharePoint User Information List (UIL) identity conflict, which occurs when a guest account is deleted and recreated with the same email address. 

Root Cause Explanation

Every SharePoint site collection maintains a hidden list called the User Information List (UIL). When a user (including a guest) is granted access to a site or first interacts with it, SharePoint caches their identity information in this list — including a unique identifier (PUID) that is separate from their email address or UPN.

When a guest account is deleted from Entra ID and a new guest account is created with the same email, the new account is assigned a new PUID by Entra ID. However, the old PUID remains cached in the UIL of every site the user previously visited. During authorisation, SharePoint compares the PUID in the authentication token against the PUID stored in the UIL — because these no longer match, access is denied, even though the email address appears correct and the user has been re-added to the appropriate permission groups.

This also explains why:

• Approving access requests does not resolve the issue (SharePoint writes permissions against the stale UIL entry).
• Direct sharing and managed access fail (the old identity reference blocks the new account).
• The "copy link" method surfaces the explicit error about a legacy account with the same email.
• The M365 Admin Centre may not flag a mismatch, as the diagnostic evaluates differently depending on the access context and entry state. 

Recommended Remediation Steps

Since this issue spans multiple sites, the legacy user entry must be removed from the UIL on each affected site collection individually. Below are two methods:

 

Method 1 — Via the SharePoint UI (per site)

 

1. Navigate to each affected site and append the following to the site URL: /_layouts/15/people.aspx?MembershipGroupId=0 For example: https://yourtenant.sharepoint.com/sites/sitename/_layouts/15/people.aspx?MembershipGroupId=0
2. Locate the external user in the list (look for the guest's email address).
3. Select the checkbox next to their name, then from the Actions menu, select Delete Users from Site Collection. 

 

Method 2 — Via SharePoint Online PowerShell (recommended for multiple sites)

 

1. Connect to SharePoint Online Management Shell as a SharePoint Administrator.
2. Run the following command for each affected site collection:

Remove-SPOUser -Site 

Replace the site URL and login name with the actual values for each external user. 

 

After removing the legacy entry from the UIL:

1. Re-grant permissions to the guest user on each site (e.g., via site permissions, sharing, or adding to the appropriate SharePoint group). This will create a fresh UIL entry with the correct PUID.
2. Allow up to 24 hours for changes to fully propagate across the service.

 

Additionally — Run the Site User ID Mismatch Diagnostic:

 

Although the M365 Admin Centre did not flag a mismatch initially, I recommend running the dedicated diagnostic tool as a supplementary step:

• Navigate to: https://aka.ms/PillarSiteUserIDMismatch
• Sign in as a Global or SharePoint Administrator.
• Enter the affected guest user's email and the URL of each impacted site.

This diagnostic performs a broader range of validations for both internal users and guests and may detect and resolve residual conflicts that are not visible through the standard admin checks."

When I asked them to clarify step "4. Allow up to 24 hours for changes to fully propagate across the service.", this was their response:

"To summarize the flow:

Remove the user from site permissions/groups.

1. Navigate to /_layouts/15/people.aspx?MembershipGroupId=0 and delete the user from All People.
2. Wait up to 24 hours.
3. Re-grant access by adding them back to the correct group/share.
4. User accepts the invite and tries access immediately."

The instructions above have fixed the issue.

Answer 2

Hello @Angharad Davies, 

Thank you for taking the time to share the details of your issue.

Based on the information you’ve provided, this issue requires deeper investigation from Microsoft’s internal teams to identify the root cause and restore the functionality. For this reason, I recommend contacting the Microsoft Support Team directly so they can assist you further.

For business support:   

1. Find your Microsoft 365 admin: If you don't know who the global admin is in your organization, you can find guidance here: How can I find my Microsoft 365 admin? - Microsoft Support    

2. Submit a service request: The Global Administrator should create a support request with Microsoft to receive advanced technical assistance. For detailed instructions, see: Get support - Microsoft 365 admin | Microsoft Learn    

Note: If your organization's subscription is from a partner or reseller, contact the reseller's support provider to help open a service request on behalf of you instead.    

I’d also like to mention that as a forum moderator, I don’t have access to backend logs or the ability to reach out to Microsoft Support on your behalf. I’m here to provide guidance based on my permissions and the resources available to me.

That said, I’m happy to support you throughout the process. Once you’ve created the support request and received a ticket number, feel free to share it with me via private message. I can help you track the case and suggest next steps if needed.

To access the private message, please refresh this page, you should see a pop-up at the top of your thread. Click on View Messages to review it.

Thanks again for your patience, and I’m here if you need any further help.

Answer 3

Thanks for your confirmation, @Angharad Davies.

To move forward, can you provide some additional information:

• May I ask when checking the site’s full user list and remove the old entry manually by accessing this link: https://<site>/_layouts/15/people.aspx?MembershipGroupId=0 , can you find the external user's entry?
• Does this issue occur when sharing from all sites, or only from a specific site?
• Could you try removing the user from the Entra ID Center and then adding them back one more time to see if the issue persists?
• Does the issue only occur with a specific email address, or does it affect other external addresses as well? Also, what type of accounts are involved (personal, work, or school)?

I recommend referring to the following instructions to fully remove the external user entry before adding them back again: Remove users from SharePoint - SharePoint in Microsoft 365 | Microsoft Learn

Looking forward to your response so we can get this sorted out for you together. 

Answer 4

Hello @Angharad Davies, 

This isn’t typically a timing/propagation issue on the Entra side. 

Even after a user is hard-deleted from Entra ID, SharePoint keeps its own record of users in the site-level User Information List (UIL). That record includes the old user’s internal ID, and it doesn’t get removed automatically when the Entra object is deleted. 

If you recreate a user with the same email, it’s treated as a completely different identity (new GUID), but SharePoint is still referencing the old one behind the scenes. That’s why you’re seeing behaviors where permissions appear to apply but access is denied, or errors mentioning a “legacy user account”. 

In practice, this won’t resolve itself just by waiting, the stale entry in SharePoint needs to be cleaned up. Here's what you can try: 

• Run the Site User ID Mismatch diagnostic again by following this official instruction : Fix site user ID mismatch in SharePoint or OneDrive - SharePoint | Microsoft Learn 

• If that doesn’t resolve it, check the site’s full user list and remove the old entry manually by accessing this link: https://<site>/_layouts/15/people.aspx?MembershipGroupId=0 . You can find any entry for that email and remove it, then re-share the site. 

This issue is quite common when accounts are deleted and recreated with the same UPN, SharePoint isn’t syncing identities in real time, so the old reference has to be explicitly cleared before the new account will work properly. 

If the issue still persists after trying these steps, please let me know so I can help you with further troubleshooting steps. 

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment". 

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

Answer 5

For external (guest) users, deletion in Microsoft Entra ID and complete removal from Microsoft 365 resources happens in stages, not instantly.

Key timelines and behaviors from the provided information:

1. Entra guest account deletion (soft delete then hard delete)
   • When a guest user is deleted in Microsoft Entra ID, the account is soft deleted and moved to Deleted users for 30 days.
   • During this 30‑day period, the account can be restored; after that, it is permanently deleted.
   • This applies both when:
     • The user is deleted manually from Entra ID, or
     • The user leaves the organization as a B2B guest.
2. Access reviews / “block then delete” behavior
   • If access reviews are used with the option “Block user from signing-in for 30 days, then remove user from the tenant”, the guest is:
     • Immediately blocked from sign‑in.
     • Deleted from the tenant after 30 days if no admin action is taken.
   • During this 30‑day “applying” period, the review’s settings and logs are locked.
3. Entitlement management lifecycle for external users
   • For guests onboarded via entitlement management:
     • By default, when they lose their last access package assignment, they are blocked from sign‑in, and after 30 days their guest account is removed from the directory.
     • Admins can configure whether to remove the external user and how many days to wait before removal, but changes only affect users who lose their last assignment after the change.
4. SharePoint / OneDrive cleanup depends on Entra deletion
   • For OneDrive, the retention/deletion process only starts when the user account is deleted from Entra ID.
   • After the Entra account is deleted, SharePoint/OneDrive runs a cleanup job and marks the OneDrive for deletion based on the configured retention period (default 30 days).
   • This shows that SharePoint relies on the Entra identity lifecycle; it does not fully “forget” a user until the Entra account deletion has propagated and the retention period has run.

Putting this together for the scenario:

• A “hard” delete in Entra ID still leaves a 30‑day soft‑deleted window where the user object exists in Deleted users.
• SharePoint and OneDrive cleanup and identity reconciliation depend on that deletion and their own retention jobs (default 30 days for OneDrive). During this time, there can be residual references to the old guest identity.
• If a new guest account is created with the same email shortly after deletion, SharePoint may still hold references or legacy identity mappings to the old (soft‑deleted) guest, which can cause “legacy user account” errors until:
  • The Entra guest object is permanently deleted (after 30 days), and
  • SharePoint/OneDrive cleanup and identity sync jobs complete.

From the documented behavior, the practical expectation is:

• At least 30 days from the time the guest is deleted in Entra ID for the identity to be permanently removed from the directory.
• Additional time may be needed for SharePoint/OneDrive cleanup jobs, especially if default retention (30 days) is in place.

So, all traces of the external user (as far as Entra ID and dependent services like SharePoint/OneDrive are concerned) are not fully removed immediately after a “hard” delete; the documented minimum lifecycle is 30 days, and effective cleanup in SharePoint/OneDrive can align with or extend beyond that depending on configured retention.

---

References:

• How to create, invite, and delete users
• Leave an organization where you have a guest account
• Govern access for external users in entitlement management
• Create an access review of groups and applications in Microsoft Entra ID
• Use Microsoft Entra ID Governance to review and remove external users who no longer have resource access
• Manage user and guest user access with access reviews
• OneDrive retention and deletion