How to setup external guests and allow them access to SharePoint

Collaborating with external partners, vendors, and clients is a everyday necessity for modern organizations, but setting up secure external access in Microsoft 365 can often feel like navigating a maze of hidden settings. Because external sharing controls span across multiple admin centers—from Microsoft Entra ID and M365 Groups to the SharePoint Admin Center—it’s easy to misconfigure permissions or accidentally block guests from viewing what they need.

This guide cuts through the confusion to help you successfully configure external guest access so outside users can safely log into and collaborate on your SharePoint sites.

Key Highlights of This Guide:

• Multi-Layered Configuration: Learn how to configure sharing boundaries correctly at the tenant level down to individual sites.

• Admin Center Navigation: Step-by-step guidance covering Microsoft Entra ID, Microsoft 365 Groups, and the SharePoint Admin Center.

• Security & Governance: Balance ease of collaboration with enterprise safety by understanding permission inheritance, guest types, and link restrictions.

• Troubleshooting Access: Prevent common pitfalls, like guests getting stuck in a "Pending Acceptance" state or failing to pass authentication.

When setting up external collaboration, one of the first design decisions is choosing the right container: SharePoint Sites vs. Microsoft Teams.

For external guest sharing, we intentionally standardise on dedicated SharePoint sites rather than Microsoft Teams. This decision is driven by two major user-experience and support friction points:

Desktop App Installation Overhead: Collaborating via Microsoft Teams often prompts external users to download, install, or switch accounts within the Teams desktop client. For external users in strict corporate environments, installing desktop software is often blocked by their local IT policy.

Tenant-Switching Confusion: Navigating multi-tenant environments in Teams remains notoriously clunky. External users frequently fail to switch to the hosting tenant properly, resulting in false "Access Denied" errors and a surge in internal IT helpdesk tickets.

By deploying standalone SharePoint sites, external guests interact entirely through standard web browsers, drastically reducing login friction while maintaining seamless file collaboration.

Architectural Strategy: SharePoint Sites vs. Microsoft Teams

Default Microsoft 365 sharing settings are often too permissive for enterprise security standards. To mitigate organizational risk, we implement strict configuration boundaries across Entra ID and SharePoint Admin Centers:

Tenant-Level Sharing Controls

SharePoint sites enabled for external sharing are strictly capped at the "New and Existing Guests" level rather than "Anyone".

This deliberate separation ensures that site owners cannot arbitrarily invite unvetted external email addresses directly from a SharePoint site interface. Guests must first exist in the organization’s Microsoft Entra ID (Azure AD) directory before they can be assigned permissions to any site.

Naming Conventions for Visual Auditing

Because native SharePoint site lists do not offer immediate visual tags or custom flags for external sharing status in standard views, governance becomes difficult without running custom PowerShell scripts or automated compliance reports.

To solve this, we enforce a strict naming convention: Every externally shared site must use the prefix EXT - in its Site Title.

E.g. "EXT - Project Blackstone"

This simple prefix allows administrators to rapidly search, group, review, and initiate lifecycle deletions for externally accessible sites directly from the SharePoint Admin Center.

Tenant & Site Configuration: Mitigating Risk by Default

To maintain complete visibility over who enters our tenant and why, guest invitations are fully automated via a custom ServiceNow request form and ticket workflow.

Instead of ad-hoc sharing, internal staff submit a request containing:

1. Target guest email addresses and full names.

2. A formal business justification.

3. Specific permission levels, including whether the guest requires file download capabilities (download permissions are restricted by default and allocated via specific Entra security groups).
   
   

Why Automation Wins

• Provisioning Dedicated Sites: The workflow automatically provisions a fresh, isolated SharePoint site for the engagement. This strictly separates live external work from internal documentation and legacy files.

• Identity Vetting: Our Entra domain does not rely on domain blacklists, as malicious actors can easily register arbitrary custom domains. Instead, all submitted guest identities and external domains are passed to our Identity and Security teams, who vet them using automated background tools like World-Check before access is granted.

• Metrics & Trend Analysis: Running invitations through ServiceNow allows IT leadership to track external collaboration trends, identify high-volume departments, and maintain an immutable audit trail for compliance frameworks.

