The collaboration spectrum
External collaboration in Microsoft 365 isn't a single capability — it's a spectrum, with different mechanisms suited to different scenarios. Choosing the wrong mechanism is more expensive than restricting external collaboration entirely.
| Mechanism | What it is | Best for |
|---|---|---|
| Internal-only | External access disabled at the tenant or site level. | Sensitive content, regulated environments, sites with no external use case. |
| B2B guest invitation | External user gets a guest account in your Entra ID, shows up in your directory, can be assigned to sites and Teams. | Long-term collaboration with named external partners. Project teams with vendors. Contractor access. |
| Teams Connect (shared channels) | Shared channel between two organizations. External members keep their own identity and don't need a guest account. | Ongoing collaboration with another organization where their users access your content using their home identity. Lower friction than guest accounts. |
| Anonymous sharing links ('Anyone' links) | Public link, no sign-in required. Anyone with the link can access. | Low-sensitivity content shared with broad audiences. Public-facing materials. |
| Specific people sharing links | Recipient must sign in (work, school, or Microsoft account). Tracked per-user. | Targeted external sharing with named individuals. Lower friction than B2B for short-term cases. |
| File-level direct attachment | Email or attach a copy of the file. | Almost never recommended — content escapes governance immediately. |
Most organizations should default to internal-only at the tenant level, then enable external collaboration explicitly per site or per Team where the use case justifies it. This is the opposite of Microsoft's defaults, which favor flexibility — you're trading user friction for predictable governance.
Tenant-level decision: default external sharing posture
External sharing is configured at the tenant level, with the option to override per site. The tenant-level setting is the ceiling — sites can be more restrictive but never less.
| Tenant default | What it means | Posture |
|---|---|---|
| Only people in your organization | External sharing fully disabled. | Tightest. Forces deliberate exception process for external collaboration. |
| Existing guests | Only existing guests in your directory. New invitations require admin approval. | Tight. Reuse of approved guests; no broad invitation. |
| New and existing guests | Users can invite new guests; guests show up in the directory. | Balanced default for most organizations with regular external collaboration. |
| Anyone | Anonymous links allowed. Anyone with the link can access without sign-in. | Open. Best avoided unless the use case explicitly requires it (e.g., public templates). |
Default to 'New and existing guests' at the tenant level for most organizations with regular external collaboration. Restrict to 'Existing guests' or 'Only people in your organization' in highly regulated environments. Enable 'Anyone' links only for specific sites where the use case justifies it (public-facing templates, marketing assets) — and even then, gate them behind expiration policies.
Per-site sharing defaults
Site-level sharing settings can be tighter than the tenant default. Apply different defaults to different site types based on their purpose.
| Site type | Default sharing posture |
|---|---|
| Tenant root / home site | Internal-only. The home site is for the organization. |
| Department hub sites | Internal-only by default. Department-specific exceptions possible. |
| Operational sites (Team Site, no Group) | Internal-only by default. External sharing requires explicit enablement. |
| Project workspaces (Teams) | Configurable per Team. Project Teams with named external members get guest invitations; internal Teams stay internal. |
| Records & functional hubs | Internal-only. Records content does not leave the organization through the platform's sharing mechanism. |
| Communication sites for external audiences | Anonymous links allowed for designated content (e.g., public-facing policies, partner-facing materials). |
Workspace templates set sharing defaults during provisioning. A Project Team template can default to 'New and existing guests' with a 1-year expiration; a Records hub template can default to internal-only with sharing disabled. Site Owners can request changes through the Workflow Engine rather than reconfiguring sharing settings ad-hoc.
Guest user lifecycle
Guest accounts that aren't actively managed accumulate. A guest invited to a project in 2023 still has access in 2026 because nobody removed them. Three controls keep this manageable:
-
Invitation governance. Who can invite guests — anyone, only Site Owners, only Brokers, only IT. The default in M365 is 'anyone'; most governed organizations restrict this to Site Owners or higher.
-
Expiration policy. Guest access auto-expires after a defined period (often 90 days, 6 months, or 1 year, with renewal possible). Without expiration, guest accounts persist indefinitely.
-
Access review. Periodic review (often quarterly) where guest access is reviewed and renewed or removed. Microsoft Entra ID Access Reviews automates this.
-
Departure/cleanup. When a project ends, the Team is archived, and guest access is removed as part of the lifecycle. Without explicit cleanup, guests accumulate.
Guest sprawl is one of the most common governance debt patterns. By year three of a deployment, organizations routinely discover thousands of guest accounts with no remaining access need. Set expiration policies from day one — retroactive cleanup is much harder than preventing accumulation.
Sensitive content handling
External collaboration intersects with sensitivity. Content that's safe to share with one external partner may not be safe to share with another. Two controls beyond simple sharing settings:
-
Sensitivity labels with encryption. A label that encrypts the file with policy-driven access — even if the file is downloaded and shared further, only authorized identities can open it. (See Doc 2.6.)
-
Conditional Access policies for guests. Restrict what guests can do based on device, location, sign-in risk. Particularly useful when guest access reaches sensitive content.
-
DLP policies. Block sharing of content matching specific patterns (PII, financial data, classified content) regardless of who tries to share it.
Impact's Compliance module manages sensitivity-label policies and surfaces external-sharing exposure in Insights. The Workflow Engine can enforce conditional access via property-bag tags — sites tagged as 'sensitive' can have stricter conditional access applied automatically.
Discussion Questions
• What's our default tenant-wide external sharing posture? Is it the right default for our regulatory environment?
• Which site types should allow external sharing by default, and which should be internal-only?
• Who should be allowed to invite guests — anyone, Site Owners, Brokers, IT?
• What expiration policy applies to guest access — 90 days, 6 months, 1 year?
• Do we have an access review cadence for existing guests today?
• When do we use B2B guest accounts vs. Teams Connect (shared channels)?
• Are 'Anyone' links allowed at all in our environment, and for what content?
• How do sensitivity labels and DLP fit into our external sharing strategy?