SharePoint Online and OneDrive make collaboration easy. That is one of their biggest strengths.
But over time, every tenant collects sharing links: links created for vendors, project teams, external reviewers, temporary users, and one-off exceptions that nobody remembers six months later. Some are still valid. Some are stale. Some may expose more content than intended.
The challenge is not that sharing links exist. The challenge is knowing where they exist, who they expose content to, and whether they still belong there.
That is why I built a PowerShell script to help identify and process SharePoint Online sharing links across a tenant:
Get-and-Remove-SPOSharingLinks.ps1
Why this matters
Most SharePoint admins have been asked some version of these questions:
- Can you tell me what has been shared externally?
- Do we have anonymous links anywhere?
- Can we clean up old sharing links?
- Can we prove who has access to this content?
- What sites have the most sharing activity?
The SharePoint Admin Center and Microsoft Purview provide useful views, but they are not always enough when you need a repeatable, tenant-wide inventory that can be reviewed, filtered, exported, and acted on.
Sharing links can create several governance challenges:
| Risk | Why it matters |
|---|---|
| Anyone links | Content may be accessible without sign-in if the link is still valid. |
| Organization links | Content can spread broadly inside the tenant. |
| Specific people links | These are safer, but still need lifecycle review. |
| External user access | External collaboration can persist after the business need ends. |
| Stale project content | Old content often keeps old permissions. |
| Manual cleanup | Clicking through sites and libraries does not scale. |
The goal is not to block collaboration. The goal is to make sharing visible and manageable.
What the script does
The script is designed to help admins identify and process sharing links across SharePoint Online and OneDrive content.
At a high level, it helps with:
- Connecting to SharePoint Online.
- Scanning target sites and content.
- Finding sharing links.
- Reporting link details.
- Supporting review before cleanup.
- Removing links when you are ready to take action.
The most important design choice is that this kind of script should be used in phases:
- Inventory first
- Review the results
- Decide what should be removed
- Run cleanup intentionally
That workflow keeps the process safer than jumping straight to deletion.
A practical workflow
Step 1: Start with reporting
The first run should always be discovery-focused.
You want to understand what exists before taking action. That means producing a report that can be reviewed by site owners, security teams, compliance stakeholders, or project owners.
The report should answer questions like:
- Which site contains the shared content?
- Which library or item is affected?
- What type of sharing link exists?
- Is the link anonymous, organization-wide, or scoped to specific people?
- Who created it?
- When was it created or last modified?
- Is it still needed?
This gives you a working inventory instead of relying on assumptions.
Step 2: Sort by risk
Not every sharing link deserves the same level of concern.
I usually think about sharing links in this order:
| Priority | Link type | Recommended action |
|---|---|---|
| 1 | Anyone links | Review first; remove if no active business justification exists. |
| 2 | Organization-wide links | Review for sensitive or overexposed content. |
| 3 | External specific people links | Confirm the external user still needs access. |
| 4 | Internal specific people links | Usually lower risk, but still useful for cleanup. |
You may also want to prioritize by site type:
- Executive or leadership sites
- HR, legal, finance, or regulated content
- OneDrive sites for departed users
- Old project sites
- Sites with many unique permissions
- Sites with stale content
This helps you focus effort where it matters most.
Step 3: Review with business owners
Automated reporting is useful, but removal decisions should still be thoughtful.
A sharing link may look risky from the outside but still support an active business process. On the other hand, a link may have been created years ago for a temporary project and no longer have a valid reason to exist.
Before removing links broadly, I recommend sharing the report with the appropriate owners and asking:
- Is this content still active?
- Does this external party still need access?
- Can this be replaced with a more controlled permission model?
- Should the content be moved, archived, or deleted?
- Is this site still governed by the right owner?
This turns the script output into a governance conversation.
Step 4: Remove links in controlled batches
Once you have reviewed the results, cleanup should be done in batches.
- Start with a small pilot site.
- Remove only a specific link type.
- Validate user impact.
- Expand to more sites.
- Keep before-and-after reports.
This is especially important for external collaboration-heavy environments. Removing links can interrupt active business processes if done without review.
Example cleanup strategy
A safe phased approach might look like this:
| Phase | Scope | Goal |
|---|---|---|
| Phase 1 | Report only | Build a tenant-wide inventory of sharing links. |
| Phase 2 | High-risk sites | Review sensitive sites first. |
| Phase 3 | Anyone links | Remove anonymous links that no longer have justification. |
| Phase 4 | External links | Validate external access with business owners. |
| Phase 5 | Ongoing monitoring | Re-run the report monthly or quarterly. |
This keeps the process manageable and auditable.
What makes this script useful
The value of this script is not just that it finds links. The value is that it supports repeatable governance.
A good sharing-link review process should be:
- Repeatable — you can run it again later.
- Exportable — results can be reviewed outside PowerShell.
- Targeted — you can focus on specific sites or scenarios.
- Auditable — you can keep evidence of what was found and what changed.
- Safe — cleanup happens after review, not by accident.
That is much better than manually clicking around the admin center and hoping you found everything.
Where this fits in a broader security review
Sharing links are only one part of SharePoint access governance.
A complete review may also include:
- Site owners and site collection admins
- Microsoft 365 group membership
- Direct item-level permissions
- External users
- Guest accounts
- Everyone and Everyone except external users grants
- Sensitivity labels
- Retention labels
- Stale content
- Orphaned OneDrive sites
That is why I see this script as part of a larger toolkit. Once you can report on sharing links, you can combine that with other scripts to build a stronger picture of content exposure across the tenant.
Recommended next steps
If you want to use this in your own environment, I recommend this order:
- Run the script in report-only mode.
- Review the output for Anyone links and external links.
- Prioritize sensitive sites.
- Validate with site owners.
- Remove links in small batches.
- Schedule recurring reviews.
The goal is not to eliminate sharing. The goal is to make sure sharing is intentional.
Final thoughts
SharePoint sharing links are useful, but they need lifecycle management. Without regular review, old links can quietly become long-term access paths that nobody owns.
Scripts like this help admins move from reactive cleanup to proactive governance. Instead of waiting for a security question or audit request, you can build a repeatable process for finding, reviewing, and removing risky sharing links at scale.
You can find the script here: