SharePoint External Sharing: Secure Configuration Guide (2026)

How to Secure External Sharing in SharePoint Online

External sharing in SharePoint Online is controlled by a stack of settings, not one switch. The tenant-level sharing posture in the SharePoint admin centre sets a ceiling, each site can be more restrictive than that ceiling but never more permissive, and the default link type decides what users actually get when they click Share. Sensitivity labels, DLP and conditional access constrain the content and the session; auditing tells you who still has access afterwards.

Most organisations configure the tenant slider, assume the job is done, and never look at the other six layers. The result is usually a tenant that is technically restricted and practically wide open, because the default link type still hands out organisation-wide access on every share.

This guide covers each layer, then the part almost everyone skips: finding out what has already been shared and to whom.

Securing SharePoint Document Sharing Is a Layered Decision

In 2026 the question is no longer "should we let users share documents externally", most enterprises have settled on some form of external collaboration because the alternative is shadow IT in personal Dropbox accounts. The question is how to control the surface area of that sharing without making the collaboration experience unusable for the people doing the actual work.

This guide covers the seven layers that determine whether a SharePoint document library is securely shareable: tenant-level sharing posture, site-level overrides, default link behaviour, sensitivity labels, Data Loss Prevention, conditional access for external collaborators, and the audit and lifecycle controls that close the loop. Each layer is a distinct decision with distinct trade-offs. Most enterprises get one or two right and assume the rest are handled, they usually are not.

Layer 1: The Tenant-Level External Sharing Posture

The first decision is the most consequential and the easiest to misconfigure. The SharePoint admin centre under Policies → Sharing controls the maximum permitted external sharing posture for the entire tenant, expressed as a four-position slider:

• Anyone, anonymous links can be created. Anyone with the link can access the content without authenticating. This is the most permissive setting.
• New and existing guests, external collaborators must authenticate, but new guest accounts can be created on demand by end users sharing content.
• Existing guests, external collaborators must already exist as guest users in the tenant directory. End users cannot create new guests.
• Only people in your organization, no external sharing of any kind is permitted at the tenant level.

The tenant-level setting is a ceiling, not a default. Setting the slider to "Anyone" does not mean every site allows anonymous links; it means every site is permitted to allow anonymous links subject to the next layer down. Setting it to "Existing guests" means no site in the tenant can be more permissive, regardless of site-level configuration.

For most enterprises in regulated industries, "New and existing guests" is the right ceiling. Anonymous link sharing is rarely justifiable from a defensibility perspective in 2026, and "Existing guests" is operationally too restrictive for ad-hoc collaboration with new partners.

Layer 2: Per-Site Sharing Overrides

The tenant ceiling sets the maximum, but each site collection has its own sharing setting that can be more restrictive than the tenant. This is where most of the practical security work happens.

For a tenant with hundreds or thousands of SharePoint sites, the realistic pattern is:

• Default new sites to "Only people in your organization" or "Existing guests"
• Explicitly enable broader external sharing on specific sites that legitimately need it, partner collaboration sites, deal rooms, customer-facing project workspaces
• Audit which sites currently have broader-than-default sharing enabled, and why

The SharePoint admin centre lists every site with its current sharing setting under Sites → Active sites. Reviewing this list quarterly catches the situation where someone enabled "Anyone" sharing on a project site three years ago and the setting persisted long after the project ended.

For the broader context of how site sharing settings interact with SharePoint storage and lifecycle, see securing SharePoint document libraries.

Layer 3: Default Link Types and Link Behaviour

When a user clicks "Share" on a document in SharePoint, the default sharing link presented to them is set by tenant policy. The choice between three options materially affects how much risk casual sharing introduces.

The default link types are:

• Anyone with the link, produces an anonymous link. Anyone who receives the link can access the content without authenticating.
• People in your organization, anyone with a valid tenant identity who has the link can access. Equivalent to "any employee."
• People with existing access, does not change permissions; the link is just a convenience pointer for users who already have access.
• Specific people, explicit access grant to named recipients only.

