Security

SharePoint External Sharing: Enterprise Configuration Playbook

The four-posture decision framework for SharePoint external sharing: open, partner-only, gated, locked. With tenant vs site controls, guest lifecycle, DLP pack, and PowerShell.

SharePoint Support Team2026-06-2713 min read
SharePoint External Sharing: Enterprise Configuration Playbook - Security guide by SharePoint Support
SharePoint External Sharing: Enterprise Configuration Playbook - Expert Security guidance from SharePoint Support

"Can we just turn external sharing on?" is one of the most consequential single decisions in an enterprise SharePoint tenant. The answer is almost never a binary yes or no — it's a posture decision that varies by site, sensitivity, and regulatory profile. This playbook is the four-posture framework we use with financial services, healthcare, manufacturing, and defense-adjacent clients, along with the PowerShell to implement each posture, a Purview DLP rule pack, and the sensitivity label integration.

The four-posture decision framework

External sharing is not one policy — it's a family of policies applied at four scopes: the tenant, the site, the sensitivity label, and the specific link. The four postures below represent the practical combinations we see in enterprise deployments.

SharePoint governance framework showing policies, roles, and compliance
SharePoint governance model with policies and compliance controls

Posture 1: Open (public collaboration model)

  • Tenant sharing setting: Anyone (anonymous links allowed)
  • Site sharing: most sites inherit tenant; regulated sites more restrictive
  • Link default: People in your organization
  • Guest lifecycle: review annually, no automatic expiration
  • Fits: consulting firms, agencies, professional services with heavy client collaboration
  • Regulatory posture: low — not typically compatible with HIPAA/SOX default sites

Posture 2: Partner-only (authenticated B2B)

  • Tenant sharing setting: New and existing guests (authenticated only)
  • Site sharing: most sites allow guests; sensitive sites internal-only
  • Link default: Specific people
  • Guest lifecycle: invited on demand, quarterly review, 90-day inactivity expiration
  • Fits: financial services, manufacturing, mid-market SaaS with structured vendor programs
  • Regulatory posture: moderate — works for SOX, PCI, most GDPR scenarios with proper DLP

Posture 3: Gated (approval-based)

  • Tenant sharing setting: Existing guests only, no new invites without approval
  • Site sharing: site-by-site allowlist of who can share
  • Link default: Specific people, no forwarding
  • Guest lifecycle: central identity governance workflow, sponsor required, 30 to 60 day expiration
  • Fits: healthcare with PHI, defense contractors, regulated pharmaceutical
  • Regulatory posture: high — supports HIPAA, ITAR-adjacent (verify with counsel), FedRAMP-adjacent

Posture 4: Locked (internal only)

  • Tenant sharing setting: Only people in your organization
  • Site sharing: internal only across the board
  • Link default: Specific people
  • Guest lifecycle: N/A
  • Fits: intelligence-adjacent workloads, high-security government, some financial trading environments
  • Regulatory posture: maximum — supports classified-adjacent workloads (with appropriate cloud)

Most enterprises land in Posture 2 with certain sites elevated to Posture 3 for regulated data. Very few real enterprises can operate at Posture 1 (external partners still need attribution) or Posture 4 (some external work always exists).

Tenant-level configuration

Tenant-level settings define the ceiling — no site can be more permissive than the tenant. Use the SharePoint Online Management Shell.

```powershell

# Connect

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

# Posture 2: Partner-only baseline

Set-SPOTenant `

-SharingCapability ExternalUserSharingOnly `

-DefaultSharingLinkType Direct `

-PreventExternalUsersFromResharing $true `

-ShowAllUsersClaim $false `

-ShowEveryoneClaim $false `

-ShowEveryoneExceptExternalUsersClaim $true `

-RequireAcceptingAccountMatchInvitedAccount $true `

-ExternalUserExpirationRequired $true `

-ExternalUserExpireInDays 90 `

-EmailAttestationRequired $true `

-EmailAttestationReAuthDays 30 `

-DefaultLinkPermission View

```

Break down what each of those actually does:

| Setting | What it enforces |

|---------|------------------|

| SharingCapability | The ceiling: Disabled, ExistingExternalUserSharingOnly, ExternalUserSharingOnly, ExternalUserAndGuestSharing |

| DefaultSharingLinkType | Direct means "specific people" is the default link type instead of "anyone" |

| PreventExternalUsersFromResharing | Blocks a guest from forwarding your link to another guest |

| RequireAcceptingAccountMatchInvitedAccount | Guest must sign in with the email address you invited |

| ExternalUserExpirationRequired | Guest accounts auto-expire (see next setting) |

| ExternalUserExpireInDays | Days before an unused guest account is disabled |

| EmailAttestationRequired | Guest must re-verify their email periodically |

| DefaultLinkPermission | View instead of Edit by default |

Restricting the "Everyone" claim is one of the highest-value settings — it prevents ad-hoc tenant-wide sharing that shows up in permissions audits.

Site-level configuration

Site-level settings can only tighten the tenant policy, never loosen it.

```powershell

# Elevate a specific site to Posture 3 (gated)

Set-SPOSite -Identity https://contoso.sharepoint.com/sites/FinanceControlled `

