Microsoft is reminding Exchange Online administrators that a deadline tied to legacy Exchange Web Services (EWS) settings is approaching, and tenants that haven’t configured their environment could be caught out by automated changes.
According to reporting from Neowin, the risk is straightforward: if your tenant still relies on unconfigured legacy EWS settings, Microsoft may apply automated rollouts that disrupt existing integrations. The recommended fix is to populate the EWSAllowedAppIDs list and begin planning a migration to the Microsoft Graph API.
What’s changing with Exchange Online EWS?
Exchange Web Services has been Microsoft’s long-standing API for letting third-party applications and tools access mailbox data such as email, calendar, and contacts. It predates the Microsoft Graph API and relies on a SOAP-based protocol that has served enterprises for well over a decade.
Microsoft has spent years encouraging customers to move off EWS in favor of the Graph API, which offers a more modern, unified interface across Microsoft 365 services. This deadline is part of that broader push to retire older protocols and reduce the maintenance burden of legacy authentication paths.
For organizations that never audited their integrations, the situation can feel sudden. The practical reality is that Microsoft is nudging everyone toward a cleaner, more secure endpoint, and leaving legacy settings unconfigured is no longer a safe default.
The EWSAllowedAppIDs list explained
The EWSAllowedAppIDs setting is an organization-level configuration in Exchange Online. It lets administrators whitelist specific application IDs that are permitted to authenticate against EWS. Think of it as a controlled allowlist: any app you depend on for EWS-based access must be listed here, or it could be blocked when Microsoft applies its automated rollout.
If you’ve already identified every application and integration that relies on EWS and added their IDs to this list, your environment is likely in good shape. The danger zone is for tenants that never configured the setting in the first place and are still running legacy integrations without visibility.
From an administration standpoint, this is a proactive task rather than an emergency. The key is knowing which of your tools still talk to EWS before Microsoft’s automated changes take effect.
Why Microsoft wants you on the Graph API
The Microsoft Graph API is Microsoft’s recommended path forward. Unlike EWS, which is Exchange-specific, Graph provides a single endpoint for accessing data across Mail, Calendar, Teams, OneDrive, and other Microsoft 365 workloads. It also supports modern authentication and token-based access that aligns with today’s security expectations.
For applications still built on EWS, this means updating the code that connects to your mailbox. Most enterprise tools and connectors have already added Graph support, so in many cases the migration is a matter of repointing configuration rather than rebuilding software from scratch.
This is the strategic reason behind the deadline: Microsoft wants to consolidate traffic onto a single, supported interface and phase out the older protocol it can no longer maintain as efficiently.
What this means for you
For everyday Exchange Online admins, the practical takeaway is that this is a planning task, not a panic. If your organization runs any third-party email, backup, archiving, or calendar tool, you need to know whether it depends on EWS and, if so, ensure its app ID is on the allowlist.
The risk is greatest for tenants that haven’t reviewed their integrations recently. Automated rollouts can take effect without additional notice, so waiting until the deadline is the riskiest approach.
How to prepare before the deadline
Start by inventorying every application and service that connects to your mailboxes. For each one, determine whether it uses EWS and, if so, capture its application ID so it can be added to the EWSAllowedAppIDs list.
Then, prioritize migrating the most critical integrations to the Microsoft Graph API. This reduces your long-term dependency on the legacy protocol and aligns your environment with Microsoft’s direction.
If you’re unsure where to start, Microsoft’s documentation on EWS and Graph migration provides the technical steps, and your application vendors can confirm whether their current versions support Graph. The earlier you begin, the more time you have to test changes in a non-production environment before anything is affected.
Bottom line
The Exchange Online EWS deadline isn’t hypothetical — tenants with unconfigured legacy settings face automated rollouts. Populate the EWSAllowedAppIDs list, plan your Graph API migration, and you should be able to avoid service disruptions.
Source: Neowin
Over to you: Have you already audited your integrations for EWS, or are you planning to migrate straight to the Graph API?
