As reported by BleepingComputer, Microsoft will add .msix and .msixbundle attachments to Outlook's BlockedFileTypes list beginning in early November 2026, with general availability expected by mid-November. While this may read as a routine policy update, it reflects a meaningful shift in how Microsoft is progressively tightening default-deny posture across its most abused communication surfaces — and defenders should understand both the security rationale and the operational impact.

Key Takeaway: While this may read as a routine policy update, it reflects a meaningful shift in how Microsoft is progressively tightening default-deny posture across its most abused communication surfaces — and defenders should understand both the security rationale and the operational impact.

Why MSIX Became an Attractive Attack Vector

MSIX is Microsoft's modern packaging format, designed to replace MSI and App-V with a cleaner, containerized installation model. Its legitimacy is precisely what makes it useful to attackers: a signed-looking .msix file arriving via email doesn't immediately trigger suspicion the way an .exe or .bat might. Threat actors have increasingly leveraged MSIX packages — sometimes abusing the MSIX installer mechanism itself — to deliver loader malware, establish persistence, and bypass legacy attachment filters that hadn't yet caught up to the format.

The risk isn't theoretical. MSIX-based delivery has appeared in campaigns distributing info-stealers and initial-access payloads over the past year. Email remains the dominant initial-access method, and every filetype that can carry executable content but isn't on a blocklist represents a gap attackers will map and exploit.

Who Is Affected

Why MSIX Became an Attractive Attack Vector
Exchange Online tenants — the default OWA mailbox policy will be updated automatically; custom policies will also receive the block.
Organizations distributing software via email — if your internal app delivery or helpdesk workflows involve emailing .msix installers, those will be blocked.
ISVs and vendors using email as a software distribution channel for MSIX-packaged tools.
Defender for Office 365 customers — while Safe Attachments provides detonation, the default block removes the dependency on sandbox verdicts.

Most organizations don't email MSIX packages legitimately. But some do — and if that's you, a silent policy change in November could break an internal process.

Broader Pattern: Microsoft's Progressive Attachment Lockdown

This isn't an isolated move. Microsoft blocked .library-ms and .search-ms in June 2025, both of which had been weaponized in phishing and malware campaigns since at least 2022. In October 2025, Outlook stopped rendering inline SVG images for similar reasons. The trajectory is clear: Microsoft is systematically closing filetype vectors that attackers have proven they'll abuse, and doing so at the platform-default level rather than leaving it to per-tenant configuration.

This default-deny-by-platform approach is the right one. It shifts the burden from individual admins — who rarely audit attachment policies until after an incident — to Microsoft's security team, which can correlate telemetry across millions of tenants and act faster.

What You Should Do

Immediate Actions

  • Audit MSIX usage now. Search mail flow logs and endpoint telemetry for any .msix or .msixbundle files sent or received in the past 90 days. If you find legitimate business use, document it.
  • Prepare an allowlist exception if needed. Add the filetypes to the AllowedFileTypes property of the relevant OwaMailboxPolicy objects only if you have a documented business requirement. Use targeted policies scoped to specific groups rather than tenant-wide exceptions.
  • Communicate to helpdesk and app owners. If internal software distribution currently relies on emailed MSIX packages, move to an alternative channel — internal portal, Intune deployment, or network share — before the block takes effect.
  • Review your full BlockedFileTypes list. Use this as a prompt to audit your existing OWA mailbox policies. Many tenants have legacy custom policies that are less restrictive than the Microsoft default — a gap attackers exploit.
  • Update phishing simulation content. If your security awareness program includes MSIX-based payloads, ensure detection rules and user training reflect the new default block.

Detection Considerations

Even with the block in place, monitor for circumvention attempts: renamed extensions, archive containers (zip, 7z) wrapping MSIX files, and cloud-storage links delivering MSIX payloads. Email gateway rules should flag any MSIX content regardless of whether it's directly attachable — threat actors will pivot to link-based delivery once direct attachment is closed.

The bigger lesson for defenders: treat your attachment allowlist as an attack surface. Every filetype you permit is one an attacker can weaponize. Review it quarterly, not annually.