-SharingCapability ExistingExternalUserSharingOnly `

-DefaultSharingLinkType Direct `

-DefaultLinkPermission View `

-DisableCompanyWideSharingLinks Disabled `

-OverrideTenantAnonymousLinkExpirationPolicy $true `

-AnonymousLinkExpirationInDays 7

```

Common site-level patterns:

  • HR site at Posture 3: existing guests only, no new invites without HR approval
  • Legal e-discovery at Posture 4: internal only, no exceptions
  • Marketing campaign site at Posture 2: partner-authenticated, with DLP rules preventing PHI
  • Executive team site at Posture 4: internal only
  • Board portal at Posture 3: existing guests only, board members' organizations pre-approved

Microsoft's SharePoint external sharing overview is the canonical reference for the settings model, and the change external sharing for a site documentation covers the specific commands.

Guest lifecycle policy

The four-phase lifecycle applies across all postures except Locked.

Invite

  • Sponsor is a named internal user with budget authority over the collaboration
  • Business purpose is captured (dropdown or free text, retained for audit)
  • Sensitivity label is set on the site or content being shared
  • Expiration date is set at invite time (or defaults from tenant policy)

Activate

  • Guest accepts invite within 7 days or invite auto-expires
  • Guest's home tenant is verified via Entra External ID
  • Guest sees a company-branded consent page with acceptable use terms
  • First-access is logged and flagged if unusual

Review

  • Quarterly access reviews via Entra ID Governance access reviews
  • Sponsor certifies the guest still needs access
  • Non-response defaults to revoke (not extend)
  • Reviews are logged for SOX/ISO evidence

Expire

  • Guest accounts inactive for 90 days are disabled
  • Guest accounts inactive for 180 days are deleted
  • Sponsor is notified before disable and before delete
  • Deletion cascades to remove the guest from all SharePoint site collections

Purview DLP rule pack for external sharing

External sharing without DLP is a compliance gap. This rule pack covers the highest-value scenarios.

Rule 1: Block sharing of documents with high-confidence PHI

  • Content match: Health information built-in classifier, 3+ instances
  • Scope: SharePoint sites, OneDrive
  • Action: Block sharing to external users, notify content owner
  • Fits: any tenant handling PHI, including business associates

Rule 2: Warn on sharing documents with financial data

  • Content match: Credit card, SSN, or bank account patterns
  • Scope: SharePoint sites (not internal comms)
  • Action: Show policy tip to sharer, log event, allow with justification
  • Fits: SOX, PCI scope, financial services

Rule 3: Block anonymous links to sensitivity-labeled content

  • Trigger: File is labeled Confidential, Highly Confidential, or Restricted
  • Scope: Tenant-wide
  • Action: Block anonymous link creation, force specific-people link
  • Fits: any organization using sensitivity labels

Rule 4: Alert on unusual external sharing volume

  • Trigger: Single user shares more than 100 files externally in 24 hours
  • Scope: Tenant-wide
  • Action: Alert to Sentinel, notify SecOps
  • Fits: insider threat and account compromise detection

Rule 5: Block resharing by guests

  • Trigger: Guest attempts to reshare a document to another guest
  • Scope: Tenant-wide (enforced by tenant setting above)
  • Action: Block, log
  • Fits: all Posture 2, 3, 4 tenants

Sensitivity label integration

External sharing without label enforcement is a leaky abstraction. The pattern we recommend:

  • Public / Non-business → no external sharing restriction
  • General / Internal → external sharing allowed for existing guests
  • Confidential → external sharing requires justification, specific people links only, encrypt in transit
  • Highly Confidential → external sharing blocked, exceptions require site admin approval
  • Restricted → external sharing blocked with no exceptions, DLP enforced

Labels applied at the file level travel with the file, so a Highly Confidential document copied to a personal OneDrive still cannot be shared externally.

Regulated industries decision matrix

| Industry | Tenant posture | Site posture (regulated data) | Site posture (general work) |

|----------|----------------|-------------------------------|------------------------------|

| Healthcare (HIPAA) | Posture 3 | Posture 4 for PHI | Posture 2 for admin |

| Financial services (SOX) | Posture 2 | Posture 3 for financial reporting | Posture 2 for general |

| Public sector (FedRAMP Moderate) | Posture 3 | Posture 4 for controlled | Posture 3 for general |

| Manufacturing (ITAR-adjacent) | Posture 3 | Posture 4 for ITAR data | Posture 2 for general |

| Professional services | Posture 2 | Posture 3 for client-specific | Posture 2 for general |

| K-12 education | Posture 2 | Posture 4 for student data | Posture 2 for general |

Common configuration mistakes

  • Loosening tenant policy to accommodate one site: the tenant setting is the ceiling; loosening it exposes every other site. Instead, add a specific site to a more permissive site collection with a separate governance model.
  • Skipping the "reshare" block: without PreventExternalUsersFromResharing, a single guest can propagate your document across their organization.
  • Not requiring account match on invite: allows a guest to accept the invite in a different account than the invited one, breaking your audit trail.
  • Anonymous link expiration set to "never": any anonymous link created today is a security debt forever. Set 30 days maximum, ideally 7 to 14 days.
  • Not applying DLP rules to OneDrive: OneDrive is where the ad-hoc sharing happens. DLP must cover SharePoint and OneDrive as a set.
  • Guests in privileged Entra roles: occasionally a guest ends up as a Global Reader or worse through nested groups. Alert on any guest gaining a privileged role.

