External sharing end to end

The guest object (what an external user actually is)

When you share externally with sign-in, the recipient becomes an Entra B2B guest — a guest user object in your directory (#EXT# in the UPN) that can be granted access, added to groups, and governed like any principal. Guests are the durable external identity; Anyone links are the exception that grant access with no object at all (anonymous, URL-only). Knowing which of the two a given share used is the first question in any external-access review.

The layered switches (all must agree)

External access is an AND of independent layers — the most restrictive wins:

1. Entra external collaboration settings — the directory-level policy on whether/how guests can be invited at all, and by whom.
2. SharePoint tenant SharingCapability — the SPO ceiling (tenant-sharing concept): Disabled → ExistingExternalUserSharingOnly → ExternalUserSharingOnly → ExternalUserAndGuestSharing.
3. Per-site sharing level — can only tighten below the tenant.
4. OneDrive OneDriveSharingCapability — a separate ceiling for personal storage.
5. Domain allow/block lists and B2B integration — SharePoint-OneDrive B2B integration (EnableAzureADB2BIntegration) routes external sharing through Entra B2B so guest governance (access reviews, Conditional Access) applies.

If external sharing "doesn't work," it's almost always a lower layer overriding an upper one — e.g. tenant permits it but the site is set to internal-only, or the recipient's domain is blocked.

OTP verification (recipients without an account)

Share with an external email that has no Microsoft/guest account and SharePoint uses a one-time passcode: the recipient enters their email, receives a time-limited code, and is verified per session as a guest — no password, no persistent account required unless they redeem a full invite. This is how ad-hoc external recipients get in without you provisioning anything, while still being an authenticated, auditable guest rather than anonymous.

The failure modes

• Anonymous vs guest confusion — an Anyone link has no identity to audit or revoke individually; it's revoked by killing the link. Prefer Specific-people (which creates/uses a guest) for anything you'll need to account for.
• Guest sprawl — guests accumulate and outlive the collaboration; without expiration (ExternalUserExpirationRequired) and access reviews they become a standing external attack surface.
• Resharing — a guest with edit rights can sometimes reshare; bound this with site settings and least-privilege links.
• Invite redemption mismatch — an invite forwarded to a different address can be redeemed by the wrong person unless RequireAcceptingAccountMatchInvitedAccount is on.
• Blocked-domain surprises — an AllowList with a missing partner domain silently blocks legitimate sharing.

What to watch (proofs)

• The full chain: Get-SPOTenant | fl SharingCapability, OneDriveSharingCapability, RequireAcceptingAccountMatchInvitedAccount plus the Entra external-collaboration settings — the layered stance in one view.
• B2B integration on: Get-SPOTenant | fl EnableAzureADB2BIntegration — are guests governed through Entra B2B (reviews/CA apply) or the legacy path?
• Guest inventory and age: the guest users in Entra + their last sign-in — the sprawl and the access-review candidates.
• Per-share reality: a site's external users (Get-SPOExternalUser / Get-SPOUser) and its SharingCapability — who's actually external and whether the site should allow it.