Microsoft is rolling out the “Start Chat with Email Address” feature in February 2026.
On paper, this sounds harmless … a Teams user types in an email address, and communication begins. Technically, however, a significant architectural shift is taking place here, which directly attacks your identity governance if you’re not careful.
Learn more -> https://www.microsoft.com/en-IE/microsoft-365/roadmap?filters=&searchterms=513271
The problem is not the chat itself. The problem is the identity creation mechanism that runs in the background. If your user starts a chat with you partner@externe-firma.de , Microsoft will automatically create a B2B guest account in your Entra ID as soon as the other party accepts.
Here’s how this “ad-hoc” federation works technically, why it undermines your guest access policies, and how to take back control.
Architecture: Implicit vs. Explicit Guest Creation
Until now, the process for guest access has usually been explicit: a team owner invites someone to a team, or an admin creates the guest in the Entra ID. That was controllable.
With the new feature (Roadmap ID 513271), the trigger changes.
- Initiation: Your user enters an email address in the Teams chat that does not exist in the directory.
- Invitation: Teams sends an email invitation to the external partner.
- Provisioning: As soon as the external clicks, an Entra ID Guest User object is created in the background.
Why is this critical? Because the hurdle is lowering. There is no longer any need to “join the team”. A fleeting chat creates a permanent identity object in your tenant. These “Orphaned Guests” accumulate, potentially have access to other shared resources (depending on your Guest User Access Restrictions), and bloat your directory.
While the process respects your global Entra ID External Collaboration Settings (B2B guidelines), it democratizes guest creation to the level of a simple chat message.
Guest Access and External Access Comparison Table:
Summary in advance:
- Guest Access is like a visitor badge: the person comes to your house (your tenant), gets an account and can work on projects.
- External access is like a phone call: the person stays outside in their own house, but you can talk to each other (chat/calls).
| External Access (Federation) | ||
| Main purpose | collaboration (files, projects). | Communication (chat, calls). |
| Identity / Account | A guest account is created in your Azure AD (Entra ID) (B2B user). | No account in your system. The person is purely using his or her own identity. |
| Teams & Channels | :Yes. Can be a member of Teams and see/lead channel conversations. | No. No access to teams or channels. |
| Share files | : Yes. Access to files in Teams (SharePoint) and OneDrive possible. | No. File sending in chat is usually blocked. |
| Chat | Full functionality (gifs, emojis, file attachments, editing). | Restricted (plain text/emojis only; no files). |
| User experience | The guest has to change tenants in the Teams client (top right) to access. | The external stays in their own tenant and sees your chat there (“Native Experience”). |
| Apps & Tabs | Yes. Can (depending on the setting) use tabs and apps in the team. | No. No access to apps or tabs. |
| Search | You can find the guest in the directory (after they’ve been added). | You need to know the full email address to start the chat. |
| Group | chats Yes, can participate in group chats. | Yes, can participate in group chats (but cannot share files). |
| Security / Control | Subject to your policies (MFA, Conditional Access, expiration date possible). | Subject to the guidelines of the external’s own home organization. |
Control | Pull the brake
Although Microsoft has developed this feature primarily for SMB (Business Basic/Standard) customers, it is also enabled by default in enterprise tenants (“Enabled by Default”). To prevent an uncontrolled increase in guest identities (identity sprawl), proactive action is required.
Since Microsoft does not yet offer a graphical interface for this setting in the Teams admin center, the configuration is mandatory via PowerShell.
1. Checking the status quo
First, validate which messaging policies have enabled the feature
Get-CsTeamsMessagingPolicy | Format-Table Identity, UseB2BInvitesToAddExternalUsers2. Deactivation by Policy
To prevent “shadow guesting”, set the attribute UseB2BInvitesToAddExternalUsers to $false. This prevents a guest object from being generated from a chat request.
Set-CsTeamsMessagingPolicy -Identity "Global" -UseB2BInvitesToAddExternalUsers $falseNote: Replace “Global” with your specific policy names if you have differentiated roles (e.g. “Marketing allowed, Finance not”).
3. The alternative: Use external access (federation)
It’s important to understand the difference:
- Guest Access (B2B): The user is an object in your AD. (This is what happens with the new feature).
- External Access (Federation): The user stays in his AD, you just trust each other.
For pure chats without file exchange, External Access is architecturally cleaner, as there is no identity garbage in your tenant. Therefore, check your federation settings.
Conclusion: Comfort vs. hygiene
The “Chat with Email” feature is a classic example of the conflict between user experience and system hygiene. For the end user, the “annoyance factor” of first creating a team or asking IT for a guest account is eliminated.
From an architect’s point of view, however, you open another gateway for identities that you have to manage.
Recommendation: In strict enterprise environments, you should disable the feature globally (UseB2BInvitesToAddExternalUsers $false) and only allow it to specific “power user” groups that understand what a guest account implies. Identity Sprawl is tomorrow’s technical debt… Avoid them today.
Be the first to comment