Table of Contents
File Sharing in Federated Chat Creates Questions for Microsoft 365 Tenants
I’ve seen some commentary about message center notification MC1479514 since Microsoft first published it on 25 September 2026 (updated 29 September 2026). Most of what I’ve read has been an inch deep and a mile wide for a topic that deserves better treatment.
In a nutshell, from late October 2026, Teams will automatically allow file sharing in federated chat and set permissions on the shared files to ensure that external chat participants can access the files. Currently, users can paste links to files into federated chats. These steps make the sharing process easier.
Loosening file sharing in chat only affects one-to-one conversations with external people. It does not affect chats with guest accounts. Dropping the restriction means that users can add files to federated chats using the Attach file (paperclip) option (Figure 1) or by dragging and dropping files to the chat.
Eliminating friction in how people share information with each other doesn’t sound too bad, but the devil is often in the details of implementation and its effect on how tenants protect themselves against potential infection.
Imposing Unwanted Change on Tenants
The biggest issue in the original proposal was Microsoft’s intention to override existing controls in tenants that previously disabled the capability. In the original text of MC1479514, Microsoft bluntly said: “This change applies even if your organization previously configured this Teams setting as Disabled.”
I can never understand why Microsoft thinks that they have the right to force behavioral change on their customers, especially when the change has consequences for the security profile of a tenant. If a tenant decides to disable file sharing in federated chat, presumably they do so for a good reason (like not wanting people to share files with external users). Microsoft program managers shouldn’t decide that they know better than customers because they often lack the context behind a tenant’s security decisions. Apart from anything else, a change like this introduces configuration drift in a tenant that might not be noticed by tenant administrators.
Fortunately, common sense prevailed. Microsoft noted the adverse commentary and changed its plans so that the change now only impacts tenants who have not previously blocked file sharing for federated chat (update to MC1479514 , 1 October 2026).
Sharing is Caring (But Not Too Much)
My assumption is that the argument advanced by the Teams developers is that they wish to encourage richer collaboration between Teams tenants by allowing people to share files. It’s safe to do so because existing OneDrive for Business, SharePoint Online, and security controls “continue to govern access.” For instance, a file protected by a sensitivity label can only be accessed by those granted rights by the label. In addition, if external sharing is restricted by a tenant, it’s entirely possible that external users will be unable to access shared files.
It’s true that Teams respects external sharing restrictions imposed by the tenant that hosts the shared file. The problem is that those restrictions are defined by the sender’s tenant, not yours. That tenant might not be one who you care to work with because they have looser controls than apply within your tenant.
For example, let’s assume that your tenant does not impose an allow list for external collaboration (the default), meaning that any user from any other Teams tenant can conduct a federated chat with a user in your tenant. Let’s assume that an attacker reaches out and makes a connection and uses social engineering to win the trust of a target user in your tenant. They then share an infected file to further compromise the target account.
Infection via Sharing Files via Email Happens Too
Proponents of open sharing in Teams argue that the same can happen when an attacker sends a target an email with an infected attachment. This is true, but the email infrastructure is generally better equipped to detect and suppress malicious content delivered through email simply because that infrastructure has grown and evolved over many years to deal with many forms of threat. All versions of Teams contain basic malware scanning for uploaded files. More extensive protection like Safe Links, Safe Attachments, and Zero-Hour Auto Protection (ZAP) for files uploaded to Teams is available through Microsoft Defender for Office 365 (MDO).
The thing here is that MDO scans files when they are in your tenant’s OneDrive for Business or SharePoint Online repositories. MDO can detect a problem if a user downloads a file uploaded by an external user to a federated chat, but only if they store the downloaded file in OneDrive or SharePoint. A separate malware scanner is needed to detect suspect files downloaded to local storage.
Depending on MDO to protect files uploaded to Teams federated chats creates a similar licensing issue to that which exists for shared mailboxes. Last year, Microsoft eventually concluded that only shared mailboxes exposed to external email needed MDO licenses in tenants where MDO Plan 2 is active. The licensing requirement arises because the shared mailboxes benefit from MDO protection applied to messages delivered to the mailboxes. MDO Plan 2 is automatically active in tenants with Office 365 or Microsoft 365 E5 licenses.
The same licensing principle applies when Teams users benefit from MDO capabilities such as Safe Attachments for files shared through Teams. Those users require at least MDO Plan 1 licenses. Not every Teams user has the required license, which is included in Office 365 E5 or Microsoft 365 E5.
Three Points to Consider about File Sharing in Federated Chat
Making file sharing with external friends friction-free is a compelling notion in a world where threat doesn’t exist. But threat exists, and Microsoft acknowledges that threat through initiatives like Secure Future and Secure by Default. Quite how the Teams developers reconcile this feature with the notion of Zero Trust is difficult to understand.
Three points arise. First, do you want to allow file sharing in federated chat? I think not, and I recommend that you run this PowerShell command to disable file sharing for federated chat in all file policies defined within the tenant:
Connect-MicrosoftTeams
$Policies = Get-CsTeamsFilesPolicy
ForEach ($Policy in $Policies) {
Set-CsTeamsFilesPolicy -Identity $Policy.Identity -FileSharingInChatsWithExternalUsers Disabled
}
The restriction removes the ability to attach files using the paperclip option or via drag and drop. It only applies when sharing files in federated chat. Users can still share files in chats with guest accounts.
Second, if you like the idea of file sharing in federated chat, do you want to allow every Teams tenant in the world to initiate federated chat with your tenant? Again, I think not. I recommend that you create an allow list of partner tenants permitted for federated chat with your tenant. Yes, it’s a pain to have yet another list to maintain, but it can be automated with PowerShell.
Third, if you allow file sharing in federated chat and depend on Microsoft Defender for Office 365 to protect against users uploading infected files to OneDrive or SharePoint, do you have the necessary licenses to benefit from MDO? That’s the point no one is discussing.
Microsoft 365 for IT Pros continues to earn 5-star reviews from readers—and for good reason. If you manage a Microsoft 365 tenant, you’ll benefit from practical, real-world guidance written by experts who work with the platform every day. The subscription includes extensive coverage of Microsoft 365 administration, security, compliance, and governance, plus a 450-page book dedicated to automating Microsoft 365 with PowerShell.