Exchange Online EWS Deprecation: Re-enable Works Until April 2027

November 2, 2026. Microsoft's deprecation of Exchange Web Services in Exchange Online began on 1 October 2026, tenant disablements had started by 21 October, and that day its Exchange Team published instructions for tenants whose "EWS application stopped working." The mechanics matter for any sales team whose CRM, calendar sync, mailbox-reading tool or legacy add-in still talks to Microsoft 365 through EWS. Since early October, setting EWSEnabled to True "will no longer be sufficient on its own": a tenant also needs an allow list, EWSAllowedAppIDs, naming the apps permitted to use the protocol. Tenants that never set EWSEnabled get a seven-day warning in Message Center, then Microsoft fills the allow list from 60 days of usage and sets EWSEnabled to False. A tenant admin can re-enable EWS today in the admin center or PowerShell, and the change takes "typically under 1 hour (but can be up to 4 hours)", but the re-enable "will stop working in April 2027", after which "EWS will not be an option that your client applications can use." Here is the timeline as Microsoft published it, the two re-enable routes, and the question to put to every vendor in your stack.

What changed on 1 October

The Exchange Team's post "EWS Deprecation Is Here", dated 1 October 2026 and updated through 26 October, opens with "the deprecation of EWS in Exchange Online starts today." The first change, from early October 2026: "setting EWSEnabled to True will no longer be sufficient on its own to keep EWS working in the tenant: an AppID allow list (EWSAllowedAppIDs) will be required to specify apps that you want to permit access to EWS."

The post then sets out what happens to each kind of tenant in Microsoft's worldwide multi-tenant cloud:

Sovereign cloud tenants are told to "stay tuned for more detailed timeline." The post's own update log shows how fast the ground moved: 2 October, timing variability; 15 October, the table above; 21 October, "EWS disablements have been started"; 26 October, the April 2027 note for tenants already set to True.

How to tell EWS was turned off for you

The 21 October post, "Exchange Online EWS application stopped working? Do this.", describes the symptoms: applications "might give you various errors when EWS is turned off, from repeatedly asking for username or password, to giving you a clear error that EWS protocol is not available." The confirmation is in Message Center. Search for a post titled "Action may be required: EWS will be disabled in your tenant in 7 days" or "EWS has been disabled in your tenant", which "will tell you when EWS was turned off in your tenant." Microsoft is explicit that "Microsoft support cannot perform these steps for you. Only the tenant administrator can follow these steps and re-enable EWS."

The two ways to switch it back on

1. Microsoft 365 admin center. Open the Baseline security mode page, find "Block access to Exchange Web Services," uncheck "Block your entire organization from using EWS" and apply, then check it again and apply. Microsoft's description of the result: with the Block setting selected, "the underlying setting on your tenant is now actually set to allow EWS (EWSEnabled = True) with a specific app(s) in the EWS allow list." The post points to the page's Scope Summary section for the apps that are excluded from the block.
2. Exchange Online PowerShell. Run Get-OrganizationConfig | Fl EWSEnabled; "EwsEnabled : False" confirms the problem. Then Set-OrganizationConfig -EWSEnabled $true. To see which apps Microsoft put on the list, run Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Fl EwsAllowedAppIDs, which returns "EWS applications that Microsoft has detected were in use within last 60 days in your tenant."

Timing from the posts: changes to EWSEnabled take "typically under 1 hour (but can be up to 4 hours)"; changes to the allow list "take 24 hours to take effect." A separate property, EWSAllowList, "does not need to be configured and/or changed (it is not related to EWS deprecation)."

The clock that matters: April 2027

Both posts say the re-enable is a bridge, not a fix. The 21 October post: "The steps above will work only temporarily (until April 2027). We are now in the first stage of EWS disablement, where customers are still able to re-enable EWS. Re-enabling EWS will stop working in April 2027. The long-term solution is to update your applications to the application versions that do not use EWS. You must contact your application vendor to get the updated application version, or if you created the application yourself, you must change the code to not use EWS anymore. EWS will not be an option that your client applications can use after April 2027."

Microsoft's own clients are on the same list. The 1 October post says Outlook for Windows users "should be on latest builds (August 2026 build 16.0.20430.20092 or higher)," that Outlook for Mac users should "switch to the new Outlook for Mac," that classic Outlook for Mac needs the "Microsoft Office" AppID in the allow list, and that Excel Power Query has its own retirement page while "PowerBI: we will provide an update soon."

What this means for a sales and outreach stack

1. Ask every mailbox-connected vendor one question: does your Microsoft 365 integration still use EWS, and if so, when does the version without it ship? Microsoft's own advice is to "contact your application vendor to get the updated application version." A no means nothing to do on this deadline; a yes means a vendor deadline of April 2027. In our experience CRM email sync, meeting schedulers and shared-inbox tools are the integrations to check first.
2. Check Message Center this week. If the disabled notice is there, EWS is off for every app until an admin re-enables it. Once re-enabled, only the apps Microsoft detected in the previous 60 days are on the allow list, so anything not used in that window has to be added, and allow-list changes take 24 hours.
3. Re-enable only to buy time, and write the date down. The admin center route keeps the block visible while allowing listed apps; the PowerShell route shows you the list. Either way, April 2027 is the end.
4. Do not confuse this with SMTP AUTH. EWS is the mailbox and calendar API. The retirement of Basic authentication for SMTP AUTH, which affects tools that send mail with a username and password, has its own separate date, covered in SMTP AUTH Basic authentication deprecation. The two changes hit different parts of a sending stack.

The posts say nothing about sending limits on Microsoft 365 mailboxes; those are in Microsoft 365 sending limits. If an outreach stack is being rebuilt anyway, our email infrastructure service sets up sending domains, authentication and mailboxes that do not depend on a retiring protocol, and email hosting cost compares what the mailbox layer costs by provider.