EWS retirement: the August deadline most tenants miss

Exchange Web Services has been on a retirement track for a long time, and most IT directors have filed it under "2027 problem." The Exchange Team's post Exchange Online EWS, Your Time is Almost Up — first published in February 2026 and updated on August 19, 2026 — changes that filing in one sentence. The retirement is executed tenant by tenant, through a property called EWSEnabled, and the window in which a tenant could opt itself out closed on August 31, 2026. What is left is the rollout, which begins October 1, 2026.

What the end-of-August window bought, and why it still matters

EWSEnabled has three states: True, False, and Null. Null is today's default, which means the overwhelming majority of tenants have never touched it and are sitting in the default. Microsoft's commitment is specific:

"if you proactively configure an Allow List and set EWSEnabled to True by the end of August 2026, your tenant will be excluded from the October 1 automatic change to EWSEnabled=False."

Read the two halves. It is not "set EWSEnabled to True." It is configure an Allow List and set the property. Doing one without the other is not the described action, and the exclusion is described as following from both. That two-part structure is the whole reason this post exists, and it did not stop mattering when the window closed: the date was the easy half, and the Allow List is still where people get it wrong.

Microsoft is also running "scream tests" — deliberate temporary shutoffs designed to surface dependencies nobody has documented. Setting EWSEnabled to True exempts your tenant from those as well, and that is not tied to the August window. If your change calendar is full and you are looking for a reason to move in early September 2026 rather than late, that is it: the scream tests do not wait for October 1.

What happens on October 1 if you do nothing

"Any tenant with EWSEnabled still set to Null on October 1, 2026, will see the value changed to False as the deployment rolls out. That will block EWS for all applications in the tenant at that time."

Two words carry the weight there. Rolls out means October 1 is the start of a deployment, not a single global instant — your tenant may flip that day or later, which is worse for planning, not better, because you cannot put a date in the change calendar. And all applications means the block is not selective. It is not "unsupported apps" or "legacy clients." Everything in the tenant that speaks EWS stops, at a moment you did not choose.

If your tenant missed August 31

If EWSEnabled is still untouched on your tenant, the window to document an exclusion from the October 1 automatic change is closed. Microsoft's Skype for Business hybrid guidance ties that exclusion to acting before the end of August 2026 — it does not describe a mechanism for opting out after that date, and this post is not going to imply one exists.

There is one concrete reason to act even this late, and it is the subject of the September section below: a list a tenant builds itself is not overwritten by the auto-population Microsoft runs in September 2026. Missing the August 31 window did not end the decision about what ends up on that list.

The real trap: two controls, almost the same name

Here is the part that will cause more outages than the deadline. There are two controls in this space whose names read as synonyms and which do entirely different things. Microsoft's own Greg Taylor said so in the discussion thread on August 18:

"The biggest source of confusion we're seeing is two similarly named controls that work at different layers."

The distinction, stated plainly:

Microsoft acknowledged the problem directly — "We're writing up another blog to try and explain this a bit more. It's not helped by the naming similarity." That future blog does not help an admin who has to configure this before the October 1, 2026 rollout.

We are deliberately not printing a command here. Get the property names right first — EWSEnabled and EWSAllowedAppIDs for this work — then have whoever holds the change window pull the current syntax from Microsoft's own post below. A near-miss on a cmdlet in this area is a mail outage, and there is no version of this that is worth guessing at.

September: Microsoft builds the list if you don't

In September 2026, Microsoft pre-populates the Allow List from each tenant's own observed usage for tenants that have not created one. A list you built yourself is not overwritten. On the surface that sounds like a safety net, and to a degree it is. It is still the worse outcome, for a reason that has nothing to do with Microsoft.

An auto-populated list is assembled from what was running. That includes applications nobody approved, a departed contractor's integration, an archiving tool from a project that ended, and a client someone configured on a personal machine. Microsoft cannot tell the difference between a business-critical integration and a forgotten one; it can only see traffic. Carry that list forward and you have quietly renewed a set of dependencies you never audited, and you have burned the one moment when the environment was forced to show you them.

