When you prepare for a Copilot rollout in Microsoft 365, orphaned SharePoint permissions can cause unexpected data exposure. Orphaned permissions occur when user or group accounts are removed from Azure Active Directory but their access rights remain in SharePoint sites. Copilot indexes content from SharePoint and can surface information to users who should not see it. This article shows you how to find and remove orphaned permissions before enabling Copilot for your organization.
Key Takeaways: Finding Orphaned SharePoint Permissions
- SharePoint Online Management Shell (Get-SPOSiteUser): Lists all users with permissions on a site collection, including orphaned accounts.
- Microsoft Graph PowerShell (Get-MgUser): Checks if a user still exists in Azure AD; cross-reference with SharePoint user list to find orphans.
- SharePoint admin center > Site permissions > Check permissions: Manual method to verify a specific user’s access before deprovisioning.
Why Orphaned Permissions Matter for Copilot
Copilot accesses Microsoft Graph data, including SharePoint site content, to generate responses. When a user asks Copilot a question, the system retrieves documents that the user has permission to view. Orphaned permissions create a security gap: a former employee’s account is disabled in Azure AD, but the SharePoint site still grants read or edit rights to that account. If the account is later reactivated maliciously, Copilot could expose sensitive content. Microsoft recommends auditing all SharePoint permissions before enabling Copilot for Microsoft 365. The process involves exporting current permissions, comparing them against active Azure AD accounts, and removing any access that no longer has a valid user or group.
How Orphaned Permissions Occur
Orphaned permissions typically result from three scenarios. First, a user is deleted from Azure AD without first removing their SharePoint access. Second, a security group is removed from Azure AD but the group membership remains in SharePoint. Third, a site collection is migrated or restored from backup, and the permission entries reference accounts that no longer exist in the directory. In all cases, the SharePoint site still shows a user or group in its permission list, but the identity cannot be resolved to a current Azure AD object. Copilot cannot distinguish between a valid user and an orphaned entry because it relies on the SharePoint permission model, which still grants access to the unresolved identity.
Steps to Identify Orphaned SharePoint Permissions
Use the following method to export all site users and cross-reference with Azure AD. This approach works for SharePoint Online in Microsoft 365.
- Connect to SharePoint Online Management Shell
Open Windows PowerShell as an administrator. Run the commandConnect-SPOService -Url https://yourtenant-admin.sharepoint.com. Replaceyourtenantwith your tenant name. When prompted, sign in with a SharePoint admin account. - Export all site users for a site collection
RunGet-SPOSiteUser -Site https://yourtenant.sharepoint.com/sites/yoursite. This command returns every user and group that has permissions on the specified site. Record the LoginName and Email properties for each entry. - Repeat for all site collections
RunGet-SPOSite -Limit All | ForEach-Object { Get-SPOSiteUser -Site $_.Url }to export users across every site collection. Pipe the output to a CSV file for analysis:Get-SPOSite -Limit All | ForEach-Object { Get-SPOSiteUser -Site $_.Url } | Export-Csv -Path C:\temp\AllSiteUsers.csv -NoTypeInformation. - Connect to Microsoft Graph PowerShell
RunConnect-MgGraph -Scopes User.Read.All, Directory.Read.Alland sign in with a Global Admin or User Administrator account. - Check each user against Azure AD
For each LoginName in the CSV, runGet-MgUser -Filter "userPrincipalName eq 'user@domain.com'". If the command returns no output, the user does not exist in Azure AD and is orphaned. For groups, runGet-MgGroup -Filter "mail eq 'group@domain.com'". - Document orphaned entries
Create a new CSV listing the site URL, the orphaned LoginName, and the permission level (Read, Contribute, Full Control). This list will be used for removal.
Remove Orphaned Permissions from SharePoint Sites
After you identify orphaned permissions, remove them using the SharePoint Online Management Shell. Do not remove permissions for groups that still exist in Azure AD even if no members are assigned.
- Remove a single orphaned user from a site
RunRemove-SPOUser -Site https://yourtenant.sharepoint.com/sites/yoursite -LoginName user@domain.com. Confirm the prompt to remove the user. - Remove orphaned users in bulk
Import your CSV of orphaned entries. Use a loop:Import-Csv -Path C:\temp\OrphanedUsers.csv | ForEach-Object { Remove-SPOUser -Site $_.SiteUrl -LoginName $_.LoginName -Confirm:$false }. The-Confirm:$falseparameter suppresses confirmation prompts for each removal. - Verify removal
RunGet-SPOSiteUser -Site https://yourtenant.sharepoint.com/sites/yoursiteagain to confirm the orphaned user no longer appears in the list.
If Orphaned Permissions Persist After Removal
Orphaned users reappear after running Remove-SPOUser
This can happen if the user is a member of a security group that still has permissions. Remove the group from the site instead. Run Remove-SPOUser -Site https://yourtenant.sharepoint.com/sites/yoursite -LoginName group@domain.com. If the group is also orphaned, this removes the group permission entirely.
Permissions inherited from a parent site cannot be removed at the child site
Break inheritance on the child site first. Run Set-SPOSite -Identity https://yourtenant.sharepoint.com/sites/childsite -DenyAddAndCustomizePages $false to ensure you can manage permissions. Then use the SharePoint admin center to stop inheriting permissions and remove the orphaned entry.
Orphaned permissions in OneDrive sites
OneDrive sites are personal and do not usually have orphaned permissions from deleted users. However, if a user is deleted and their OneDrive is still shared with others, the shared links remain active. Use the SharePoint Online Management Shell with Get-SPOSite -IncludePersonalSite $true to list OneDrive sites, then check permissions as described above.
SharePoint Permission Audit Methods: PowerShell vs Admin Center
| Item | PowerShell (SPO Management Shell) | SharePoint admin center |
|---|---|---|
| Scope | All site collections in one command | One site at a time |
| Speed | Fast for bulk operations | Slower for large tenants |
| Orphan detection | Requires cross-reference with Azure AD | Manual check of each user |
| Removal | Bulk removal via script | Manual removal per user |
| Skill level | Requires PowerShell knowledge | No scripting required |
After you complete the audit and remove all orphaned permissions, you can enable Copilot for Microsoft 365 with confidence. Run the same audit quarterly to maintain security. Use Microsoft Purview Data Lifecycle Management to automatically remove permissions when a user is deleted from Azure AD. This prevents orphaned permissions from accumulating between audits.