Microsoft Exchange Online is set to retire its fallback support for the EWSEnabled=True setting, and administrators who haven’t explicitly whitelisted the application IDs they rely on could see third-party mail tools stop working overnight. The enforcement takes effect on October 10, per Microsoft’s service communication notice MC1485116.
In short, Microsoft is enforcing the EWSAllowedAppIDs requirement: from that date, only application IDs you’ve specifically added to the allowlist will be permitted to use Exchange Web Services (EWS). Traffic from anything else falls through.
What’s changing, and why it matters
EWS is one of Microsoft’s older programmatic interfaces, dating back to Exchange 2007. It lets third-party applications read and write mailbox data — email, calendar, and contacts — without routing through the newer Microsoft Graph API. Over the past several years, Microsoft has steadily pushed organizations away from EWS toward Graph and REST-based endpoints, largely because EWS predates the modern authentication and multi-factor enforcement that newer APIs enforce natively.
The EWSAllowedAppIDs setting is a tenant-level configuration that acts as a whitelist. Administrators use it to name exactly which application (client) IDs are allowed to reach mailboxes over EWS. Historically, a fallback value of EWSEnabled=True let EWS traffic through even when an app ID wasn’t on the list — a convenience many tenants leaned on.
The October 10 enforcement
With MC1485116, Microsoft is pulling that fallback. Starting October 10, the EWSEnabled=True safety net is gone, and the allowlist becomes the sole gatekeeper for EWS access. If a third-party app your organization depends on isn’t in the EWSAllowedAppIDs list, it can lose mailbox access with little or no advance warning.
The notice frames this as a risk of “sudden service outages” — meaning the break isn’t gradual or easily caught in testing. Apps that have worked for months can stop on the enforcement date if their app ID was never explicitly added.
What the EWSAllowedAppIDs requirement means for you
This change primarily affects organizations running third-party email, calendar, archiving, security, or collaboration tools that still talk to Exchange Online over EWS. If your team relies on such a tool, its application ID needs to be in the allowlist before October 10.
Personal and small-business tenants that use only Outlook, the Outlook web app, or Microsoft’s own tools are far less likely to be impacted, since those don’t depend on the EWS app-ID allowlist in the same way.
From an IT-pro standpoint, the practical move is to inventory every EWS-dependent app in your environment, confirm each one’s application ID, and add the ones you need to the allowlist. Leaving it to chance means betting that a vendor hasn’t changed its ID or that your app was already covered.
How to prepare before the deadline
According to Microsoft’s documentation, the allowlist is managed through Exchange Online PowerShell using the Set-OrganizationConfiguration cmdlet and its EWSAllowedAppIDs parameter. You’d supply the application IDs of the apps you want to keep working over EWS.
Before the deadline, work through these steps:
- Inventory your EWS apps: List every third-party tool that accesses mailboxes over EWS, and note each one’s application (client) ID from its Microsoft Entra ID app registration.
- Prioritize critical tools: Focus on archiving, security/antispam, backup, and collaboration integrations that would cause real disruption if they went dark.
- Plan a migration off EWS: For apps where a Graph-based path exists, consider moving them off EWS entirely so they no longer depend on this setting at all.
- Test before you commit: Validate that whitelisted apps keep working, and confirm with your vendor that the app ID you have matches what they’re actually using.
What this means for everyday users
For most people who simply check email in Outlook or on the web, nothing changes. This is a behind-the-scenes configuration that only matters if your organization runs tools that hook into your mailbox programmatically.
If you’re an administrator, though, treat October 10 as a hard deadline rather than a soft reminder. The safest path is to confirm your EWS app-ID allowlist now, and to phase dependent apps off EWS where a modern alternative exists — a move that also aligns with Microsoft’s longer-term push to retire older protocols in favor of Microsoft Graph.
Source: Neowin
Over to you: Has your organization already whitelisted the app IDs needed for third-party mail tools, or is October 10 still on your radar?
