Microsoft is disabling Exchange Web Services (EWS) in Exchange Online in a phased rollout: from 10 October 2026 every worldwide tenant with EWS enabled must maintain an AppID allow list (EWSAllowedAppIDs) or its EWS apps are blocked, and EWS is fully disabled in April 2027. Developers must migrate to Microsoft Graph.

Microsoft is disabling Exchange Web Services (EWS) for Exchange Online — and the mechanics turned out to be more gradual than its original announcement implied. The 2023 blog said Microsoft would “start blocking EWS requests” on 1 October 2026, and we, like many, read that as a single hard cutover on that day. The current official process is a phased disablement that runs through April 2027, with worldwide enforcement of a new allow-list requirement beginning 10 October 2026.

Correction (2 October 2026). This entry originally gave 1 October 2026 as a hard block date and was marked passed on that day. Microsoft’s current primary sources describe a phased rollout, not a one-day block. We’ve corrected the date to 10 October 2026 (worldwide allow-list enforcement) and rewritten the entry below. A reader first flagged the discrepancy; we confirmed it against Microsoft’s own documentation before changing anything.

How the shutdown actually works

EWS is being turned off through an allow list, then a full disablement:

• Early October 2026 — Setting EWSEnabled = True on a tenant is no longer sufficient by itself. An AppID allow list, EWSAllowedAppIDs, must name every app permitted to call EWS; anything not listed is refused.
• 2 October 2026 (end of day, Pacific) — Microsoft recorded which worldwide tenants had EWS enabled with no allow list.
• 8–9 October 2026 (end of day, Pacific) — For those captured tenants, Microsoft auto-created an EWSAllowedAppIDs list seeded with the AppIDs seen in the previous 60 days.
• 10 October 2026 — Microsoft turns on the cloud setting enforcing the allow-list requirement for all tenants in the worldwide (WW) cloud. This is the date unlisted apps start being blocked.
• April 2027 — EWS is fully disabled.

The auto-populated list is a backstop, not a safety net: it only covers tenants captured on 2 October, and only apps that happened to run in the prior 60 days. Anything that runs monthly, quarterly, or on-demand can fall outside it.

Who this affects

Any app that talks to Exchange Online or Microsoft 365 mailboxes over EWS — directly, through the EWS Managed API, or via the EWS SDKs for .NET and Java. In practice that is a long tail: mailbox backup and archiving tools, tenant-to-tenant migration utilities, email-signature managers, calendar and CRM connectors, and in-house line-of-business scripts. After the January 2024 Midnight Blizzard security incident, Microsoft widened the scope from third-party apps to include its own products (Outlook, Office, Teams, Dynamics 365), which it is migrating off EWS in parallel.

The scope boundary is unchanged: this applies only to Microsoft 365 and Exchange Online. EWS on Exchange Server on-premises is not affected and stays supported. On-prem-only integrations do not need to move.

What to do

1. Immediate (admins): if your tenant still needs EWS past 10 October, confirm every app that uses it is in EWSAllowedAppIDs. Don’t rely on Microsoft’s auto-seeded list for infrequently-run apps.
2. Inventory every app, service, and script that calls EWS against Exchange Online. Microsoft’s EWS Usage Reports and EWS Analyzer (shipped 2025) surface the footprint.
3. Migrate to Microsoft Graph. Map each EWS operation to its Graph equivalent and permissions. Microsoft’s parity-gap roadmap targets most remaining gaps (archive import/export, user-configuration objects, contact lists, non-draft MIME, report-message) for Q3–Q4 CY2026, and lists capabilities that won’t come to Graph — generic Public Folder CRUD, generic Microsoft 365 Group mailbox CRUD, and Discovery Mailbox access — which need a different approach.
4. Don’t wait for every gap. EWS is fully disabled in April 2027; migrate and validate app-by-app between now and then.