Our SharePoint consulting service implements this playbook as a standard governance engagement, including the Purview DLP pack and Entra ID Governance workflows. For SharePoint intranet deployments where external sharing is a first-class use case, we integrate the posture decisions into the site provisioning template so each new site inherits the right defaults.

Frequently asked external sharing questions

Expert help from our SharePoint consultants

If your team needs to move from ad-hoc external sharing to a defensible governance model, our SharePoint consulting team implements the four-posture framework end-to-end — including tenant hardening, site-by-site classification, Purview DLP pack, sensitivity label integration, and the Entra ID Governance guest lifecycle workflow. Start with our contact page to schedule a discovery call.

Share this article:

Written by the SharePoint Support Team

Senior SharePoint Consultants | 25+ Years Microsoft Ecosystem Experience

Our senior SharePoint consultants bring deep expertise spanning 500+ enterprise migrations and compliance implementations across HIPAA, SOC 2, and FedRAMP environments. We cover SharePoint Online, Microsoft 365, migrations, Copilot readiness, and large-scale governance.

Frequently Asked Questions

What is the difference between "Anyone" and "Anyone Except External Users" in SharePoint sharing?
They are opposite ends of the sharing scale despite sounding similar. "Anyone" allows anonymous link creation — anyone with the URL can access without signing in. "Everyone Except External Users" (EEEU) is an internal claim granting access to every authenticated user in your tenant. Neither is appropriate for most content: Anyone creates untraceable external access, and EEEU grants tenant-wide internal access. The recommendation is "Specific people" links as the default, with occasional exceptions documented and time-bounded.
How do we prevent guests from resharing our documents?
Two settings work together. At the tenant level, PreventExternalUsersFromResharing set to true blocks a guest from creating a new sharing link from a file they have access to. At the site level, DefaultSharingLinkType set to Direct means the default link is specific-people rather than tenant-wide. Combined with sensitivity labels that encrypt the document with usage rights, you get three defense layers. The tenant setting is the most important — enabling it is essentially free from a functional standpoint but plugs the highest-impact leak vector.
Do guest users count against our Microsoft 365 license?
Not directly for SharePoint access under most licensing scenarios. Guest access to SharePoint via Entra External ID is included in the tenant's SharePoint license, up to the External Collaboration limits published by Microsoft. Where guests do incur cost is in Entra ID Governance (for the guest lifecycle workflow), Microsoft Purview (for DLP rules applied to guest sharing), and Entra External ID Premium P2 (if you use Identity Protection risk scoring on guests). Budget $2 to $8 per guest per month for the full governance stack, though this varies by tenant size and Microsoft licensing agreement.
How do we handle guest access reviews at scale?
Entra ID Governance access reviews are the scalable pattern. Configure quarterly reviews grouped by the SharePoint site where the guest has access, assign the review to the site owner, and set the default action to "remove access if reviewer does not respond." For a tenant with 3,000 guests spread across 200 sites, the review workload distributes to 200 site owners with 15 guests each — an achievable manual review. The critical piece is that non-response defaults to revoke, not extend. Extending on non-response defeats the purpose of the review.
Can we allow external sharing on some sites but not others?
Yes, this is the standard enterprise pattern. Set the tenant to your highest permitted posture (typically Posture 2 or 3), then use Set-SPOSite to restrict specific sites to a stricter policy. For example, tenant is at ExternalUserSharingOnly, but the HR site is set to Disabled and the executive team site is set to ExistingExternalUserSharingOnly. Site-level settings can only tighten the tenant policy, never loosen it. This is why the tenant is the ceiling and site-level is a per-site floor.
What happens to shared content when a guest account expires?
When a guest account is disabled (typically after 90 days of inactivity), the guest immediately loses access to all shared content but the content itself is not deleted. The guest still appears in permissions lists as a disabled principal until it is deleted (typically at 180 days of inactivity), at which point the permissions entries are cleaned up automatically. If the same person is later re-invited using the same email, they receive a new guest account with no access to the previous content — sharing must be recreated. This is by design, so audit trails clearly separate the two sessions.
How do we audit external sharing after enabling it?
Three complementary log sources cover audit needs. First, the Purview unified audit log records every sharing action with sharer, recipient, resource, and permission level. Ingest into Sentinel for retention beyond the default 90 days. Second, the Entra ID sign-in logs record every guest authentication and can be filtered for anomalies. Third, the SharePoint sharing report in the admin center provides an operational view. For SOX or HIPAA evidence, retain the Purview audit log for the applicable retention period (7 years for SOX financial reporting) and configure alerts on high-risk patterns like bulk external sharing or sharing to competitor domains.

Need Expert Help?

Our SharePoint consultants are ready to help you implement these strategies in your organization.