Share via

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

Angharad Davies 40 Reputation points
2026-05-26T11:57:48.1233333+00:00

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?

Microsoft 365 and Office | SharePoint | For business | Windows
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Tamara-Hu 15,280 Reputation points Microsoft External Staff Moderator
    2026-05-27T12:03:18.9833333+00:00

    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. 

    Was this answer helpful?

  2. Tamara-Hu 15,280 Reputation points Microsoft External Staff Moderator
    2026-05-26T13:59:26.19+00:00

    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: 

    User's image

    • 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. 

    User's image

    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. 

    Was this answer helpful?

  3. AI answer

    2026-05-26T11:58:29.27+00:00

    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:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.