EWS Deprecation in Exchange Online: Allow Lists, Tenant Phases and the Final Shutdown

On 1 October 2026 the Exchange team published a post that opens: “The deprecation of EWS in Exchange Online starts today.”

Starts is the important word. Exchange Web Services (EWS) was not switched off on 1 October. Microsoft is retiring it in stages. Under Microsoft’s published schedule, the first stage, an application allow list requirement in the worldwide cloud, applies from 10 October. A tenant-by-tenant change to a default setting follows, with seven days’ notice to each tenant selected. The end point is fixed: from 1 April 2027, EWS in Exchange Online is “fully and permanently disabled”, and Microsoft says “There will be no exceptions past April 2027.”

This article sets out exactly how the EWS deprecation in Exchange Online works, from Microsoft’s own posts and documentation, for two audiences:

• Tenant administrators, who need to know what each setting does, what Microsoft will change on their behalf, and how to keep essential applications working while they finish migrating.
• Software vendors (ISVs) whose Outlook add-ins, back-end services or integrations still call EWS. Your application’s continued access now depends on a setting in each customer’s tenant that you do not control.

All sources were checked on 9 October 2026 and are listed at the end. Microsoft has updated these posts several times since February, so check the sources again before you act.

The Settings That Control EWS

Two settings decide whether EWS calls reach a mailbox in Exchange Online.

EWSEnabled exists at the organisation level (Set-OrganizationConfig) and at the mailbox level (Set-CASMailbox). It can be True, False or Null. Microsoft’s documentation states that “The default value Null is treated as EwsEnabled set to True”, and that “EWS will only be allowed if both the organization-level and user-level EWSEnabled flags are true.”

EWSAllowedAppIDs is the new allow list, set with Set-OrganizationConfig. Microsoft describes it as “a tenant-level list of application (client) IDs”. The cmdlet reference adds: “You identify each application by its Azure AD application ID (GUID).” It “applies only to direct EWS (SOAP) connections. It doesn’t affect requests from the Microsoft Graph API or the REST endpoint.”

One possible confusion is worth clearing up early. An older property, EWSAllowList, controls access by client user agent. Microsoft’s 1 October post is explicit that the “EWSAllowList property does not need to be configured and/or changed (it is not related to EWS deprecation).”

The Phases, as Microsoft Has Published Them

Three points in this table are easy to miss.

The phases are for the worldwide (WW) multi-tenant cloud first. Microsoft states: “This behavior change will take place in the WW cloud first. Tenants in other clouds will see comms and timelines specific to them via Message Center in due course.” If you administer a tenant in another cloud, watch Message Center for your own dates and do not plan against the table above.

The second phase has no single date. Tenants are selected as the rollout proceeds, and each gets a 7-day warning in Message Center when selected. An administrator who misses that post has less than a week to react.

EWS in Exchange Server itself is not changing. The February announcement states that “there are no changes to EWS in Exchange Server.” But Microsoft has identified two scenarios that “do impact our on-premises Exchange customers”: hybrid organisations whose on-premises mailboxes have online archives, and on-premises organisations with an organisation relationship to an Exchange Online tenant. Microsoft’s advice in both is for the Exchange Online tenant to keep EWSEnabled set to True and, in the hybrid case, to add its dedicated Exchange hybrid application to EWSAllowedAppIDs.

What an Empty Allow List Means

Under Microsoft’s published schedule, from 10 October, in the worldwide cloud, EWSEnabled = True is no longer enough on its own. Microsoft’s June post introducing the allow list is blunt: “after enforcement begins, setting EWSEnabled=True without an AppID allow list effectively becomes a block-all configuration.”

The February post confirms the empty-list case: “If the list exists, but has no entries, no EWS will be allowed.” In both cases, Microsoft notes that cross-tenant organisation relationship traffic is still allowed.

Microsoft’s Set-OrganizationConfig reference still says that setting EwsAllowedAppIDs to $null removes the application ID restriction. Microsoft’s June post shows that this was the behaviour before October 2026. Under enforcement, EWSEnabled = True with an empty or null list blocks all EWS traffic.

A Practical Runbook for Tenant Administrators

1. Find out what is calling EWS

Microsoft provides an EWS usage report in the Microsoft 365 admin center (Reports > Usage > Exchange > EWS usage). It “displays the SOAP actions used by each application calling EWS in your organization”. Its Application ID column is “The Microsoft Entra identifier for the registered application”, which is exactly the value the allow list needs.

Two cautions:

• “Usage data is collected and aggregated weekly, not daily. It can take up to 10 days for usage to show in the report.” An application that called EWS yesterday may not appear yet.
• Microsoft’s field guidance notes that tenants outside the worldwide cloud “should rely heavily on the script as admin center reports are not available”, referring to its Exchange app usage reporting script.

