When a user leaves an organization, their account is usually deleted from Microsoft Entra ID. However, SharePoint often keeps a record of that user in its own databases. These records are commonly called orphaned users. Most of the time they do not cause any problems. But when the same user principal name (UPN) is later assigned to a new account, these orphaned records can cause the well-known User ID Mismatch issue. In this article, we’ll look at what orphaned users are, why they exist, how they are related to User ID Mismatch, and what SharePoint administrators can do about them.
Overview
An orphaned user in SharePoint is generally understood as a user whose record still exists in a SharePoint site collection, even though the corresponding account no longer exists in Microsoft Entra ID.
Orphaned user records are not necessarily errors. SharePoint maintains its own site-level user information so that it can preserve historical context, such as who created or modified a document. However, these records can become operationally significant when an organization creates a new Entra ID account using the same User Principal Name, or UPN, as a previously deleted account.
This can produce a SharePoint user ID mismatch:
- The old and new accounts have the same UPN.
- They have different Entra ID object IDs.
- SharePoint still associates the UPN with the old identity.
- The newly created user cannot access content, even after apparently receiving permissions.
This article explains:
- What orphaned SharePoint users are.
- Why SharePoint retains them.
- How they contribute to user ID mismatch.
- Why fixing one affected site does not solve the tenant-wide problem.
- How remediation strategies differ by tenant size, tenant age, and employee turnover.
- How to approach the problem using cleanup, ticket prevention, and offboarding controls.
What Is an Orphaned User in SharePoint?
SharePoint maintains information about users who have interacted with or received permissions to a site collection. This information is stored in the site collection’s User Information List, commonly referred to as the UIL (it’s a hidden list in every SharePoint site collection). When a person visits a site or is otherwise resolved as a user, SharePoint caches information about that identity in this list. Deleting the corresponding account from Microsoft 365 or Entra ID does not necessarily remove the entry from each SharePoint UIL. [learn.microsoft.com]
The resulting record is commonly called an “Orphaned user” or “Stale user” or “Legacy user” or “Orphaned SharePoint identity”. “Orphaned user” is a useful administrative term, although Microsoft documentation more frequently uses terms such as legacy user account, outdated user account, or an old entry in the UIL.
Why does SharePoint retain the user?
The retained record provides continuity for user-related metadata. For example, after an employee leaves the organization, other users may still need to see that the former employee:
- Created a document.
- Modified an item.
- Added a list entry.
- Was previously assigned permissions.
- Participated in historical SharePoint activity.
From this perspective, the orphaned record appears not harmless but useful. It helps SharePoint preserve the historical identity associated with existing content.
Should administrators treat every orphaned user as something that must immediately be deleted? I see Microsoft positions are conflicting/controversial/ambiguous, as generally they say that legacy entry in the UIL is needed to preserve metadata but removal an orphan user from the UIL is OK, but primarily as a troubleshooting action for profile synchronization and mismatched-ID scenarios, rather than as routine indiscriminate cleanup. [learn.microsoft.com]
The Problem Appears When an Identity Is Recreated
Consider a common employee lifecycle scenario.
- John Smith leaves the organization.
- His Entra ID account is deleted.
- SharePoint retains John’s entries in the UIL of sites where he previously appeared.
- Several months later, the organization rehires John
- The identity team creates a new Entra ID account using the same UPN, such as
john.smith@contoso.com.
The new account looks similar to the old account:
- Same display name
- Same email address
- Same UPN
However, it is not the same directory object.
The recreated account receives a new internal identity value, even though its UPN matches the deleted account. Microsoft documents this as a primary cause of SharePoint and OneDrive user ID mismatch. [learn.microsoft.com], [learn.microsoft.com]
The same situation can also occur when the UPN is assigned to an entirely different person. For example, a new employee named John Smith may receive an address previously used by another John Smith.
From Entra ID’s perspective, the new account is a new security principal. From the affected SharePoint site’s perspective, however, the UPN may still be associated with the legacy UserInfo entry.
What Is a SharePoint User ID Mismatch?
A user ID mismatch occurs when the identity presented by the current user does not match the identity stored in SharePoint.
Conceptually, SharePoint sees something like this:
| Attribute | Legacy account | New account |
|---|---|---|
| Display name | John Smith | John Smith |
| UPN | john.smith@contoso.com | john.smith@contoso.com |
| Entra ID object ID | Unique (Old value) | Unique (New value) |
Although the UPN is the same, the internal identity is different.
Microsoft describes the underlying cause as follows: the recreated account receives a new ID, but the affected SharePoint or OneDrive UIL still contains the old ID. When the user attempts to access the site using the new account, the new identity does not match the identity stored in the site. Access can therefore be denied.
Sometimes a user experiences issues with their personal OneDrive site.
[User Id Mismatch in OneDrive scenario]
Typical symptoms include:
- An Access denied message.
- A message stating that a legacy account with the same email exists.
- Permissions that appear correct to the site owner but do not work for the user.
Why Denying Existing Access Is Correct
At first glance, it may appear that SharePoint should automatically connect the new account to the old account because the UPN is identical.
That would create a security risk.
A reused UPN does not prove that the new account represents the same person. Even if it is the same person, the individual may have returned:
- In a different position.
- In another department.
- As a contractor instead of an employee.
- Under different security requirements.
- With a different level of authorization.
The new account should not automatically inherit the old account’s SharePoint permissions.
Therefore, SharePoint is correct not to treat the recreated account as the same security principal merely because the UPN matches.
The more problematic behavior appears after an authorized site owner intentionally grants the new account access.
Where the Actual Operational Problem Begins
Suppose the new John Smith requests access to a site.
The site owner reviews the request and intentionally approves it. Alternatively, the site owner shares a site, library, folder, or document with the new account.
From the site owner’s perspective, everything may appear correct:
- The expected name is displayed.
- The expected email address is displayed.
- The user appears in the permissions interface.
- The sharing operation completes without an obvious error.
However, the user may still be unable to access the resource because the site’s UIL contains the legacy identity associated with the same UPN.
SharePoint does not always replace the old identity automatically when the new account is granted access. That is the practical limitation behind many user ID mismatch incidents.
Microsoft’s supported starting point is the Site User Mismatch diagnostic in the Microsoft 365 admin center. When a mismatch is found, the diagnostic can offer to remove the old identity from the affected site. After the old entry is removed, the new account must be assigned the appropriate permissions. [learn.microsoft.com], [learn.microsoft.com]
For a single site, this is usually manageable.
At tenant scale, it becomes much more complicated.
Why Fixing One Site Is Not Enough
A recreated user rarely interacted with only one SharePoint site.
During the person’s previous employment, the account may have been present in:
- Team sites
- Communication sites
- Microsoft Teams-connected sites
- Project sites
- Departmental sites
- Shared OneDrive sites
- Archived collaboration workspaces
- Sites where individual files or folders were shared
Removing the legacy identity from one affected site fixes only that site.
The same user may encounter another mismatch tomorrow, next week, or several months later when attempting to access a different site.
This creates a recurring support pattern:
- The user reports an access problem.
- The administrator identifies a mismatch.
- The administrator fixes the affected site.
- The ticket is closed.
- The user encounters the same problem on another site.
- The investigation starts again.
The technical fix is site-specific, while the identity lifecycle problem is potentially tenant-wide.
Why Discovering Every Affected Site Is Difficult
The obvious question is:
Which SharePoint sites still contain the old identity?
SharePoint Online does not provide a simple out-of-the-box report listing every site collection whose UIL contains a specific legacy user.
An administrator can technically scan SharePoint sites and inspect their users. However, this can be inefficient in a large tenant.
For example, imagine a tenant with:
- 50,000 SharePoint sites.
- A user who appeared in approximately 100 of those sites.
A straightforward tenant scan may need to inspect all 50,000 sites to locate the relevant 100.
This is a classic search-efficiency problem. The administrator knows the identity being investigated but does not know which site collections contain that identity. SharePoint’s user information is distributed across site collections rather than exposed through a convenient centralized orphan-user inventory.
For one affected user, a tenant-wide brute-force scan may consume considerable time and service resources relative to the number of useful results.
Shifting Left: When Should the Problem Be Addressed?
Instead of waiting for a user to report an access problem, administrators can move the remediation point earlier in the identity lifecycle.
There are three general opportunities.
Option 1: Fix the Site After a Ticket Is Reported
This is the most reactive approach.
Workflow
- A user reports that SharePoint access does not work.
- The administrator confirms that the account was recreated or the identity changed.
- The administrator runs the Site User Mismatch diagnostic.
- The old user entry is removed from the affected site.
- The new account is granted the appropriate permissions.
- The user tests access.
Advantages
- Limited scope.
- Low immediate effort.
- Changes are made only when necessary.
- Reduced risk of unnecessary tenant-wide modifications.
Disadvantages
- The user has already experienced disruption.
- The problem may exist on multiple sites.
- Each new site can generate another ticket.
- Support engineers repeatedly investigate the same root cause.
This approach treats the symptom rather than the tenant-wide identity residue.
Option 2: Check Newly Created Accounts
The next shift-left opportunity occurs when an account is created.
The organization could determine whether the UPN was previously used and then search for the corresponding legacy SharePoint identity.
Advantages
- The mismatch may be resolved before the user accesses SharePoint.
- Work is targeted at identities that are actually being created or recreated.
- It avoids cleaning every orphaned user immediately.
Disadvantages
- The process must determine whether the UPN is genuinely new or reused.
- The administrator still needs to locate the sites containing the previous identity.
- Historical identity data may not be readily available.
- It is still reactive to account creation rather than integrated with offboarding.
This approach can prevent tickets, but it requires reliable identity history and potentially expensive site discovery.
Option 3: Remove Legacy Site Entries During Offboarding
The earliest intervention point is employee offboarding.
Before deleting the Entra ID account, the organization still has a valid and identifiable user. It may be easier to determine the SharePoint sites associated with a current identity than to reconstruct that information months or years later.
The offboarding process could:
- Identify the SharePoint and OneDrive sites associated with the departing user.
- Record relevant site membership and ownership information.
- Address ownership and permission dependencies.
- Remove the user from selected UILs when appropriate.
- Delete or disable the directory account according to organizational policy.
Advantages
- The identity is still known and available.
- Site discovery can be incorporated into lifecycle automation.
- It can reduce future user ID mismatch incidents.
- It addresses the problem at its earliest practical stage.
Disadvantages
- Most offboarded users will never return.
- Most deleted UPNs may never be reused.
- Removing every departing user from every site may be unnecessary.
- Historical and metadata implications must be tested.
- Offboarding workflows become more complicated and potentially slower.
- A poorly designed process could create more risk than it removes.
This is the most proactive approach, but it can also be an over-engineered solution if the actual mismatch rate is very low.
An organization should not assume that universal deletion is automatically the best practice. Microsoft specifically describes UserInfo removal as a troubleshooting operation that should be performed for synchronization or mismatch scenarios when advised, rather than as a general cleanup requirement. [learn.microsoft.com]
A Three-Workstream Strategy
For established tenants, no single activity completely solves the problem. A practical program can be divided into three separate workstreams.
1. Clean Up Existing Orphaned Users
This workstream addresses the historical backlog already present in the tenant.
Its purpose is to:
- Inventory orphaned or legacy users.
- Identify high-risk identities.
- Detect reused UPNs.
- Remove confirmed conflicting identities where appropriate.
- Document exceptions and unresolved cases.
This is a backlog-remediation activity.
It can require substantial effort in an old or large tenant because orphaned identities may have accumulated for many years.
2. Stop Tickets
This workstream focuses on newly created or recreated accounts.
Its purpose is to prevent a new employee or returning employee from encountering mismatch errors after receiving SharePoint access.
Possible activities include:
- Detecting whether the new UPN was used previously.
- Comparing the new Entra ID object ID with historical identity information.
- Checking likely or known SharePoint sites.
- Removing confirmed legacy entries.
- Reassigning access explicitly to the new identity.
- Verifying access before the user begins work.
This is a near-term ticket-prevention activity.
It does not remove the entire orphan-user backlog, but it can prevent visible incidents for newly created accounts.
3. Stop the Bleeding
This workstream is triggered when users are offboarded.
Its purpose is to prevent new legacy identity conflicts from accumulating.
Possible activities include:
- Capturing the user’s site footprint before account deletion.
- Reassigning site, group, and content ownership.
- Recording the original Entra ID object ID and UPN.
- Applying a UPN-retention or reuse policy.
- Removing selected SharePoint user entries where justified.
- Preserving an auditable identity mapping for future investigation.
This is a future-state prevention activity.
The safest implementation may not be immediate removal from every UIL. In many organizations, the more valuable first step is recording the departing user’s identity and SharePoint footprint so the information remains available if the UPN is reused.
Tenant Age Changes the Priority
The appropriate combination of these workstreams depends partly on the age of the tenant.
New Tenant
A newly created tenant has little or no legacy identity history.
The primary focus should therefore be:
- Offboarding design.
- Identity history retention.
- UPN-reuse controls.
- Future orphan-user prevention.
A new tenant may not need a significant cleanup or ticket-remediation program.
Established Tenant
An established tenant may already contain:
- Many deleted identities.
- Previously reused UPNs.
- Unresolved UserInfo entries.
- Existing user ID mismatch cases.
Implementing an improved offboarding process prevents new problems, but it does not repair the historical backlog.
The organization may need all three workstreams:
- Clean up existing records.
- Prevent current tickets.
- Improve future offboarding.
Old Tenant
An old tenant with many years of account turnover may require a formal engineering solution.
The challenge is not necessarily deleting every orphaned entry. The challenge is:
- Identifying which entries are risky.
- Prioritizing accounts whose UPNs have been reused.
- Finding affected sites efficiently.
- Correcting mismatches without damaging historical information.
- Avoiding an endless tenant-wide brute-force scan.
Tenant Size Determines the Technical Approach
Small Tenants
In a small tenant, brute-force scanning may be acceptable.
An administrator may be able to:
- Enumerate all SharePoint sites.
- Enumerate the users on each site.
- Compare SharePoint identities with Entra ID identities.
- Produce an orphan-user report.
- Review and remediate the results.
Depending on throttling, permissions, and the number of sites, the process might complete within a practical operational window.
Medium-Sized Tenants
A medium-sized tenant may require a hybrid approach:
- Scan high-value sites first.
- Prioritize reused UPNs.
- Process active departments before archives.
- Maintain a cached site-user index.
- Perform incremental scans instead of full rescans.
- Combine ticket-driven remediation with scheduled discovery.
The objective is to avoid repeatedly scanning every site for every affected user.
Large Tenants
In a large tenant, a naive brute-force approach may be impractical.
The solution may require:
- Incremental inventory collection.
- Parallel processing with controlled concurrency.
- Throttling and retry handling.
- Persistent storage of site-user relationships.
- Delta-oriented identity processing.
- Site prioritization.
- Historical identity correlation.
- Separate handling for SharePoint sites and OneDrive sites.
- Governance around retention and UPN reuse.
At this scale, orphan-user management becomes an engineering and data-indexing problem rather than a simple administrative script.
Employee Turnover Also Matters
Tenant size and age are not the only factors.
Two organizations with the same number of users may experience very different levels of risk.
An organization with stable staffing and low turnover creates relatively few deleted identities. An organization that frequently hires contractors, seasonal workers, or temporary employees may create and delete a much larger number of accounts.
Relevant factors include:
- Number of offboarded users per year.
- Percentage of UPNs eventually reused.
- Frequency of employee rehires.
- Use of contractors and seasonal employees.
- Tenant age.
- Number of SharePoint sites.
- Average number of sites associated with each user.
- Average delay between deletion and UPN reuse.
The mismatch rate may be low relative to the total number of deleted accounts. Therefore, removing every orphaned SharePoint user during every offboarding may be disproportionate to the actual risk.
A more efficient strategy may prioritize identities whose UPNs are known to have been reused or are likely to be reused.
Is It Safe to Remove an Orphaned User?
This deserves its own detailed discussion.
Microsoft documents removal from the UIL as a way to troubleshoot mismatched identity and profile synchronization scenarios. At the same time, Microsoft warns that the removal procedure should be used for those troubleshooting purposes rather than as an unrestricted general cleanup method. [learn.microsoft.com]
The practical safety of removal depends on several factors:
- Whether the account is truly deleted.
- Whether the UPN has been reused.
- Whether the old and new accounts belong to the same person.
- Whether permissions have been reviewed.
- Whether the user owns or administers important resources.
- Whether workflows, applications, or custom solutions reference the user.
- How historical people fields behave after removal.
- Whether the target is SharePoint or OneDrive.
- Whether the organization has retention, audit, or compliance requirements.
Removing the old UserInfo entry can be appropriate for correcting a confirmed mismatch. It should not be confused with granting the new user the old user’s access.
After the legacy entry is removed, the new account should receive only the permissions appropriate to the new identity and current role.
For additional analysis, see:
Related article: [Is It Safe to Remove a User from the SharePoint User Information List?]
Link to be added.
Recommended Administrative Approach
A balanced strategy is usually better than universal deletion.
For an Active User ID Mismatch
- Confirm that the account was deleted and recreated or otherwise received a new identity.
- Confirm that the UPN matches a legacy SharePoint entry.
- Use Microsoft’s Site User Mismatch diagnostic for the affected site.
- Remove the confirmed old identity.
- Assign permissions to the new account explicitly.
- Validate access using the new account.
- Record the affected site so repeated incidents can be correlated.
- Investigate other high-probability sites used by the person.
The Microsoft diagnostic requires an appropriate administrative account. Microsoft also notes that it is unavailable in GCC High, DoD, and Microsoft 365 operated by 21Vianet environments. [learn.microsoft.com]
For Newly Created Accounts
- Check whether the UPN was previously assigned.
- Preserve both the new and historical Entra ID object IDs.
- Identify known sites associated with the previous identity.
- Correct confirmed legacy entries before granting new access.
- Avoid automatically restoring previous permissions.
During Offboarding
- Capture the departing account’s UPN and Entra ID object ID.
- Record site ownership and critical memberships.
- Transfer required ownership.
- Preserve an identity-to-site inventory where practical.
- Apply the organization’s UPN-retention policy.
- Remove SharePoint entries only according to a tested and documented policy.
Conclusion
Orphaned SharePoint users are not automatically defects. They are a consequence of SharePoint retaining site-level identity information after the associated Entra ID account has been deleted.
In many cases, these records remain harmless and help preserve historical context.
They become problematic when:
- An Entra ID account is deleted.
- A new account is created with the same UPN.
- The new account receives a different internal ID.
- SharePoint still associates the UPN with the old identity.
- The new user attempts to access a site containing that legacy identity.
SharePoint is correct not to transfer the old account’s permissions automatically. A reused UPN should not be treated as proof that two accounts represent the same security principal.
The operational limitation is that SharePoint may continue resolving the UPN against the old site-level identity even after a site owner intentionally grants access to the new account.
For one site, the solution is relatively straightforward: identify and remove the legacy entry, then assign the proper permissions to the new identity.
For an entire tenant, the problem is much harder because administrators must determine which sites contain the old identity.
An effective strategy therefore separates the work into three areas:
- Clean up the historical backlog.
- Stop tickets for newly created or recreated accounts.
- Stop the bleeding by improving offboarding and identity-history processes.
The right balance depends on tenant size, tenant age, employee turnover, UPN-reuse practices, and the organization’s tolerance for support incidents versus proactive engineering effort.
Related Articles
- User ID Mismatch in SharePoint: Detailed Troubleshooting and Resolution
Link to be added. - Is It Safe to Remove a User from the SharePoint User Information List?
Link to be added. - Managing Orphaned SharePoint Users in Small Microsoft 365 Tenants
Link to be added. - Managing Orphaned SharePoint Users in Large Microsoft 365 Tenants
Link to be added. - Estimating User ID Mismatch Risk in Your Microsoft 365 Tenant
Link to be added. - User Id Mismatch in OneDrive scenario
Another Way to Prevent User ID Mismatch: Identity Management
So far, we discussed the problem from a SharePoint administrator’s point of view. In that world, the typical solution is to find the legacy user in SharePoint and remove the old user entry from the User Information List.
However, there is another approach.
Instead of fixing User ID Mismatch issues after they occur, an organization can prevent many of them through proper identity management.
The root cause of most User ID Mismatch issues is not SharePoint itself. The issue typically appears when a user account is deleted and later a new account is created with the same UPN. SharePoint still contains records for the old identity, while the new account has a different internal identity value. As a result, SharePoint treats them as two different users even though the UPN is the same. [learn.microsoft.com], [learn.microsoft.com]
Because of that, Identity and Access Management (IAM) teams can reduce or eliminate many User ID Mismatch issues by ensuring that each person receives a unique UPN that is never reused.
For example, instead of recreating:
john.smith@contoso.com
for a rehired employee, the organization could assign a different UPN, such as:
john.smith2@contoso.com
or follow another naming standard that guarantees uniqueness.
With this approach, the new account never collides with the legacy SharePoint user record. As a result, User ID Mismatch issues are much less likely to occur.
Of course, this approach comes with its own challenges. Organizations often prefer to reuse the original UPN because it is easier for users, administrators, and business processes. In addition, changing naming standards may affect other systems that depend on predictable user names.
For that reason, UPN management should be viewed as an identity governance decision rather than a SharePoint administration task. SharePoint administrators can fix User ID Mismatch issues when they occur, but Identity and Access Management teams can often prevent those issues from appearing in the first place by implementing policies around account lifecycle management and UPN reuse.
In short, there are two ways to address User ID Mismatch:
- SharePoint approach: Find and remove the legacy SharePoint user records that cause the conflict.
- Identity management approach: Prevent UPN reuse so that the conflict never occurs.
The first approach is owned by SharePoint administrators. The second approach is owned by Identity and Access Management teams. In many organizations, the best long-term solution is a combination of both approaches.