Microsoft is adding MSIX and MSIXBundle files to Outlook’s default list of blocked attachment types. From November 2026, users of Outlook on the web and the new Outlook for Windows will no longer be able to open or download these files by default. The move highlights a broader security principle: even legitimate software packaging formats can become a risk when delivered through email.

Microsoft is tightening controls around executable email attachments by adding .msix and .msixbundle files to the default blocked file types used in Outlook Web App mailbox policies. The change affects Outlook on the web, the new Outlook for Windows and Exchange Online environments. For most organisations, the practical impact is expected to be limited, as MSIX packages are relatively uncommon as email attachments. From a security perspective, however, the decision is significant. Microsoft is effectively restricting one of its own modern application packaging formats at one of the most frequently exploited entry points for cyberattacks: email. The rationale is straightforward. A software installation package can be entirely legitimate and still represent a potentially dangerous delivery mechanism when sent to users through an email message.

A modern package format with built-in security controls

Microsoft introduced MSIX as a modern packaging standard for Windows applications. It was designed to provide more controlled installation, updating and removal of software while combining features from earlier deployment technologies. MSIX includes a number of security-related mechanisms. Packages have a defined identity and use cryptographic integrity controls that allow Windows to determine whether their contents have been modified. Code signing also plays a central role in verifying the publisher associated with a package. The format can additionally make use of virtualisation and application-container technologies to limit how software interacts with the Windows environment. Those controls, however, do not make every MSIX package inherently safe. A valid digital signature primarily establishes who signed the package and whether it has been altered since signing. It does not guarantee that the application itself is benign. The level of isolation also depends on how a package is configured. Some applications distributed through MSIX can run with broader permissions and behave more like traditional desktop software. That distinction is critical. A secure packaging format reduces certain categories of risk, but it does not eliminate the possibility that users can be persuaded to install unwanted or malicious software.

Email remains a high-value delivery channel

From an email security perspective, the decisive question is not simply whether a file format incorporates security mechanisms. It is what can happen after a recipient opens it. Installation packages are fundamentally different from passive files such as images. Their purpose is to deploy software onto an endpoint. If an attacker convinces a user to trust and launch an unwanted package, the security properties of the format do not necessarily prevent abuse of the installation process itself. This is why Outlook has long taken a restrictive approach to executable attachments. Numerous file types capable of launching code or installing software are blocked by default. Legitimate software distribution is instead encouraged through more controlled channels, including enterprise deployment tools, application stores and managed file-sharing services. The addition of MSIX and MSIXBundle files follows the same principle. Where a file type has limited legitimate use as an email attachment but can install software, the convenience of direct delivery is increasingly outweighed by the associated attack surface.

The move does not undermine MSIX itself

Microsoft’s decision should not be interpreted as a rejection of the MSIX format. MSIX remains a supported Windows packaging technology and continues to be used for enterprise application deployment through platforms such as Microsoft Intune, the Microsoft Store and other managed distribution systems. What is being restricted is the delivery mechanism. The distinction is important. Microsoft is not saying that MSIX packages are inherently unsafe. It is saying that email is not an appropriate trust channel for software installation in many modern enterprise environments. This reflects a wider Zero Trust principle: an object should not be considered trustworthy simply because it has a recognised file format, a valid signature or a technically legitimate purpose. Origin, context, delivery path and permissions all matter. For enterprise security teams, that makes the change particularly relevant. Software should generally be distributed through controlled deployment channels rather than passed between users as email attachments.

Administrators can still create exceptions

Organisations that genuinely depend on MSIX or MSIXBundle files as email attachments will still be able to modify their policies. Exchange and Outlook on the web allow administrators to define which file types are blocked or explicitly permitted through OWA mailbox policies. This means businesses can create exceptions where there is a clear operational requirement. Such exceptions should, however, be treated carefully. Relaxing a default security control increases the attack surface and should therefore be justified by a specific business need rather than by convenience or legacy practice. For security teams, the policy change creates a useful question: does the organisation genuinely need to exchange installation packages by email, or is this simply an outdated workflow that should be replaced with managed software deployment?

Signed software is not automatically trusted software

The Outlook update also illustrates a broader lesson in software security. Digital signatures, package integrity and containerisation are valuable controls, but they solve different problems. A signature can verify publisher identity and detect post-signing modifications. Integrity mechanisms can identify tampering. Isolation can restrict access to parts of the operating system.

None of these mechanisms alone answers the most important question: should this particular application be installed in this particular environment? That is where control of the distribution channel becomes important. By blocking MSIX attachments, Microsoft is treating software received through email differently from software delivered through a managed enterprise process. That distinction reflects the continued importance of phishing and social engineering in cyberattacks An attacker does not necessarily need to bypass every technical control if a user can instead be persuaded to initiate the installation.

Software delivery becomes part of the security architecture

For organisations, the implications go beyond a single Outlook configuration change. Secure software delivery requires control over the entire chain of trust. Security teams need to know who supplied an application, through which channel it arrived, who is authorised to install it, which privileges it receives and whether its deployment can be centrally monitored. Email is poorly suited to many of those requirements. A managed deployment platform, by contrast, can provide approval workflows, inventory information, policy enforcement and central visibility. This is why the Outlook change is better understood as part of a wider shift in enterprise security rather than as a technical response to a particular file format. Microsoft is narrowing the number of situations in which users are expected to make their own trust decisions about executable content. That matters because many successful attacks still rely on exactly that moment: persuading a recipient that a file is legitimate enough to open. Blocking MSIX and MSIXBundle files at the email layer therefore closes less of a software vulnerability than a preventable delivery path. The wider message for enterprise security is clear: software installation and email communication should not depend on the same trust channel.