For most enterprises the right tenant default is "Specific people". This forces users to think about who they are granting access to, rather than producing a link that is shareable to anyone in the organization by default. It is slightly less convenient for ad-hoc sharing but materially reduces the surface area of accidental over-sharing.

Tenant policy also controls link expiration for anonymous links, typically set to 30 days as a backstop in case anonymous sharing is enabled, and link permissions (view vs edit) defaults.

Layer 4: Sensitivity Labels for Shared Content

Microsoft Purview sensitivity labels provide the per-document classification layer that overrides container-level sharing settings. A document with a "Confidential, Internal Only" sensitivity label cannot be shared externally even if it lives in a site that permits external sharing.

The 2026 sensitivity label capabilities relevant to sharing controls:

• Encryption with permissions, a labelled document can be encrypted such that only specified users or groups can decrypt it, regardless of where the file is stored or how it is shared
• Container labelling, sites and Teams can be labelled, which restricts the sharing settings available to that container
• Auto-labelling, content matching policy patterns (credit card numbers, regulatory identifiers, custom keywords) can be automatically labelled and the corresponding sharing restrictions enforced without user action
• Default labels, new content created in a labelled container inherits the container label by default

Sensitivity labels are the only layer in this stack that travels with the document. A SharePoint sharing setting protects the document while it lives in SharePoint. A sensitivity label with encryption protects the document everywhere, including after it has been downloaded, forwarded, or copied to an unmanaged device.

For the design distinction between sensitivity labels (access control) and retention labels (preservation), see sensitivity labels vs retention labels in SharePoint.

Layer 5: Data Loss Prevention for SharePoint

Data Loss Prevention (DLP) policies in Microsoft Purview detect when content matching defined patterns is being shared and either warn the user, require justification, or block the share outright.

The DLP detection patterns relevant to SharePoint sharing include:

• Built-in sensitive information types, credit card numbers, national identifiers, healthcare records, financial account numbers, source code patterns
• Custom sensitive information types, keyword lists, dictionary matches, regex patterns specific to the enterprise (customer reference numbers, internal project codes, regulated product names)
• Trainable classifiers, machine-learning models that detect content types like contracts, source code, harassment, or industry-specific document categories
• Document properties, match on SharePoint column values such as project codes or classification metadata

The enforcement actions in 2026:

• Notify the user, pop-up notification when a sharing action triggers a DLP match
• Require business justification, user must enter a written justification before the share is permitted
• Restrict the share to internal recipients only, block external sharing of matched content even if the site permits external sharing
• Block the share outright, sharing action is denied; user is notified of the policy
• Notify administrators or compliance officers, alert workflow when high-severity matches occur

DLP is the layer that protects the enterprise from the specific scenario of a well-meaning employee about to share a spreadsheet that contains a thousand customer Social Security numbers because they did not realise it was in there.

Layer 6: Conditional Access for External Collaborators

External collaborators authenticated via guest accounts can be subjected to conditional access policies via Entra ID (formerly Azure AD). The 2026 policies most commonly applied to SharePoint guest access:

• Multi-factor authentication required for all guest sign-ins, basic hygiene; do not allow guest accounts to access shared content with password-only authentication
• Compliant device required, restricts guest access to devices managed by either the host tenant or a partner organization with managed-device attestation
• Block access from anonymous IP addresses or VPN exit nodes, reduces account-takeover surface from automated credential-stuffing attacks
• Session controls via Microsoft Defender for Cloud Apps, prevent download, restrict copy/paste, time-box guest session lifetime
• Block legacy authentication protocols, guest accounts should never need to use IMAP, POP, or basic authentication for SharePoint access

For external collaboration with a small number of trusted partners, cross-tenant access settings allow inbound/outbound trust configuration that streamlines guest sign-in while preserving the conditional access posture. For ad-hoc sharing with many one-off external recipients, per-policy conditional access scoped to the guest user type is the practical pattern.

