External access and guest access in Microsoft Teams

Outside collaboration in Microsoft Teams is a confusingly named topic because the terms overlap. There are actually four distinct mechanisms, and choosing the right one matters for both security and user experience.

1. Guest access

A guest is someone you add as a full member of one of your teams using their existing email address. They get a guest identity in your Entra ID directory and can chat in channels, access files, and join meetings — almost like a regular member, but with restricted permissions and visibility into your tenant.

Use guest access for deep, long-term collaboration with someone outside your organisation (a consultant embedded in a project for a year, for example).

2. External access (federation)

External access is one-to-one chat and calling with people in other Microsoft 365 tenants — and, optionally, with Skype consumer users. It's federation between tenants. The other party stays in their own tenant entirely; you just exchange messages and calls. No file sharing, no team membership.

Use external access for direct messaging with counterparts at other companies.

3. Shared channels (Teams Connect)

A shared channel lets you invite people from other Microsoft 365 tenants into a specific channel, without making them members of the team or guests in your tenant. They keep their home identity; your tenant publishes the channel via Entra ID Cross-Tenant Access Settings.

Use shared channels for ongoing cross-organisation collaboration that doesn't justify guest accounts. This is the most modern option and the one Microsoft is investing in.

4. Anonymous join

In a meeting, you can let people join anonymously without any identity at all — they enter a name and join the lobby. Useful for one-off meetings with people who don't have Teams.

How to choose

| Need | Mechanism | | --- | --- | | Long-term embedded contractor | Guest | | Direct chat/call with another tenant | External access | | Ongoing cross-tenant project channel | Shared channel | | One-off external meeting attendee | Anonymous join |

Admin controls

All four are toggled separately. In the Teams admin center, External access controls federation; Guest access toggles allow guests at all. Shared channels are governed by Cross-Tenant Access Settings in the Entra admin center. Anonymous join is a meeting policy. A common mistake is to ask "is Teams open to outside people?" without distinguishing which of these four is meant.

A worked example: partner working with two client tenants

A consultancy runs shared channels to two client tenants and guest access to a third. The design that stops confusion after week two:

• Client A and B (long engagements, weekly cadence) — shared channels in each client's tenant, the consultants added via B2B direct connect. Consultants sign in with their own identity; the channel content lives in the client's tenant with the client's retention and DLP. No profile switch, no guest account.
• Client C (short-term, IT project) — guest access in Client C's tenant. Consultants get a guest account and switch profiles in Teams to work there. Cheaper to set up, more friction daily.
• Cross-tenant access settings on the consultancy's tenant — Direct Connect inbound: allow, MFA required. Guest access outbound: allow (users can be added as guests elsewhere). B2B collaboration inbound: allow with the client tenants' IDs on the trusted list.
• CA policies — session-frequency of 8 hours for guests; require compliant device where the consultants access highly-sensitive client sites.
• Guest lifecycle — quarterly access review on the guest account population; anything not touched for 90 days gets removed automatically.

Decision matrix: shared channels, guest access, or federation

| Situation | Reach for | | --- | --- | | Long-lived collaboration with people at one other tenant | Shared channels (B2B direct connect) | | Occasional cross-tenant meeting attendance | External access (federation) — no account needed | | Deep integration with a single partner over months/years | Shared channels on both sides, cross-tenant access settings tuned | | A vendor needs to work inside your team for two weeks | Guest access (B2B collaboration) with time-bound access review | | A single-tenant contractor sitting inside the tenant for months | Full member account, not guest | | Multiple tenants that are all "you" (multi-tenant org, acquired brands) | Multi-tenant organisation (MTO) feature — inbound sync + shared channels by default |

When these features are the wrong tool

• You need document control not chat control. Shared channels use a SharePoint site in the tenant that owns the channel. If the content belongs to the other side, put the channel there instead — you cannot flip the ownership later.
• You want two-way calendar visibility. External-access chat and calling doesn't share free/busy. That's cross-tenant calendar sharing, a separate capability.
• You need per-file classification the partner honours. Guests inherit your labels within your tenant. In a shared channel the labels live in the owning tenant — the partner can't apply their own on top.
• You want one identity to work everywhere. That's cross-tenant synchronization provisioning members across tenants, not guest access. Guests will always be second-class citizens with permission ceilings you can't lift.

MSP checklist

• Default posture per tier. SMB client = guest access on, external access on, shared channels off. Mid-market = shared channels on with trust lists. Regulated = shared channels only, guest access off.
• Trust list, not open-world. Configure cross-tenant access settings with the specific partner tenant IDs — never leave "allow all tenants" enabled at the inbound layer.
• Quarterly guest review scheduled per client tenant, results archived. Guests dormant for 90 days = removed with a documented policy.
• Naming convention for guest accounts (ext-firstname.lastname@client.com or the raw external UPN) so the tenant Global Address List makes provenance obvious.
• Cross-tenant sign-in reports as part of monthly service review. Unexpected inbound patterns (new partner tenant, new user from a partner) surface before they become a support ticket.