Microsoft has extended the list of blocked attachments in Outlook with two extensions that had so far flown under the radar: .msix and .msixbundle. Starting with the rollout planned for early to mid-November 2026, users of New Outlook for Windows and Outlook on the Web in Exchange Online will no longer be able to download or open attachments with these extensions by default. The reason is straightforward: a maliciously crafted .msix package, if installed without proper checks, can compromise a device.

The company acknowledges that these formats are "infrequently used," but also admits there are legitimate reasons to send them via email. For this reason, administrators can add the extensions to the AllowedFileTypes property of the relevant OwaMailboxPolicy before the rollout. Those managing Exchange Online environments must therefore decide whether to keep the block or create exceptions for specific senders or scenarios.

The change comes after Microsoft's application packaging system had come under scrutiny: in December 2023, Microsoft disabled the ms-appinstaller protocol handler by default, after it had been abused to distribute malware. The attachment block adds another layer of protection, unless administrators explicitly disable it. In addition to the new formats, Outlook on the Web already blocks .py Python files, .ps1 PowerShell files, and .cab files.

The most telling aspect is not the list itself, but the delay in adding .msix and .msixbundle. These formats have existed for years and represent a known infection vector. The delay suggests that enterprise application security defaults evolve more slowly than the threat landscape. For those managing self-hosted infrastructure, the structural message is clear: you cannot delegate all protection to vendors, because controls often arrive late. An attacker who compromises an administrator's workstation via a malicious attachment can then move laterally to servers hosting models, training data, or inference pipelines. In on-premise environments, where data sovereignty is a requirement, the attack surface includes corporate email as well.

There is also a second effect to consider: renaming an attachment's extension or sending a download link can bypass the restriction, but it does not make the package safe. Persuading someone to download and install an executable remains a viable route for attackers, even with additional Windows protections. The block reduces automatic risk, but does not eliminate the need to educate users and segment networks.

Microsoft's choice signals a broader direction: permissive defaults are giving way to settings that deny execution of unsolicited content. For organizations evaluating on-premise deployments, this is a piece of the overall security posture: the analytical frameworks available on /llm-onpremise help assess the trade-offs between control, TCO, and attack surface, but the decision remains tied to the specific context.

The open question is how long it will take for attackers to move to other equally dangerous but not yet blocked formats. In the meantime, blocking .msix and .msixbundle closes a known gap, albeit years late.