Layer 7: Audit, Monitoring, and Lifecycle Controls

The previous six layers prevent or restrict sharing actions. This final layer ensures the enterprise can see what is actually being shared, with whom, and for how long.

The 2026 audit capabilities in Microsoft Purview:

• Sharing audit log entries, every share action (link created, permission granted, guest user added) is logged with actor, target, recipient, and timestamp
• Sensitive content discovery, Purview can scan SharePoint content for sensitive information types and report on which documents are most exposed
• Sharing analytics, admin-centre dashboards showing the volume of external sharing, the sites generating the most external links, and the guest accounts with the most access
• Access reviews, Entra ID access reviews can periodically prompt site owners to recertify which guest users still need access to which sites
• Guest user lifecycle, automatic expiration of guest accounts after a defined period of inactivity, with optional renewal workflows

The audit layer is what converts the previous six layers from theoretical policy into operational governance. Without it, no one can answer the question "what did we actually share externally last quarter, to whom, and is any of it still accessible?"

What Happens to Shared Content When It Is Archived

The seven layers above govern active SharePoint content. A consideration that becomes important as content ages: what happens to the sharing relationships when content is moved out of active SharePoint storage for archive or cost reasons?

The two common archive paths in 2026 each affect shared-link lifecycle differently because they archive at different granularities:

• Microsoft 365 Archive archives an entire site as a unit. Every shared link to any content in the archived site stops working - regardless of whether the linked file itself was actively being used - and stays broken until the entire site is reactivated. Reactivation is a tenant-admin action with associated reactivation fees per Microsoft's published Microsoft 365 Archive pricing.

• Squirrel file-level archiving archives individual files to customer-owned Azure Blob Storage based on inactivity policies. When a file is archived its original sharing relationships are released along with the file - a share on an archived file does not survive the archive. The practical difference is scope: only files that have actually been archived (typically those untouched for the policy window) are affected, and the rest of the site continues to work normally for both internal users and external collaborators. The archived file itself can be restored from Azure into SharePoint at any time, at which point a fresh share can be issued.

For enterprises with shared collaboration workspaces that accumulate years of content, the choice of archive mechanism directly affects the blast radius of an archive event on existing external sharing relationships. For the full design context, see the SharePoint archiving guide and the enterprise buyer's checklist for SharePoint archiving.

A Reference Configuration for Most Enterprises

The pragmatic default configuration for an enterprise that wants secure-by-default external sharing without making collaboration painful:

Layer	Recommended setting
Tenant ceiling	New and existing guests
New-site default	Only people in your organization
Default link type	Specific people
Anonymous link expiration	30 days maximum (if anonymous enabled at all on specific sites)
Sensitivity labels	Three-tier (Public / Internal / Confidential) with auto-labelling on regulated content
DLP policies	Block external share of regulated identifiers; notify on internal share of confidential labels
Guest conditional access	MFA required, session control via Defender for Cloud Apps for confidential sites
Access reviews	Quarterly recertification of guest access on confidential sites
Archive integration	File-level archive (impacts only archived files) rather than site-level archive (breaks every link in the site at once)

This is not the most secure possible configuration, it is the configuration where end users continue to use the platform without routing around it. Tighter postures are appropriate for specific industries (defence, classified, regulated healthcare with explicit data residency requirements) but trade collaboration ergonomics for additional defensibility.

Spotting risky sharing after the fact means reading the audit log. Doing it continuously means monitoring those events as they happen: see SharePoint audit log monitoring and alerts.

A Quick Decision Matrix

Scenario	The right configuration
One-time file delivery to a client	Specific-people link with an expiry date
Temporary vendor access	Specific-people link, expiry, MFA through conditional access
Long-term partner collaboration	Guest accounts via Entra ID B2B, sensitivity labels, quarterly access reviews
Regulated or labelled content	Tenant ceiling at existing guests, DLP policy, no anonymous links

