Until recently, external users could remain in a Teams group chat even if your external access policy no longer allowed it. Microsoft closes that gap with two new PowerShell settings. What they do, when they are available, and how to configure them.
Teams has become the daily communication platform for many organisations. Collaborating with external parties, suppliers, customers, or partners via federation has become normal. You invite someone from another company into a Teams chat or meeting, and the collaboration feels as if you are colleagues.
But that openness has always had a downside. IT teams configure an external access policy: which domains are allowed, which are not. What was missing until recently was a mechanism that enforced that policy after a group chat had already been created. Someone could add you to a group chat that also included participants from a non-permitted domain, and those participants remained visible, even after a policy change.
The problem lies in how group chats with external participants work. When a chat is created, Teams checks at that moment whether the participants are allowed. But then the check stops. If you later tighten your policy, or if an external participant is added via a third tenant with which your policy does not permit direct federation, those participants could remain.
This is not a theoretical scenario. In practice, IT teams regularly see external addresses in chat logs that are not actually permitted under their policy. The external access policy in Teams Admin was the boundary at chat creation, not during maintenance. That gap is now being closed.
Microsoft introduces two new settings in the Set-CsTenantFederationConfiguration cmdlet via message centre post MC1423114. Both are disabled by default, so existing behaviour does not change immediately. IT administrators consciously choose whether and when to activate them.
The first setting is EnableExternalAccessRestrictionsForChatParticipants. The second is EnableMutualFederationForChatParticipants. They work independently but complement each other. Together, they give IT teams genuine ongoing control over who is allowed to stay in a federated group chat for the first time.
This setting is available from 31 July 2026. When you enable it, Teams continuously checks whether external participants in your group chats still comply with your external access policy. If they no longer do, for example because you have blocked a domain or tightened policy, those users are automatically removed from the relevant chats.
This works in both directions. If your own policy changes and an external domain is no longer permitted, participants from that domain are removed from your group chats. The reverse also applies: if the external organisation changes its policy and no longer allows your domain, their users leave your shared chats as well.
For organisations with a strict external access policy, this is a welcome addition. Previously, you had to manually track who was in which chat and actively remove participants after a policy change. That is now automated.
The second setting is available from 30 September 2026. It addresses a specific scenario: a group chat with multiple external participants from different organisations. The problem it solves is that participant A and participant B may both be permitted to communicate with your organisation, but not directly with each other. Via your chat they could still communicate, creating a workaround of their own policy.
When EnableMutualFederationForChatParticipants is enabled, Teams checks whether all participants in a group chat can mutually federate with each other. If participant A and B cannot communicate directly, one or both are automatically removed from the shared chat.
This is particularly relevant for organisations operating in sectors with strict compliance requirements, such as healthcare, education, or finance, and for organisations working with competing suppliers or customers who should not communicate via the same chat.
Both settings are configured via the Teams PowerShell module. Make sure you have the most recent version of the module installed, as the parameters are new. The command is: Set-CsTenantFederationConfiguration -EnableExternalAccessRestrictionsForChatParticipants $true for the first setting, and Set-CsTenantFederationConfiguration -EnableMutualFederationForChatParticipants $true for the second.
Use Get-CsTenantFederationConfiguration to check the current status. Both settings default to $false. Do not enable them simultaneously if you want to assess the impact. Start with the first setting and monitor for two weeks which users are removed from which chats. That gives a picture of the scope before you enable the second setting.
Bear in mind that automatically removing participants has an immediate effect on ongoing collaboration. If someone is in the middle of a project and is removed from the project chat because a policy change has taken place, that person notices immediately. Communicate to those involved before enabling the settings.
The choice depends on how strict your current external access policy is and how actively you use federated collaboration. Three scenarios.
Do you have a strict policy where you only work with a limited list of trusted domains? Then both settings are immediately valuable. They ensure that policy changes immediately flow through to all existing chats without manual cleanup.
Do you work with many external partners and are your chats broadly open? Then caution is warranted. Test first in a pilot environment or via a limited user group. Inventory how many existing chats contain external participants who may no longer comply with the strict mutual federation policy. A large unexpected removal wave damages trust in the platform.
Do you manage an environment where external access is deliberately open, such as a government organisation working with many different partners? Then these controls are less urgent, but it is wise to map out now what the effect of enabling them would be, so you can make an informed decision.
Three concrete actions. First, review your current external access policy. Are any domains blocked? Are there partners with whom you collaborate intensively via group chats? Do you know how your policy would look if EnableExternalAccessRestrictionsForChatParticipants were active?
Second, run Get-CsTenantFederationConfiguration and record the current values. This tells you exactly what changes when you enable the new settings and gives you a baseline to fall back on.
Third, plan a communication moment towards your users before activating the settings. A short notice that Teams will automatically remove external participants who no longer comply with policy prevents confusion and unnecessary support requests.
Want help assessing your current Teams federation policy, testing the new settings in your environment, or drafting communication to users? Zarioh supports organisations with Microsoft 365 governance and Teams administration. Contact us for a no-obligation conversation.
Zarioh Digital Solutions
IT specialists from Utrecht, the Netherlands. We help businesses with Microsoft 365, AI agents, hosting and telephony — and share what we learn in practice. Follow us on LinkedIn
Microsoft 365
Microsoft 365
Microsoft 365
