External collaboration in Microsoft 365, explained

"Can external people access our stuff?" is the most common security question in Microsoft 365, and it has no single answer — because external collaboration isn't one feature. It's five overlapping mechanisms, configured in four different admin centres, each with its own idea of what "external" means. This guide is the map: what each mechanism actually is, how they stack on top of each other, and which one to reach for in each situation.

If you only take one thing away: most external collaboration in Microsoft 365 runs through Entra B2B guest accounts underneath, and the controls you see in Teams and SharePoint are mostly gates in front of that one machine. Understand the B2B layer and the rest falls into place.

The mechanisms each have a page: guest access in Teams, shared vs standard channels, restricting external sharing for a SharePoint site, Loop external sharing, cross-tenant calendar sharing, and — for organisations that own several tenants — Multi-Tenant Organizations.

The five mechanisms

Entra B2B guest accounts — the foundation. An external person is invited into your tenant and gets a guest object in your directory. They sign in with their own credentials (their work account, or a Microsoft/Google account), but they exist in your Entra ID, can be assigned to groups and teams, and are subject to your Conditional Access policies. Almost everything else builds on this. Deep dive: Entra ID B2B guest access.

Teams external access (federation) — 1:1 chat and calling with people in other Microsoft 365 tenants. No guest account, no shared workspace, no files — just a chat thread between two directories that trust each other. This is the one mechanism that does not create anything in your tenant.

Teams shared channels (Teams Connect) — a channel shared with people from another tenant who keep their own identity. No guest object in your directory; instead the trust is negotiated through Cross-Tenant Access Settings. The modern default for ongoing cross-organisation project work. Covered in Teams external collaboration patterns.

SharePoint and OneDrive sharing links — file- and folder-level sharing with outsiders. Depending on your settings, a link to an external email address either forces the recipient through B2B guest redemption (they become a guest) or — with "Anyone" links — grants access with no identity at all. The layered controls are in SharePoint external sharing.

Cross-tenant synchronization — the heavyweight option for multi-tenant organisations (mergers, conglomerates, split tenants). Users from a partner tenant are automatically provisioned as B2B guests in yours, at scale, without invitations. Covered in cross-tenant synchronization.

How they stack

The mechanisms aren't alternatives at the same level — they're layers:

| Layer | Mechanism | Creates identity in your tenant? | | --- | --- | --- | | Directory | Entra B2B guests | Yes — a guest object | | Directory, automated | Cross-tenant synchronization | Yes — guests, provisioned in bulk | | Trust configuration | Cross-Tenant Access Settings | No — governs the others | | Workspace | Teams guest membership | Uses the B2B guest | | Workspace | Teams shared channels | No — external identity stays home | | Messaging | Teams external access | No | | Content | SharePoint/OneDrive sharing | Yes for specific-people links, no for "Anyone" links |

Two consequences follow from this stacking.

First, turning off one gate doesn't close the others. Plenty of organisations proudly disable guest access in Teams and never notice that SharePoint "Anyone" links are wide open, or that external access still lets staff chat with any tenant on earth. If you're auditing exposure, you audit all five.

Second, Cross-Tenant Access Settings (CTAS) sit under everything tenant-to-tenant. B2B invitations, shared channels, and cross-tenant sync are all governed by the inbound and outbound trust rules you define in Entra. If cross-tenant collaboration behaves strangely — a partner can't join a shared channel, an invited guest can't redeem — CTAS is the first place to look. Design guidance: Cross-Tenant Access Settings design.

Which mechanism for which relationship

A contractor embedded in a project for months → B2B guest, added to the team. They need the full workspace: files, channels, meetings, Planner. Accept that they're an identity in your tenant and lifecycle them properly.

A partner company you run a joint project with, both on Microsoft 365 → shared channel. Nobody becomes a guest, everyone stays in their home tenant, and the channel gets its own isolated SharePoint site. This beats mass guest invitations for cross-org work — cleaner security, better user experience (no tenant switching).

Ad-hoc chat with a peer at another company → external access. It's on by default for all tenants; most organisations should narrow it to a block/allow list rather than leave it open to the world.

Sending one file to an external accountant → a SharePoint sharing link scoped to specific people. Not a guest invitation to a team, and not an "Anyone" link.

Two tenants in the same corporate group → cross-tenant synchronization plus B2B direct connect. Invitation-by-invitation guest management does not scale to a merger.

External users of your customer-facing app → none of the above. That's Entra External ID, not B2B collaboration — a separate product for customer identity.

Where the controls live

This is the operationally painful part — the settings are spread across four admin centres, and they interact:

• Entra admin centre: external collaboration settings (who may invite guests, guest permission levels), Cross-Tenant Access Settings, cross-tenant sync configuration, guest access reviews.
• Teams admin centre: external access (federation) allow/block lists, guest access toggle and capabilities, shared channel policies.
• SharePoint admin centre: the tenant-wide external sharing dial (Anyone → New and existing guests → Existing guests → Only your organisation), per-site overrides, link defaults and expiry. OneDrive's dial can be stricter than SharePoint's, never looser.
• Microsoft 365 admin centre: the Microsoft 365 Groups guest setting, which gates whether guests can be added to group-connected workspaces at all.

The precedence rule that trips everyone up: the most restrictive setting in the chain wins. A guest invited to a team still can't open its files if the underlying SharePoint site blocks external sharing; a shared channel fails silently if either tenant's CTAS doesn't trust the other. When external collaboration "doesn't work", walk the chain from Entra down to the site.

A sane default posture

Opinionated starting point for a typical organisation:

