Microsoft Starts Switching Off Exchange Web Services on October 1 — and the Opt-In Window Already Closed
Exchange Web Services has been dying since July 2018, when Microsoft announced it would receive no more feature updates. The end is now four weeks away. Per the Exchange Team's February 2026 post, starting October 1, 2026, Microsoft begins switching EWS off in Exchange Online, tenant by tenant, and on April 1, 2027, it is fully and permanently disabled — the tenant-level switch itself is removed. Microsoft's own summary of what happens to organizations that ask for more time: “There will be no exceptions past April 2027.”
This is not a product end of life in the usual sense. Nothing stops receiving patches; an API that thousands of line-of-business applications, backup tools, archiving products, CRM connectors and room-booking systems use to reach mailboxes stops answering. That makes it a harder deadline than most of the ones on this site, and it has had almost no coverage as a lifecycle event.
EWSEnabled to True by the end of August 2026. That window closed last week. Tenants that did not act are on the default path: EWS is blocked on or soon after October 1, and re-enabling it afterwards means a service interruption first.The dates, and where each one comes from
Two Microsoft pages describe this retirement, and they are not equally precise. The Learn deprecation page (last updated August 21, 2026) gives only months: “October 2026: EWS starts to be disabled globally for all organizations” and “April 2027: EWS is fully disabled.” The day-level dates come from the Exchange Team's Tech Community post of February 5, 2026 and the matching Message Center notice MC1227454 issued the same day.
| Date | What happens | Source |
|---|---|---|
| July 2018 | EWS deprecation announced: no further feature updates | Learn page timeline |
| September 2023 | Disablement date set: “on October 1, 2026, we will start blocking EWS requests from non-Microsoft apps” | Microsoft 365 Developer Blog |
| January 2024 | Midnight Blizzard incident involves EWS; Microsoft says it “elevated the urgency” and widened scope to its own applications | Learn page timeline |
| February 5, 2026 | Phased, admin-controllable plan published; day-level dates confirmed | Exchange Team post; MC1227454 |
| End of August 2026 | Deadline to opt out of the automatic October 1 change (Allow List + EWSEnabled True) — passed | Exchange Team post |
| September 2026 | Microsoft pre-populates an AppID Allow List for tenants that never created one, from their own usage | Exchange Team post |
| October 1, 2026 | Tenants still at the default (EWSEnabled Null) are flipped to False as the rollout reaches them; EWS blocked for every app in the tenant | Exchange Team post; MC1227454 |
| April 1, 2027 | EWS fully and permanently disabled; the EWSEnabled control is removed from tenant admins | Exchange Team post; MC1227454 |
The precision point is worth stating plainly, because it is the kind of thing that goes wrong in copy-paste coverage. If you cite the lifecycle page, the commitment is “October 2026” and “April 2027”. If you cite the Exchange Team, it is October 1 and April 1. Both are Microsoft. The team's phrasing is that the switch happens “on (or soon after) Oct 1, 2026” as the deployment rolls out, so a tenant may see it on the first or some days later — plan for the first.
How the switch actually works
Disablement is per tenant and driven by one organization-level property, EWSEnabled, which has three states. True keeps EWS on; from October, a True tenant with an AppID Allow List admits only the applications on that list. False blocks all EWS. Null, the default every tenant started with, currently means “allowed” and is the value Microsoft changes to False from October 1. The Allow List is a new property, EWSAllowedAppIDs, managed through Baseline Security Mode or Exchange Online PowerShell; where a tenant already had an EWSApplicationAccessPolicy, the new list takes precedence and an application must pass both checks.
Three details from Microsoft's FAQ decide what your October looks like:
- If you set True before Microsoft reaches your tenant, it honors it. The August deadline governed exclusion from the automated pass; a True value set at any time before the Null-to-False change hits your tenant is respected.
- If you get blocked and still need EWS, you can turn it back on — set True with an Allow List, or set Null again to re-enable without restrictions until April 2027. Both go through Exchange Online PowerShell, and Microsoft's own words are that “there will be a service interruption in this case.”
- Expect “scream tests”. Microsoft says it may briefly turn EWS off and on again before the final cutoff to surface hidden dependencies, and that tenants already set to True are not subject to them.
On-premises Exchange is not affected — but hybrid is
Microsoft is explicit that “there are no changes to EWS in Exchange Server.” An application talking to an on-premises mailbox keeps working. The complication is hybrid: on-premises mailboxes may keep using EWS, cloud mailboxes must move to Microsoft Graph, and per the Exchange Team only Exchange Server Subscription Edition supports Graph for calls into Exchange Online. That lands on top of the other Exchange date in this window: Exchange Server 2016 and 2019 extended security updates end November 1, 2026, so a hybrid estate still on 2019 has two reasons to be on Subscription Edition by the autumn, not one.
What still does not exist in Microsoft Graph
Microsoft's position is that Graph has “near-complete feature parity for the vast majority of EWS scenarios” and that most workloads can migrate now. Its own parity-gap roadmap on the Learn page, current as of August 21, 2026, lists what has not closed: import and export of public folders (with the note that CRUD APIs will not be available), import and export of Microsoft 365 Groups, event delta for recurring events, Sticky Notes CRUD, and user configuration and the administration APIs, both still in preview. Mailbox import and export is in preview except for Groups and public-folder mailboxes. One gap is permanent by design: creating a calendar event without inviting attendees “will not be supported in Microsoft Graph API.” If an application depends on one of those, the October date does not move for it — it goes on the Allow List and has until April.
What to do in the four weeks left
- Read the usage report before anyone guesses. The Microsoft 365 admin center has an EWS usage report; Microsoft also publishes scripts for a deeper inventory and a code analyzer for in-house applications. The Midnight Blizzard lesson is that the EWS callers you do not know about are the ones that matter.
- Decide the October posture now. Either set
EWSEnabledto True with an Allow List you wrote yourself, which keeps the named applications running until April 1, 2027 with no interruption, or accept the block and treat October 1 as a forced discovery exercise. Do not leave it at Null and hope; Null is the value that gets changed. - Check what Microsoft put on your list. Tenants that never created an Allow List get one populated in September from observed usage. Microsoft's own caveat is that it “might also include apps in there you weren't aware of.” Review it, prune it, and note that once an admin edits the list Microsoft will not touch it again.
- Treat vendors as the critical path. Backup, archiving, e-discovery, signature-management and CRM connectors are where EWS hides in products you do not own the code for. Ask each vendor for the Graph-based version and its release date, in writing.
- Put April 1, 2027 in the risk register as a hard stop. After it, the control is gone from tenant admins entirely. Nothing on this site has a cleaner “no extension exists” statement from a vendor than this one.
If the same estate is carrying the other autumn Microsoft dates — October 13 for Windows Server 2012 R2, Windows 10 ESU, Windows 11 24H2 and Office 2021, then November 1 for Exchange 2016 and 2019 — the Stack Scanner reads a pasted inventory against the full dataset in your browser.
Frequently Asked Questions
When is Exchange Web Services being turned off in Exchange Online?
Disablement starts October 1, 2026 and proceeds tenant by tenant; EWS is fully and permanently disabled on April 1, 2027. Microsoft's Learn page states the milestones as “October 2026” and “April 2027”; the day-level dates are from the Exchange Team's February 5, 2026 post and Message Center notice MC1227454.
Can we keep using EWS after October 1, 2026?
Yes, until April 1, 2027. Set the tenant's EWSEnabled property to True and maintain an AppID Allow List of the applications that still need it, or set it back to Null to re-enable EWS without restrictions. The deadline to be excluded from the automatic October change was the end of August 2026; after a tenant has been switched off, re-enabling involves a service interruption.
Does the EWS retirement affect on-premises Exchange Server?
No. Microsoft states there are no changes to EWS in Exchange Server. Hybrid deployments are affected on the cloud side: cloud mailboxes must move to Microsoft Graph, and only Exchange Server Subscription Edition supports Graph for calls to Exchange Online.
Is there an extension past April 2027?
No. Microsoft's FAQ answer to “we will not be ready by April 2027, how do we get an extension” is that there will be no exceptions past April 2027, and the EWSEnabled control is removed from tenant admins on April 1, 2027.
Where are the authoritative sources?
Microsoft's Learn page “Deprecation of Exchange Web Services in Exchange Online”, the Exchange Team's Tech Community post “Exchange Online EWS, Your Time is Almost Up” (February 5, 2026), Message Center notice MC1227454, and the September 2023 Microsoft 365 Developer Blog announcement. Every date in this article was checked against those pages on 2026-09-04.