Impactfold

Exchange Web Services retirement

EWS in Exchange Online is being switched off: in phases from 1 October 2026, completely on 1 April 2027.

A reference for service providers who manage Microsoft 365 tenants. Every statement links to Microsoft's own documentation, checked on 26 September 2026. Microsoft updates these pages often, so check the linked sources before acting.

  1. 2023

    Microsoft announces that EWS will be disabled in Exchange Online in October 2026.

  2. 5 Feb 2026

    Microsoft sets out a phased, admin-controllable disablement, tenant by tenant. Exchange Team blog, updated since.

  3. By 30 September 2026

    A tenant that has configured an AppID allow list and set EWSEnabled to True is excluded from the automatic change.

  4. From 1 October 2026

    Tenants still at the default setting have EWSEnabled changed to False as the rollout reaches them, which blocks EWS for every application in that tenant. Starts in 5 days.

  5. 1 April 2027

    EWS is fully and permanently disabled in Exchange Online. Administrators can no longer change EWSEnabled, and Microsoft says there will be no exceptions. In 187 days.

Countdowns were calculated when this page was built (26 September 2026) and update in your browser. The phased change reaches each tenant on its own date; Microsoft has not published a per-tenant schedule.

What is changing

Exchange Web Services (EWS) is the SOAP interface applications have used for two decades to read and write Exchange mailboxes: backup and archiving tools, CRM connectors, meeting-room panels, migration tools and line-of-business integrations. Microsoft is retiring it in Exchange Online and pointing applications to Microsoft Graph. Microsoft Learn: Deprecation of EWS in Exchange Online

There is no single cut-off moment before 1 April 2027. From 1 October 2026 Microsoft changes each tenant's tenant-wide EWSEnabled setting as its rollout reaches that tenant. What happens then depends on how the tenant is configured:

How EWSEnabled and EWSAllowedAppIDs decide EWS access from October 2026
EWSEnabled (tenant)AppID allow listFrom October 2026
Not set (the default)IgnoredAllowed until Microsoft changes the value to False during the rollout; then all EWS is blocked.
TrueLists application IDsOnly the listed applications can use EWS.
TrueEmpty or not setAll EWS is blocked, apart from cross-tenant organization relationship traffic.
FalseAnyAll EWS is blocked.

Summarised from Microsoft's Exchange Online EWS, Your Time is Almost Up and Introducing EWSAllowedAppIDs. Microsoft pre-populates an allow list, from each tenant's own usage, for tenants that have not created one. It does not change a list an administrator has already created. If EWS is blocked and still needed, an administrator can re-enable it until 1 April 2027, after a service interruption.

Who and what is in scope

Exchange Online
Every Microsoft 365 and Exchange Online environment.
Microsoft's own applications
Also in scope. Microsoft widened the retirement to its own applications and is removing their EWS dependencies. A Microsoft application that still calls EWS in a tenant appears in the usage report, and needs to be on the tenant's allow list if it is still needed. Microsoft names Office and Power Query for Excel as examples.
Exchange Server on-premises
Not affected: EWS is not being retired in Exchange Server. In hybrid deployments, mailboxes in Exchange Online must be reached through Graph; see Microsoft's guidance for rich coexistence.
Mail flow
SMTP delivery and Microsoft Graph access are not part of this change. Mail keeps arriving; an application that reads it over EWS stops working when EWS is blocked for it.

The controls, old and new

EWSEnabled
The retirement control. It exists at tenant level and on each mailbox, and since 2025 EWS is allowed only when both permit it. Read it with Get-OrganizationConfig | Format-List EwsEnabled and, per mailbox, Get-CASMailbox.
EWSAllowedAppIDs
The retirement allow list: the application IDs that may still use EWS when EWSEnabled is True. Read it with Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy. Setting it replaces the whole list, and changes can take up to 24 hours to apply.
EWS application access policy (legacy)
EwsApplicationAccessPolicy with EwsAllowList or EwsBlockList matches user-agent strings, not application IDs. Microsoft states it is not part of the retirement. It remains an additional gate: a request must pass the AppID allow list and then this policy.
RBAC for Applications
Exchange Online can grant an application EWS access through the Application EWS.AccessAsApp management role, independently of consent in Microsoft Entra. Those assignments do not appear as Entra consent. Microsoft Learn

Finding which applications actually use EWS

The EWS usage report lists, for each application that called EWS in the tenant, its application ID, the SOAP actions it used, the call volume and the last activity date. Find it in the Microsoft 365 admin center: Reports → Usage → Exchange → EWS usage. It covers the last 7, 30 or 90 days and can be exported. Microsoft Learn: EWS usage report

Allow for the delay. Microsoft collects and aggregates this data weekly, not daily, and it can take up to 10 days for usage to appear. An application that ran only in the last week, or that runs monthly or quarterly, may not be in it yet. Microsoft also sends monthly Message Center posts with tenant-specific EWS usage summaries.

Four things to establish, and what proves each

These are separate facts. Evidence for one does not prove another.

1. Consent observed
Microsoft Entra records that an application holds an EWS permission: the full_access_as_app application role or a delegated EWS scope on the Office 365 Exchange Online service principal. Proves the application can call EWS; says nothing about whether it does. Also check Exchange RBAC for Applications, which grants EWS access outside Entra consent.
2. Actual usage established
The EWS usage report shows the application ID calling EWS, or the application's owner confirms it. Remember the reporting delay: absence from a recent report is weak evidence.
3. Functional migration confirmed
The vendor's Graph-based version is installed and the customer has confirmed the functions they rely on still work, preferably before EWS is blocked for that application.
4. Consent removal verified
Once the application no longer needs EWS, the EWS permission is removed and a later, complete read of the tenant confirms it is gone. Directory changes can take time to replicate, so verify after the change has settled.

Testing before Microsoft does it for you

Setting EWSEnabled to True with an allow list, or blocking EWS, changes access for every EWS application in the tenant at once. It is not automatically safe, even for a short test, and changes to the allow list can take up to 24 hours to apply everywhere. Treat it as a customer change:

  • Assess impact first. Use the usage report and consent inventory to list every application that could lose access, and who depends on it.
  • Agree a window with the customer, with someone watching the affected applications.
  • Record the current values of EWSEnabled and EWSAllowedAppIDs before changing anything, so rollback restores exactly what was there.
  • Plan the rollback, and allow for the cache delay in both directions. After 1 April 2027, there is nothing to roll back to.

Microsoft has said it may run temporary "scream tests" that switch EWS off and back on. Tenants that have set EWSEnabled to True are not included.

Why service providers feel this more

Everything above is per tenant. For a provider, each step repeats for every customer, with different applications, different owners and different dates as Microsoft's rollout reaches each tenant. Finding the application is only half the job; showing the customer that the exposure is gone, and has not come back, is the other half.

Where Impactfold fits, and where it does not

Impactfold's EWS check covers facts 1 and 4 across the tenants you connect: which applications hold EWS consent in Microsoft Entra, and verification that consent is gone after it is removed. It does not see EWS usage, the tenant's EWSEnabled or allow list, or Exchange RBAC for Applications. Establishing usage and confirming migration remain with your team and the application's owner. The check's limits in full.

Sources

Working through this by hand? The checklist works without Impactfold.

Provider checklistRequest a pilot