Exchange Online Starts Blocking EWS on October 1, 2026: How to Check Your Exposure and Buy Time With EwsAllowedAppIDs

October 1, 2026 is when Microsoft starts disabling Exchange Web Services access by default across Exchange Online tenants. If your organization has any application, integration, or third-party product that still talks to mailboxes through EWS rather than Microsoft Graph, and you have not already configured an allow list, that integration can stop working with very little warning once the flip happens. Full removal of EWS from Exchange Online, with no exceptions and no further extensions, follows on April 1, 2027.

What actually changes on October 1

Exchange Online has a tenant property called EWSEnabled. Once the retirement takes effect, tenants that have not explicitly configured an application allow list will have EWS requests blocked by default. This is not the final retirement, it is the start of the phased shutdown, and it is where most organizations that have not prepared will find out they had something depending on EWS that nobody remembered was there. The genuinely final cutoff, with EWS access removed entirely and no override available, is April 1, 2027. The six months in between exist specifically so organizations can either migrate off EWS or buy themselves time through an explicit allow list.

This retirement is scoped to Exchange Online in Microsoft 365. On-premises Exchange Server installations are not affected by this specific change.

Finding out what in your environment still uses EWS

Before touching any configuration, identify what is actually calling EWS against your tenant. Common culprits are older line-of-business applications, on-premises backup and archiving products, some CRM and calendar integration tools, and custom scripts written against the EWS Managed API before Microsoft Graph reached feature parity. If you run a mail security or archiving product from a third-party vendor, check that vendor’s own documentation specifically, several major vendors have already published their own guidance and required application IDs for exactly this transition.

Buying time with the EWS allow list

If you have applications that cannot be migrated to Microsoft Graph before October 1, you can configure a tenant-wide allow list of Microsoft Entra application client IDs permitted to continue using EWS during the extension window. This is done in Exchange Online PowerShell:

Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,11111111-2222-3333-4444-555555555555"

Two behaviors here are easy to get wrong. First, when EwsEnabled is set to $true, only the application IDs explicitly listed in EwsAllowedAppIDs are permitted to use EWS, everything else is blocked, this is an allow list, not a general re-enable switch. Second, the EwsAllowedAppIDs parameter overwrites the entire list every time you set it, there is no incremental add or remove. To add a new application ID later, you need to read the current list, append the new ID to it, and write the full combined list back, or you will silently drop every application ID that was previously allowed.

Treat the allow list as exactly what Microsoft has described it as: a temporary extension to April 1, 2027, not a permanent solution. Every application on that list still needs a real migration plan.

Migrating to Microsoft Graph

Microsoft Graph API now has near-complete feature parity with EWS for the overwhelming majority of mailbox access scenarios, mail, calendar, contacts, and folder operations that a typical integration needs. For custom-built applications, this generally means replacing EWS Managed API calls with equivalent Microsoft Graph SDK calls and moving authentication to Microsoft Entra ID app registrations with the appropriate Graph API permissions (Mail.Read, Mail.ReadWrite, Calendars.ReadWrite, and so on, scoped to what the application actually needs). For commercial third-party products, check whether a newer version already supports Graph natively before building anything custom, many vendors have already shipped Graph-based versions specifically for this transition.

A practical order of operations

• Inventory every application, script, and third-party product with any mailbox integration in your environment, do not assume you already know the full list.
• For each one, check whether it already supports Microsoft Graph. If it does, plan the migration and test it in a non-production mailbox first.
• For anything that cannot migrate before October 1, get its application client ID and add it to your EwsAllowedAppIDs list now, well before the cutoff, not the week of.
• Track every application on the allow list against a real migration deadline before April 1, 2027, since that date has no override.

Frequently asked questions

Does this affect on-premises Exchange Server?
No. This retirement applies specifically to Exchange Web Services in Exchange Online (Microsoft 365). On-premises Exchange Server EWS is not part of this retirement timeline.

What happens if I do nothing before October 1, 2026?
If your tenant has not configured an EWS application allow list, EWS requests will be blocked by default once the phased disablement takes effect, which will break any application or integration still depending on EWS without warning at the moment it tries to connect.

Is there any way to keep using EWS past April 1, 2027?
Microsoft’s guidance describes the EWS allow list as a one-time extension running through April 1, 2027 with no renewal option. Every application relying on EWS needs an actual migration plan to Microsoft Graph, the allow list only buys time, it does not change the final outcome.