1. Leave B2B guest access on, but govern it — restrict who can invite, strip guest directory enumeration rights, and put quarterly access reviews on guest membership. Blocking guests outright just pushes collaboration to personal Dropbox accounts.
2. Narrow external access from "everyone" to the tenants you actually work with, once you know who they are.
3. Set SharePoint to "New and existing guests" tenant-wide — kill "Anyone" links by default and re-enable them per site only where the business case is real, with expiry.
4. Prefer shared channels over guest floods for tenant-to-tenant project work, and invest the setup effort in CTAS once.
5. Write the posture down — one page saying which mechanism your organisation uses for which relationship type. The tooling sprawl means nobody can infer the policy from the settings; the document is the policy.

External collaboration in Microsoft 365 is genuinely good now — better than emailing attachments ever was. The mess is not the mechanisms, it's that five of them shipped without a map. Now you have one.

When to use what — a decision matrix

Once the layers are understood, most everyday choices collapse into this table. If a row applies, that's the mechanism; keep the others on the shelf.

| Relationship | Duration | Right mechanism | Wrong mechanism (and why) | | --- | --- | --- | --- | | Auditor, external counsel, contractor embedded on your project | Months | B2B guest in the team + governed guest access | External access (no workspace); Anyone links (no CA, no audit trail). | | Two Microsoft 365 tenants doing a joint project (both admin-cooperative) | Months to a year | Shared channel with CTAS trust | B2B guests for a whole tenant (invitation sprawl); anonymous links (blows past both tenants' governance). | | Merger, acquisition, or corporate group of tenants | Ongoing | Cross-tenant sync + B2B direct connect + MTO | Per-user guest invitations (does not scale past ~500 users). | | One-off file share to a supplier | Hours to days | SharePoint "specific people" link with 14-day expiry | Anyone link (loses attribution, permanent unless you set expiry). | | One-off chat with a peer at another org | Minutes | Teams external access (federation) | B2B guest (no shared workspace needed). | | External-facing consumer / partner app | Ongoing | Entra External ID (not B2B) | B2B guest tenants (wrong product — no self-serve sign-up, no branding, no scale). | | A public consultation document open to comments | Weeks | Loop with anonymous access review | Team + guest invitations (overkill and slow). |

Two rules underneath the table: default to the least-privileged mechanism that meets the need, and never mix mechanisms for the same relationship — one project should not be half guest access and half Anyone-links, or nobody knows what to revoke at the end.

Common misconfigurations and the fix

The list I see most often on audits and health checks. Each one has a page under it, but this is the checklist:

| Symptom | Root cause | Fix | | --- | --- | --- | | Guests can open the team but not its files | SharePoint site's external sharing is set stricter than the tenant | Set the underlying site to "New and existing guests" or looser; the tenant dial is a ceiling, not the effective policy. | | Guest access reviews always come back "no changes" | Reviewers are the guests themselves | Reviewers should be the sponsoring internal owner; self-review defeats the point. | | Anyone-links proliferate despite the tenant being at "New and existing guests" | A handful of legacy sites still allow Anyone at the site level | Run Get-SPOSite -Filter for SharingCapability -eq "ExternalUserAndGuestSharing" and lock down the outliers. | | Shared channels fail silently between two tenants | CTAS trust not configured on both sides | Configure Cross-Tenant Access Settings on both tenants; shared channels require inbound and outbound trust plus B2B direct connect. | | Guests show up in every Teams people-picker | Guest directory enumeration is not restricted | In Entra external collaboration settings, restrict guest access to properties and memberships of their own directory objects. | | Contractor left months ago but their guest object is still active | No lifecycle process on guests | Turn on quarterly access reviews (Entra ID Governance) and set a guest-account inactivity policy to disable and delete stale guests. | | Anonymous Loop file surfaced in an external search index | Loop was set to "anyone with the link" and posted on a public site | Restrict Loop external sharing to "specific people" tenant-wide; treat Loop as SharePoint, not as a whiteboard. |

MSP / first-time-admin checklist

Scoping an external-collaboration engagement or a new-tenant baseline:

• Draft the one-page posture first. Which relationships (contractor, partner-tenant, supplier, customer-of-your-app) map to which mechanism (guest, shared channel, sharing link, external access, External ID). Everything below flows from this document; without it, the admin centre settings are opinion.
• Inventory current guests. Export the guest list (Get-MgUser -Filter "userType eq 'Guest'") with sign-in date. Anything older than 180 days without a sign-in is a candidate for cleanup; anything older than a year is a certain one.
• Audit the SharePoint tenant + site sharing settings. Tenant dial is the ceiling, site setting is what actually applies. A "safe" tenant setting with permissive sites is the audit finding waiting to happen.
• Confirm B2B direct connect and CTAS state. Even if shared channels are not in production, the settings are the trust boundary — leaving them at default lets any tenant on the internet initiate a trust request.
• Set expiring "Anyone" links by default (30 or 90 days). Retro-fitting expiry on live links breaks work; enabling for new links from today doesn't.
• Turn on guest access reviews. Quarterly on high-risk workspaces (finance, HR, executive), annually on the rest. Reviewer is the sponsoring internal owner, never the guest.
• Document the exception process. Every "please make this an Anyone-link because our supplier can't create a Microsoft account" gets a ticket and an expiry; don't let one-offs erode the posture.
• Retest quarterly. External collaboration settings drift as Microsoft ships new defaults and new products (Loop, Copilot Chat sharing, agents). A quarterly re-baseline is the only way to keep the posture honest.