LearnMicrosoft Teams › 3 · Messaging architecture

External access, federation and guests: three different doors

Chat with another company can flow through three unrelated mechanisms with different identities, records and risks. Most 'external access' confusion is people arguing about different doors.

The three doors

Federation (external access) Guest access Teams (consumer) chat
Who they are A user of THEIR tenant An object in YOUR Entra (#EXT#) Personal Microsoft account
What they reach Chat/calls with your users Teams you invited them into — files, channels 1:1/group chat only
Identity check by you None — trust their tenant Yours: CA, MFA-able, revocable Minimal
Records you hold Your side of chats only Full — they act inside your tenant Your side only
Risk shape Vishing/phish INTO your org Data access sprawl Uncontrolled counterpart
Controlled by TenantFederationConfiguration + ExternalAccessPolicy Entra B2B + Teams guest settings + labels CsTenantFederationConfiguration consumer switches

Federation is the phone system model: you can talk to anyone reachable, but they never enter your house. Default is open-to-all-M365-tenants; you can allowlist or blocklist domains. The modern threat rides this door: fake "IT support" chats and malicious meeting invites from throwaway tenants — which is why new controls keep landing here (external-sender identification, one-way federation limits, blocking trial tenants).

Guest access brings the person inside: a real directory object, subject to your Conditional Access, discoverable, revocable, but also able to open every file in every team they were ever added to — the door with the audit obligations.

Consumer chat exists so business users can reach personal accounts; most regulated orgs close it and lose nothing.

The layered-switch trap

A guest actually reaching a team requires FOUR layers to agree: Entra B2B settings → Teams org guest toggle → the team's sensitivity-label guest rule → the team's own membership. Federation similarly: org federation config AND the user's ExternalAccessPolicy. When "external chat doesn't work", walk the layers in order — the deepest one wins and the error message never names it.

What to watch (proofs)

  • The federation truth: Get-CsTenantFederationConfiguration | fl Allow*,Blocked* — open/allowlist/blocklist state, consumer toggles; this is scanned nightly by serv365, so drift here posts to your channel.
  • Per-user gating: Get-CsExternalAccessPolicy + the user's assignment — a user-level block explains "works for everyone but Dave".
  • Who's actually flowing in: audit log + Teams admin external access reports; guest inventory via Get-MgUser -Filter "userType eq 'Guest'" with last-sign-in — stale guests are your standing risk register.
  • An attempted fake-IT-support attack: external 1:1 chat requests from unknown domains in the audit trail — the signal to move federation from open to allowlist.

PowerShell for this concept

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.