If an Application ID in the report is unfamiliar, Microsoft suggests you “check your Enterprise Applications in Microsoft Entra ID.”

2. Check your current settings

# Organisation and mailbox-level switches
Get-OrganizationConfig | fl EWSEnabled
Get-CASMailbox user@contoso.com | fl EWSEnabled

# The allow list (the switch is required)
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Microsoft notes that “The use of “RetrieveEwsOperationAccessPolicy” is required for performance reasons”. Without it, the allow list will not be returned.

If your tenant was on Microsoft’s 2 October list, the published schedule says Microsoft would create your allow list on 8–9 October from 60 days of usage. Read it back and review it rather than assuming it is complete.

3. Maintain the allow list without wiping it

This is the operational trap. Setting the property “writes the full list value. If the property already contains App IDs, they will be replaced unless included in the new command… Today, this cmdlet does not support incremental add or remove operations.”

Always read, append and write back the whole list:

# Set the complete list — every app that should keep EWS access
Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,11111111-2222-3333-4444-555555555555"

The cmdlet reference describes that pattern as one that “restricts EWS access to the two specified Entra applications only.” Keep the authoritative list in source control or a change record, so that the next administrator does not overwrite it from memory.

4. Allow for propagation

Microsoft states that “Changes to EWSAllowedAppIDs take 24 hours to take effect”, and that “Changes to EWSEnabled take typically under 1 hour (but can be up to 4 hours)”. If an application breaks after a change, a fix made to the allow list will not show for up to a day. Make allow-list changes early, never as an emergency response on the morning a process is due to run.

5. Do not forget Microsoft’s own applications

Microsoft notes that its own applications, “if they show up in the EWS usage report”, “still need to be added to the EWSAllowedAppIDs list to keep working”. For Outlook for Windows, it advises that “Customers should be on latest builds (August 2026 build 16.0.20430.20092 or higher).”

6. Restrict EWS to the mailboxes that need it

Because both the organisation and mailbox flags must be true, you can narrow exposure while the allow list is in place. Microsoft’s guidance is to “ensure those are the only mailboxes with the mailbox specific property set to True, and ensure everyone else has it set to False, and then you can set the Org Wide setting to True.” For example, this lets a journaling or archiving service keep access to the mailboxes it serves without leaving EWS open across the whole tenant.

The ISV Angle: Your App ID Is Now on Your Customers’ Lists

This section is our analysis of what the published phases mean for software vendors.

If your product calls EWS, whether from an Outlook add-in’s back end, a synchronisation service, an archiving tool or a CRM connector, your access in each customer tenant now depends on that customer’s administrator. Under Microsoft’s published schedule, from 10 October, in any worldwide tenant where EWSEnabled is True, your application works only if its Entra application (client) ID is on that tenant’s allow list.

Tell your customers your application ID, now. For a multi-tenant Entra application, the application (client) ID is the identifier the usage report shows and the allow list expects. Publish it in a support article, with the exact Set-OrganizationConfig read-append-write pattern and a warning that the command replaces the whole list. An administrator who adds your ID by overwriting the list can lock out every other EWS application in the tenant, and you will get the support call.

Do not rely on Microsoft’s automatic population. Where Microsoft populates allow lists, its published schedule says it uses EWS application IDs seen in the previous 60 days. Our reading is that an integration that calls EWS less often than that, such as a quarterly export or an annual archive job, may not be captured. If your product has an infrequent EWS workload, contact your customers before it next runs.

Check whether your add-in can still get EWS tokens. Mailbox requirement set 1.16 added Ews.getTokenStatusAsync, a method “to check if Exchange Web Services (EWS) tokens are supported in an organization”. Its Removed status means “The mailbox is hosted in an Exchange Online environment where EWS tokens are turned off and are no longer supported.” Microsoft’s Outlook authentication documentation states that legacy Exchange Online user identity tokens and callback tokens “are no longer supported and turned off across all Microsoft 365 tenants.” An add-in that still depends on them needs to change, whatever the allow-list position.

Treat re-enablement as time, not a future. Until April 2027 an administrator can switch EWS back on for your application. After 1 April 2027, Microsoft says there will be “no exceptions”. Every month your customers spend on the allow list is a month in which your product depends on a setting that is going to be removed.

Where to Go Instead: Microsoft Graph and Nested App Authentication

The destination is Microsoft Graph, with modern authentication.

For Outlook add-ins, Microsoft’s authentication guidance is to use MSAL with nested app authentication (NAA). NAA lets an add-in “use the MSAL.js library… to enable single sign-on (SSO)”, through createNestablePublicClientApplication, and its broker group currently covers Word, Excel, PowerPoint, Outlook, and Teams (when Office is activated inside Teams). For back-end services that act without a user present, the equivalent is an Entra application with Graph application permissions, scoped as tightly as Exchange Online allows.