Building the list yourself converts the same work into an inventory decision. You look at the usage report, you name every application ID on it, and anything you cannot name is a finding — probably the most valuable output of this whole exercise. That was the argument for building it before September 2026 rather than letting Microsoft build it for you — and September 2026 is the month Microsoft is doing exactly that, for any tenant that has not made its own.

The hybrid consequence: this is now an Exchange SE decision

For anyone running hybrid, there is a line in the post that reframes an upgrade you may have been treating as purely a lifecycle chore:

"only Exchange SE will support Graph for calls to Exchange Online, so hybrid customers will have to use Exchange SE to host on-premises mailboxes."

If you are hybrid on Exchange 2016 or 2019, you now have two independent clocks running on the same servers. One is the paid Extended Security Updates bridge, which was always a stopgap and whose second period ends in October 2026 — the subject of our post on what happens when the ESU bridge runs out. The other is this: the version you run on-premises determines whether hybrid calls into Exchange Online have a supported path at all once EWS is gone.

Those two arguments used to be made separately, to different audiences, and each one was individually deferrable. Together they are not. If Exchange Server SE was a 2027 line item on your roadmap, the EWS retirement is a reason to move it — and it is worth knowing what SE actually commits your team to before you land on it, which is why we wrote Exchange Server SE: what modern servicing commits you to. Landing on SE is not the finish line; staying current on it is the operating cost.

Free/Busy is in scope, and it is easy to miss

Under Message center post MC1446796, cross-tenant Free/Busy, MailTips and calendar sharing are in scope. The mechanism is that organization relationships, sharing policies and availability address spaces in Exchange Online are themselves EWS-based, and they must move to Cross-Tenant Access Policies.

This one rarely appears on an application inventory because nobody thinks of it as an application. It is a configuration someone made once — during an acquisition, a partner integration, a divestiture that left two tenants sharing calendars — and it has worked silently ever since. It will stop working silently too. If your organization shares availability with any external tenant, that relationship belongs on the Allow List alongside the application IDs.

Apple Mail: one application ID, two protocols

A specific and useful detail, because it will show up in almost every usage report. Apple Mail on macOS uses EWS. Apple Mail on iOS uses Exchange ActiveSync. Apple ships the same application ID for both.

The practical consequence, per Microsoft: an Apple application ID appearing in your EWS usage report means someone configured mail on a Mac, not on an iPhone. Your iOS fleet is not what put it there. And allow-listing it is explicitly a stopgap — it buys roughly six months. So treat a Mac population showing up here as a scheduling problem: you have bought time to move those users to a supported client, not an exemption.

Public folders and archive mailboxes are not on Graph yet

One honest gap worth knowing before you plan around Graph as the universal answer: public folder and archive mailbox migration is not yet supported on Graph. Microsoft's position is that work in these areas is ongoing.

That lands hardest on tenant-to-tenant work, where public folders and archives are frequently the long tail that determines the cutover date. If you have a merger, divestiture or consolidation on the calendar, the tooling assumption underneath your plan deserves a second look — see our tenant-to-tenant Microsoft 365 migration playbook for where those workloads usually sit in the sequence. This is not a reason to stop planning; it is a reason not to assume the Graph-based path covers every workload today.

April 1, 2027: when the controls themselves go away

Final shutdown is April 1, 2027, and the important detail is not the date — it is that administrator control over EWSEnabled is removed at that point. Microsoft's wording: "There will be no exceptions past April 2027."

So the allow list is not a destination. It is a bridge with a published end, and everything you allow-list between now and then still has to reach Graph, or reach a vendor release that has. The end-of-August action buys you control over the timing; it does not buy you a different outcome.

What to do between September 3 and October 1, 2026