Provisioning & Vetting: The ServiceNow Ticket Workflow

Microsoft’s gradual deprecation and updates surrounding One-Time Passcode (OTP) authentication have created persistent access issues for legacy guests added via ad-hoc document sharing.

Common symptoms include guests getting stuck in infinite login loops, receiving continuous access errors, or failing identity redemption checks despite entering correct passcodes.

The Reliable Fix

When a guest suffers from broken OTP state or redemption failures, attempting to re-share the document or resend the SharePoint invite rarely works.

The standard operational fix is:

1. Hard-delete the broken guest object from Microsoft Entra ID (ensuring it is removed from deleted users).

2. Re-trigger the guest invitation fresh through the standard ServiceNow onboarding workflow.

This forces Entra ID to create a clean B2B user object and forces the guest through a fresh redemption flow, resolving underlying token state conflicts.

Resolving OTP (One-Time Passcode) Account Breakage

Guest access should never be granted indefinitely. Left unmanaged, stale guest accounts become significant attack vectors. We execute automated quarterly guest purges based on two strict operational metrics:

Rule A: Unaccepted Invitations (> 30 Days)

• Policy: Any guest account that remains in a "Pending Acceptance" status for more than 30 days is automatically purged.

• Rationale: Data shows that legitimate business partners accept their guest invitations within 1 to 24 hours of receiving the email. If an invitation remains pending after a month, the access is no longer required, or the email was invalid.

Rule B: Stale / Inactive Accounts (> 6 Months)

• Policy: Any guest account that has not logged into the tenant for 6 consecutive months is flagged and deleted.

• Rationale: Inactive accounts represent lingering security debt. If an external vendor or partner requires access again at a later date, our ServiceNow workflow makes re-granting access fast and frictionless—making account retention unnecessary.

Lifecycle Management: Executing Quarterly Guest Purges

• Container Strategy: Standalone SharePoint Sites (prevents Teams app & tenant-switching friction)

• Tenant Sharing Level: "Existing Guests Only" (prevents unvetted ad-hoc sharing)

• Site Naming Standard: Forced prefix EXT - [Site Name] for easy reporting and deletion

• Identity Vetting: ServiceNow workflow + Security team screening (e.g., World-Check)

• Download Control: Blocked by default; toggled via ServiceNow and Entra Permission Groups

• OTP Fix Method: Delete Entra ID B2B guest object and re-provision cleanly

• Stale Guest Clean-up: Purge after 30 days pending or 6 months inactivity

Summary Architecture Checklist

Q1: What is the difference between tenant-level and site-level sharing settings?

A: Tenant-level settings act as a strict ceiling for your entire organization—meaning you cannot allow a specific SharePoint site to be more open than what is permitted globally. Site-level settings let you restrict access further (e.g., locking down a sensitive financial site to "Existing Guests Only" or "No External Sharing") while keeping broader permissions open elsewhere.

Q2: Why can my external guest see the SharePoint site link, but they can't access the content inside?

A: This usually happens when the Microsoft 365 Group settings governing the site are misconfigured. If the checkbox allowing group members to give external people access to group content is turned off, the guest may exist in your directory, but they will be blocked from viewing files or folders inside the backend SharePoint site.

Q3: Do external guests need a paid Microsoft 365 license to access SharePoint?

A: No. External guest accounts are managed via Microsoft Entra B2B collaboration and do not require a paid Microsoft 365 license. They authenticate using their own work/school email or a secure one-time passcode (OTP), and billing is based on Azure AD external user authentication tiers if applicable.

Q4: What is the difference between "New and Existing Guests" and "Anyone" link sharing?

A: New and Existing Guests requires the external user to sign in or verify their identity, tracking them as a guest object in your directory. Anyone creates an unauthenticated, anonymous link that anyone can open and forward without signing in, which poses a higher security and data leakage risk.

Q5: How can I audit or review which external guests currently have access to our SharePoint sites?

A: You can review external users by pulling the External User Report under Site Analytics in the SharePoint admin center, checking the member list in Microsoft Teams (where external users are marked with "(Guest)"), or reviewing unified audit logs through the Microsoft Purview compliance portal.

Frequently Asked Questions (FAQ)

Contact: info@m365-simplified.com