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 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.