SharePoint External Sharing Without Losing Control

External sharing is the feature most likely to be either switched off entirely because it feels risky, or left wide open because someone needed it working by Friday. Both are avoidable. The controls are layered and reasonably granular once you understand which layer does what.

The thing to grasp first: sharing is governed at three levels, and the most restrictive one wins. A site cannot be more permissive than the tenant, and a file cannot be more permissive than its site.

The three layers

Level	Set in	Governs
Tenant	SharePoint admin centre → Policies → Sharing	The maximum permitted anywhere
Site	Per site, in the admin centre or PowerShell	That site, up to the tenant ceiling
Item	The Share dialog	One file or folder, up to the site ceiling

Sharing settings run from most to least restrictive:

• Only people in your organisation — external sharing off
• Existing guests — only people already in the directory
• New and existing guests — guests must sign in or verify their identity with a code
• Anyone — anonymous links, no sign-in at all

"Anyone" is the setting that deserves real thought. A link created under it works for whoever holds it. It can be forwarded, pasted into a ticket, or indexed if it ever lands somewhere public. There are legitimate uses — sending a document to someone whose organisation blocks guest sign-in, for instance — but it should be a deliberate exception rather than the tenant default.

Configuring it deliberately

The pattern that works in most organisations: set the tenant to what the most permissive legitimate scenario needs, then set each site to what it actually needs.

Connect-SPOService -Url "https://contoso-admin.sharepoint.com"

# Tenant ceiling: guests must authenticate. Anonymous links are not permitted.
Set-SPOTenant -SharingCapability ExternalUserSharingOnly

# A project site that genuinely collaborates with a partner
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/partner-project" `
  -SharingCapability ExternalUserSharingOnly

# An internal-only site, locked below the tenant ceiling
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/hr" `
  -SharingCapability Disabled

Setting the tenant to ExistingExternalUserSharingOnly is worth considering as a default. It means guests must already have been invited through a governed process rather than added ad hoc by whoever is sharing.

Controls worth setting alongside it

Sharing capability is the headline, but these matter as much in practice:

• Link expiration. Anyone-links can be made to expire after a set number of days. Where anonymous sharing is permitted at all, an expiry is the difference between a temporary share and a permanent one nobody remembers creating.
• Default link type. The default in the Share dialog decides what most people send. Setting it to "Specific people" rather than "Anyone" changes behaviour far more effectively than training does.
• Default permission. View rather than Edit as the default is a small change with a large effect on accidental modification.
• Domain allow or block lists. Restricting sharing to named partner domains is a strong control where the set of partners is known.
• Guest re-authentication interval. How long a verified guest stays verified.

Guests, and where they actually live

A misconception worth correcting: external users are not stored in SharePoint. Sharing a site with someone outside the organisation creates a guest account in Microsoft Entra ID, and SharePoint permissions then reference that account.

This matters for three reasons:

• Guest lifecycle is an identity problem, not a SharePoint one. Removing someone's access to one site does not remove their guest account.
• Conditional Access policies can apply to guests, which is how you require multi-factor authentication for external access.
• Entra ID access reviews can periodically ask an owner whether each guest still needs access — the most effective control available against guest accounts accumulating indefinitely.

Auditing what is already shared

Most organisations turning attention to this have years of accumulated sharing. Two things are worth knowing before you start.

The sharing reports in the SharePoint admin centre will tell you which sites have external sharing enabled and which guests exist. Beyond that, the audit log records sharing events, and PowerShell can enumerate external users per site:

# External users with access to a site
Get-SPOExternalUser -SiteUrl "https://contoso.sharepoint.com/sites/partner-project" |
  Select-Object DisplayName, Email, WhenCreated |
  Sort-Object WhenCreated

Tightening a setting revokes access that people may currently be using. Changing SharingCapability on a site with active guests will break their access, so identify who is affected before changing it rather than after.

Common mistakes and better practice

• Setting the tenant to Anyone so one project works. Raise the site, not the ceiling.
• Enabling anonymous links with no expiry. A link that never expires is permanent access granted by accident.
• Leaving the default link type as Anyone. Whatever the dialog defaults to is what most people will send.
• Treating guests as a SharePoint concern. They are Entra ID accounts. Govern them there, with access reviews.
• Sharing individual files repeatedly. Item-level permissions accumulate into a state nobody can audit. Share a site or a library and manage membership.
• Tightening settings without checking impact. It revokes live access. Enumerate the affected guests first.
• Never reviewing. Guest access accumulates silently. Periodic review is the only thing that reverses it.

Troubleshooting

Symptom	Cause	Resolution
Share dialog offers no external option	Site or tenant sharing disabled	Check the site's SharingCapability against the tenant ceiling
Guest gets "access denied" after accepting	Invitation accepted with a different address than it was sent to	Re-invite the exact address they sign in with
A link stopped working	Expiry reached, or the site setting was tightened	Check link expiration policy and recent sharing changes
Anyone-links unavailable despite tenant allowing them	Site set more restrictively than the tenant	Site settings cannot exceed the tenant, but can sit below it
Guest prompted repeatedly to verify	Re-authentication interval	Adjust the guest access expiry, weighing convenience against control
Guest cannot open a file but can see the site	Broken permission inheritance on that item	Check item-level permissions

Frequently asked questions

Do external users consume a licence?

Guest collaboration in SharePoint does not require assigning them a Microsoft 365 licence. Some Entra ID features that apply to guests are licensed separately, so confirm against current licensing documentation for your specific scenario.

Can a site be more permissive than the tenant?

No. The tenant setting is a ceiling. Sites can be equal or more restrictive.

Where do external users actually exist?

As guest accounts in Microsoft Entra ID. SharePoint permissions reference those accounts.

Does removing site access delete the guest account?

No. The account remains in the directory until it is removed there. This is why guest access reviews matter.

Is anonymous sharing ever appropriate?

Sometimes — for recipients whose organisation blocks guest sign-in, for example. Where it is enabled, pair it with link expiry and view-only defaults.

Getting to a defensible position

The configuration that holds up over time is usually: a tenant ceiling requiring guests to authenticate, sites raised individually where collaboration genuinely happens, default links set to specific people, expiry on anything anonymous, and a recurring access review in Entra ID.

None of that prevents collaboration. It prevents the accumulation of sharing nobody remembers granting — which is what audits actually find.