We have covered the migration itself in detail elsewhere, and those articles were updated in October 2026 to reflect the phased retirement described here:

• EWS to Microsoft Graph: A Migration Guide for Outlook Add-In Developers: API mapping, authentication and testing.
• The Final Sprint: Completing Your EWS to Microsoft Graph Migration as EWS Is Phased Out: a sprint plan for teams with work remaining.
• The EWS Cutover Runbook: Going Live on Microsoft Graph During the Phased EWS Retirement: feature flags, go/no-go gates and hypercare.
• Designing Outlook Add-Ins for the Microsoft Graph-Only Era: the target architecture.

For a real example of the destination, see our work with Workiro. We built an Outlook add-in alongside a server-side Microsoft Graph integration that lets users tag, import and sync email conversations from Outlook into the Workiro platform.

A Checklist for the Rest of the Retirement

Tenant administrators

1. Pull the EWS usage report and reconcile every Application ID against Entra enterprise applications.
2. Read back your allow list with -RetrieveEwsOperationAccessPolicy, especially if Microsoft created it for you.
3. Keep the list in a change-controlled record, and always write it back in full.
4. Allow 24 hours for allow-list changes to take effect.
5. Restrict EWS to the mailboxes that need it.
6. Watch Message Center for the 7-day notice if your tenant is still at Null.
7. Get a migration date from every vendor on your allow list that falls before 1 April 2027.

ISVs

1. Publish your Entra application ID, with safe allow-list instructions.
2. Identify customers whose EWS usage is infrequent, and contact them before the next run.
3. Detect token and EWS availability at run time, and fail with a clear message rather than a silent error.
4. Ship a Graph-based version before 1 April 2027 and set a date for removing EWS code paths.

How McKenna Consultants Can Help

McKenna Consultants is a UK Office add-in development consultancy. We build Outlook, Word, Excel and PowerPoint add-ins and the Microsoft Graph services behind them. We can audit your EWS usage, migrate add-ins and back-end services to Graph with nested app authentication, and help you write the customer-facing guidance your administrators need while the allow list is in force.

If you are an ISV with EWS still in your product, or an administrator with applications on your allow list and no migration dates, contact us or read more about our Microsoft Office add-in services.

Sources

All sources checked on 9 October 2026.

• Microsoft Tech Community, Exchange Team Blog — EWS deprecation is here – what this means to you (1 October 2026, updated 2 October 2026): “starts today”; the 2 October, 8–9 October and 10 October steps; the second phase with 7-day notice; propagation times; Microsoft’s own apps; EWSAllowList not related.
• Microsoft Tech Community, Exchange Team Blog — Exchange Online EWS, your time is almost up (5 February 2026, updated 9 September 2026): Null changed to False as the rollout proceeds; re-enabling until final deprecation; full and permanent disablement from 1 April 2027 with no exceptions; empty list blocks EWS; no change to Exchange Server.
• Microsoft Tech Community, Exchange Team Blog — Introducing EWSAllowedAppIDs: preparing for the final phase of EWS retirement (19 June 2026, updated 22 September 2026): reading and writing the list; full-list replacement; block-all without an allow list; behaviour of an empty or null list before and after October 2026.
• Microsoft Tech Community, Exchange Team Blog — Impact of Exchange Online EWS Deprecation on Hybrid Rich Coexistence and Cross-org Sharing (30 September 2026): the two scenarios that affect on-premises Exchange customers, and what to do in each.
• Microsoft Tech Community, Exchange Team Blog — The way to control EWS usage in Exchange Online is changing: organisation and mailbox flags must both be true; restricting EWS to selected mailboxes.
• Microsoft Tech Community, Exchange Team Blog — Notes from the field: testing EWSAllowedAppIDs safely: “a tenant-level list of application (client) IDs”.
• Microsoft Tech Community, Exchange Team Blog — Notes from the field: finding and remediating EWS app usage before retirement: reporting script for tenants outside the worldwide cloud.
• Microsoft Learn — Deprecation of EWS in Exchange Online: October 2026 start and April 2027 full disablement.
• Microsoft Learn — Control access to EWS in Exchange: Null treated as True; organisation and mailbox settings.
• Microsoft Learn — Set-OrganizationConfig: EwsAllowedAppIDs takes Azure AD (Entra) application IDs and applies only to direct EWS (SOAP) connections; $null removes the application ID restriction.
• Microsoft Learn — EWS usage report: location, columns and weekly aggregation.
• Microsoft Learn — Outlook requirement set 1.16: Ews.getTokenStatusAsync and the Removed token status.
• Microsoft Learn — Authentication options in Outlook add-ins: legacy Exchange Online tokens turned off; MSAL and nested app authentication recommended.
• Microsoft Learn — Enable nested app authentication in your add-in: createNestablePublicClientApplication; the broker group’s hosts.