1. Pull your tenant's EWS usage report and name every application ID on it. Anything you cannot name is the finding. Do this first — every subsequent decision depends on it, and it is the step that gets skipped when the deadline is close.
2. Check the current value of EWSEnabled. If it is Null, you are in the automatic path. That is the default, so assume Null until you have confirmed otherwise.
3. Confirm which control you are about to configure. EWSAllowedAppIDs is the new tenant-level, application-ID control this retirement is about. EWSAllowList and EWSBlockList are the older user-agent controls tied to EwsApplicationAccessPolicy and they affect EWS and REST. Say out loud which one you are touching before you touch it.
4. Build the Allow List yourself rather than inheriting September's. Same list, entirely different meaning: yours is a decision, the auto-populated one is a carry-forward of whatever happened to be running.
5. Set EWSEnabled to True and complete the Allow List. The window to document an exclusion from the October 1 change closed August 31, 2026, and Microsoft's Skype for Business hybrid guidance does not describe a way to reopen it. Doing both is still what determines which applications keep working once your tenant's rollout lands, and it is also the only way to avoid the empty-Allow-List trap above.
6. Inventory your cross-tenant sharing separately. Organization relationships, sharing policies and availability address spaces will not appear on an application list. Plan their move to Cross-Tenant Access Policies.
7. Flag Apple application IDs as a six-month clock, not a fix. Find the Macs, plan the client change.
8. If you are hybrid on Exchange 2016 or 2019, put Exchange SE back on the roadmap with a date. Two clocks, same servers, and the second one no longer has slack in it.
9. Give every allow-listed application an owner and a Graph migration date before April 2027. The allow list expires; the dependency does not go away on its own.

Related reading

• What running Exchange Server SE actually commits your team to: Exchange Server SE: what modern servicing commits you to.
• Why the paid ESU bridge for 2016/2019 is a stopgap and not a destination: Exchange "ESU" expired April 2026 — what now.
• Where public folders and archives sit in a cross-tenant cutover: the tenant-to-tenant Microsoft 365 migration playbook.
• The migration window for getting onto SE while side-by-side coexistence still works: Exchange Server SE: the CU2 coexistence deadline.
• Service detail: Exchange hybrid decommission.

Source

• Microsoft Exchange Team Blog — "Exchange Online EWS, Your Time is Almost Up" (published February 5, 2026; updated August 19, 2026, version 13.0). Every quotation and date in this post comes from that page and its discussion thread. It is the only source we cite here, because it is the only place several of these facts appear — the end-of-August exclusion is not on the Microsoft Learn deprecation page.

The 30-second version

The window to configure an Allow List and set EWSEnabled to True and be excluded from the October 1, 2026 automatic change to EWSEnabled=False closed August 31, 2026. A tenant that missed it has no documented way to reopen that exclusion, per Microsoft's Skype for Business hybrid guidance — but EWSEnabled and the Allow List are still open to configure, and doing so still determines which applications keep working once the tenant's rollout lands. The change blocks EWS for all applications in the tenant, not a subset. This is Exchange Online only; there are no changes to EWS in Exchange Server. The trap is not the date: EWSAllowedAppIDs (new, tenant-level, application IDs) and EWSAllowList (older, user-agent, tied to EwsApplicationAccessPolicy, affects EWS and REST) are named almost identically, and at least one admin already configured the wrong one and broke Apple Mail. A second trap sits next to it: setting EWSEnabled to True without populating EWSAllowedAppIDs blocks every application not on that list starting October 2026 — the same outcome as doing nothing. September 2026 is the month Microsoft auto-populates the Allow List for any tenant that has not built its own; that auto-populated list is a worse version of the list a tenant would build itself, and a self-built list still is not overwritten even when made in September. Free/Busy and cross-tenant calendar sharing are in scope and must move to Cross-Tenant Access Policies. Public folder and archive migration is not on Graph yet. Hybrid customers need Exchange SE for Graph calls into Exchange Online, which puts a second clock on the same servers as the expiring ESU bridge. Admin control ends April 1, 2027 — no exceptions.

If you want a senior engineer to inventory your EWS dependencies and configure the right control before your tenant's October 1, 2026 rollout lands, the project intake form takes about three minutes. Two-business-day response with scope and a fixed-fee range.

Pro IT NW does senior-led Microsoft project work — Exchange hybrid decommission, tenant-to-tenant migration, and Microsoft 365 modernization. Vendor-neutral, labor-only, based in Seattle and delivered USA-wide. We don't resell Microsoft 365 licensing, so the recommendation is about your environment rather than our margin.