The Layer Everyone Skips: What Has Already Been Shared

Configuration governs what can happen next. It tells you nothing about what has already happened, and in most tenants the accumulated sharing is the larger exposure: links created years ago under a more permissive setting, guests who left the partner organisation, anonymous links that were never given an expiry because expiry was not enforced at the time.

Tightening the tenant slider does not revoke any of it. Existing links keep working.

Three questions are worth being able to answer at any time:

• Which anonymous links exist, and on what content? These are the ones that need no authentication, so they are the only shares where you genuinely cannot tell who used them.
• Which external guests still have access, and are they still employed by the partner? Guest offboarding is nobody's job in most organisations.
• Which shares involve labelled or sensitive content? A share of a Confidential-labelled document is a different event from a share of a meeting agenda.

The audit log records every sharing event, so the raw material exists, but it is a query surface rather than a monitoring one: no alerting, no standing inventory, and a retention window. See SharePoint audit log for what it does and does not cover.

Burrow maintains that inventory continuously. It monitors every SharePoint and Entra ID audit event, keeps a standing record of external shares covering guest shares, anonymous links and the guests themselves, and emails alerts when risky sharing happens rather than waiting for someone to run a report.

The standing external-share inventory: what is currently shared, with whom, and by which link type.

Sharing detections are split by what actually happened: anonymous link creation, sharing to an external party, sharing to a known partner domain, and organisation-wide sharing are separate signals with different severities, because they carry different risk. Alerts name the sensitivity label involved when there is one.

Burrow is a SaaS addon to the Squirrel platform, so for existing Squirrel customers it is a subscription change rather than a new deployment.

Frequently Asked Questions

What is the difference between the tenant and site external sharing settings in SharePoint?

The tenant setting is a ceiling, not a default. It defines the most permissive sharing any site is allowed to use. Each site collection has its own setting that can be more restrictive than the tenant but never more permissive. Setting the tenant to Anyone does not enable anonymous links everywhere; it permits sites to enable them.

Should I allow anonymous "Anyone with the link" sharing?

Rarely. An anonymous link requires no authentication, so the audit trail cannot tell you who actually opened the content, which is usually indefensible for regulated material. For most enterprises the appropriate tenant ceiling is New and existing guests, which forces external collaborators to authenticate while still allowing ad-hoc collaboration with new partners.

Does tightening external sharing settings revoke links that already exist?

No. Changing the tenant or site sharing posture governs what can be created from that point on. Links created under a previously permissive setting continue to work, which is why reviewing existing shares is a separate exercise from configuring the policy.

How do I find out what has already been shared externally in SharePoint?

Sharing events are recorded in the Microsoft 365 audit log, which you can search in the Purview portal or through PowerShell. The limits are that it has no alerting, no standing inventory of currently-active shares, and a finite retention window, so it answers a question you already thought to ask rather than telling you when something happens.

How often should external access be reviewed?

Quarterly access reviews are a common baseline for guest accounts. The higher-value control is continuous monitoring of sharing events as they occur, because a quarterly review finds an exposure up to three months after it was created.

Can external users be required to use MFA in SharePoint?

Yes. Guest accounts in Entra ID are subject to conditional access policies in the same way as internal accounts, so MFA, device compliance and location conditions can all be applied to external collaborators. Anonymous links bypass this entirely, since there is no account to apply a policy to.

Related reading

• SharePoint audit log: what it records and how to search it
• SharePoint audit log monitoring and alerts
• SharePoint mass deletion: telling an attack from a folder move
• Role-based access control in SharePoint Online

Review What Is Already Out There

Configuring the seven layers protects what happens next. If you also want to know what has already been shared, and be told when something risky happens rather than finding it in a quarterly review, see how Burrow monitors SharePoint sharing events. Questions: sales@smikar.com.