EWS retirement: allow list required from October 10

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 most recently updated on September 9, 2026 — changes that filing in one sentence. Microsoft's wording is unambiguous that the scope stops at the cloud: "Today's announcement and the retirement of EWS apply only to Microsoft 365 and Exchange Online (all environments); there are no changes to EWS in Exchange Server." The retirement is executed tenant by tenant, through a property called EWSEnabled, and the window in which a tenant could opt itself out ran through the end of September 2026. Microsoft's October 1, 2026 post then set the next hard date: October 10, when an AppID allow list becomes required wherever EWSEnabled is True — see the update at the top of this post.

What the end-of-September window bought, and why the two-part rule 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, as the post reads after the September 9, 2026 update, is specific:

"if you proactively configure an AppID Allow List and set EWSEnabled to True by the end of September 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 AppID 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 will not stop mattering once the date passes: the date is 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 end-of-September date. If your change calendar is full and you are looking for a reason to move before that date rather than after, that is it: the scream tests do not wait for October 1.

What happens to a tenant that never touched EWSEnabled

Microsoft's October 1, 2026 post puts these tenants in a second phase, after the October 10 change: EWS is turned off for tenants "who did not modify EWSEnabled (so it is still Null) and did not create EWSAllowedAppIDs," and "tenants will get a 7-day warning in Message Center when they are selected." That Message Center notice is your only scheduled warning. Microsoft's February post, which this section originally quoted, described the same change as starting October 1:

"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 — the 7-day Message Center warning is the closest you will get. 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.

Blocked is not permanent by itself. Microsoft says that if, after the block, "you realize that you still need EWS, the admin can re-enable EWS (by setting EWSEnabled to True)" — but is explicit that "there will be a service interruption in this case." Re-enabling stops the outage from continuing; it does not undo the outage that already happened, and it is not a substitute for having a list ready before your tenant is selected.

If you have not acted yet: what still works before October 10

The end-of-September opt-out has passed, and so has Microsoft's October 2 snapshot. What that means depends on where your tenant stands:

• EWSEnabled = True before October 2, no list. You are on Microsoft's October 2 list; it builds your EWSAllowedAppIDs from the previous 60 days of usage on October 8-9. Review that list as soon as it appears — anything that runs less often than every 60 days will not be on it.
• EWSEnabled set to True after October 2. Microsoft's post is direct: you "must populate EWSAllowedAppIDs" yourself. Because "changes to EWSAllowedAppIDs take 24 hours to take effect," a list meant to be in force on October 10 has to be saved no later than October 9.
• EWSEnabled still Null. You are in the second phase. Watch Message Center for the 7-day warning, and treat the time before it as the window to build your own list and set EWSEnabled to True.
• You already built your own list. Microsoft's automated process does not change a list you created, on any path.

Microsoft's September 4, 2026 post put it plainly: "Customers that still require EWS should act now." Building the list is an inventory exercise that takes longer than setting a property, and a list you build yourself is not overwritten.

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 10, 2026 change.

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.

Microsoft builds the list if you don't — not always in September

Microsoft pre-populates the Allow List for tenants that have not created one — but not on one calendar date for every tenant. Per the Exchange Team's September 4, 2026 post, a tenant already at EWSEnabled = True gets its list populated "shortly before the logic change takes place" for that tenant specifically. A tenant still at EWSEnabled = Null gets one "a few days before" Microsoft flips that property to False "during the per-tenant rollout of that setting" — and tenants that never touched EWSEnabled "could have no AppID allow list defined until later in October." A list you built yourself is not overwritten, on either path. Microsoft's October 1, 2026 post adds the dates for the True path: tenants recorded on October 2 get their list on October 8-9. 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.

For a tenant at EWSEnabled = True, the list Microsoft builds comes from a fixed window (the September 4 post gives none for the Null path): "the previous 60 days of usage." Microsoft says so itself — that window "may miss applications that run infrequently," which in practice means the payroll integration that runs quarterly or the reconciliation tool that only fires at year-end can be absent from an auto-populated list even though it is exactly the kind of dependency you cannot afford to lose. Beyond that gap, an auto-populated list is assembled from whatever was running generally. 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, and one a usage snapshot cannot fully replace. That was the argument for building it before Microsoft populates one for you — and that population arrives on a timeline tied to your own tenant's rollout and its EWSEnabled value, not on a single September date.

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. Microsoft's migration guide is precise about which configurations are actually forced, and it is not all of them. Sharing "via Organization Relationship or Sharing Policy relies on Exchange Web Services (EWS) which is being deprecated in Exchange Online" — those two have to move to Cross-Tenant Access Policies. Availability address spaces are the exception: sharing Free/Busy that way "does not depend on Exchange Web Services and is not impacted by EWS deprecation." You can migrate them anyway for the tighter scoping Cross-Tenant Access Policy offers, but nothing in the EWS retirement requires it.

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 your EWS inventory alongside the application IDs, even though it is not something you add to the AppID Allow List.

Four things the Cross-Tenant Access Policy migration will not tell you up front

Microsoft has now published a step-by-step migration guide for this, and it is worth reading before you schedule the work rather than during it. Four details in it change how long the job takes, and none of them is obvious from the Message center post.

Creating the new policy does nothing until you disable the old one. The guide states that "existing Organization Relationships, Availability Address Spaces, and Sharing Policies take precedence over Microsoft 365 Cross-Tenant Access Policies." An administrator who builds the new policies, sees no errors and calls the migration done has changed nothing — the old configuration is still the one in use. The cutover is the disable step, not the create step, and that is the step that needs a change window.

You cannot finish this alone. Cross-Tenant Access Policy is, in Microsoft's words, an "inbound setting," and "for bidirectional sharing, both organizations must create complementary Microsoft 365 Cross-Tenant Access Policies." If you share availability with a parent company, a partner, or an entity you acquired, their administrator has to do their half. That is a scheduling dependency on somebody else's IT department, running against a Microsoft deadline you do not control. Start that conversation early; it is the part most likely to slip.

One configuration type has no clean rollback. Organization relationships and sharing policies toggle off with -Enabled $False and back on again if testing goes badly. Availability address spaces do not: "You can't temporarily disable Availability Address Spaces." Microsoft's own procedure is to export the configuration with Export-CliXML, remove it, and re-import from that file to revert. If you touch these, take the backup first — there is no toggle to undo it.

The tooling is still in preview. The guide's prerequisites call for the Microsoft Graph PowerShell SDK Beta, and the migration runs through New-MgBetaPolicyCrossTenantAccessPolicy cmdlets. Microsoft's own reference list describes the general-availability cmdlets as "Coming Soon." That is workable, but it is not the same as a supported production path, and it is worth knowing before you write a runbook against it.

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. Acting before October 10 buys you control over the timing; it does not buy you a different outcome.

What to do now

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 Microsoft's. Same list, entirely different meaning: yours is a decision, the auto-populated one is a carry-forward of whatever happened to show up in your tenant's recent usage.
5. Get the list in place before October 10, 2026 — saved by October 9. If your tenant is at EWSEnabled = True, an EWSAllowedAppIDs list is required from October 10 in the worldwide cloud, and list changes take 24 hours to apply. If Microsoft built your list on October 8-9, review it against your usage report rather than trusting it. If you are still at Null, build the list and set EWSEnabled to True before your 7-day Message Center warning arrives, not after.
6. Check Outlook builds. Microsoft's October 1 post says Outlook for Windows customers "should be on latest builds (August 2026 build 16.0.20430.20092 or higher)," and that classic Outlook for Mac users need the "Microsoft Office" AppID on the list.
7. Inventory your cross-tenant sharing separately. Organization relationships, sharing policies and availability address spaces will not appear on an application list. Plan the move for the first two, which the EWS retirement forces. Availability address spaces are optional — decide those on their merits, not on this deadline.
8. Flag Apple application IDs as a six-month clock, not a fix. Find the Macs, plan the client change.
9. 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.
10. 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.

Sources

• Microsoft Exchange Team Blog — "EWS Deprecation Is Here – What This Means To You" (published October 1, 2026; updated October 2, 2026, version 8.0). Source for the October 2 / October 8-9 / October 10 sequence, the Null-tenant second phase and its 7-day Message Center warning, the 24-hour and 1-to-4-hour propagation times, and the Outlook build guidance. Read in a browser on October 5, 2026.
• Microsoft Exchange Team Blog — "Exchange Online EWS, Your Time is Almost Up" (published February 5, 2026; most recently updated September 9, 2026, version 20.0). Source for the EWS retirement dates, the two Allow List controls, the hybrid consequence, the "if the list exists, but has no entries" half-finished state, and the service-interruption note on re-enabling EWS after a block. Its own changelog entry for September 9, 2026 reads in full: "A few smaller clarifications made, removed mentions of August, replaced with September..." — the end-of-September opt-out date in this post follows that changelog. That exclusion date is not on the Microsoft Learn page below, written for Skype for Business Server hybrid customers, which still reads end of August.
• Microsoft Exchange Team Blog — "Take control of your EWSAllowedAppIDs list before EWS access changes" (published September 4, 2026). Source for the corrected pre-population mechanics used above and in the FAQ: that a self-configured list is never overwritten, the per-tenant timing tied to a tenant's own EWSEnabled value and rollout date, the 60-day usage window that applies only to the EWSEnabled = True path, the "Customers that still require EWS should act now" line, and the October 1, 2026 start of the logic change requiring an Allow List when EWSEnabled = True. Where this post and the Learn guidance below differ on timing, this is the newer, more specific source and the one this page follows.
• Prepare for EWS retirement, Microsoft Learn, Skype for Business Server hybrid documentation (page date July 8, 2026; updated July 16, 2026; still current as checked September 13, 2026). Source for two things this post treats differently. First, the phrase quoted elsewhere in this post — that Microsoft "pre-populates the allow list for customers who haven't created one before September 2026" — which the Exchange Team's September 4, 2026 post above supersedes with more specific per-tenant timing. Second, this page's own opt-out guidance, written for Skype for Business Server hybrid customers: "End of August 2026 Deadline to set EwsEnabled = $true and add the Skype for Business Server App ID and Skype desktop client App ID to the EWS allowed App IDs list. Must act before this date to keep Skype for Business Server EWS calls working," and its warning that "Complete Steps 2 and 3 before the end of August 2026 to be excluded from Microsoft's October 1 auto-switch." As of September 13, 2026 this page has not been updated since the Exchange Team's September 9, 2026 change to end of September — see the note earlier in this post for our read on what that means if you run Skype for Business Server hybrid.
• Migrate to Microsoft 365 Cross-Tenant Access Policy for sharing Free/Busy, Calendars, and MailTips, Microsoft Learn (page date August 25, 2026; last updated September 1, 2026). Source for the Cross-Tenant Access Policy section and for the correction above it: which configurations the EWS retirement actually forces, the precedence and inbound behavior, the availability address space rollback limitation, and the Graph PowerShell SDK Beta prerequisite.

The 30-second version

EWS deprecation in Exchange Online started on October 1, 2026, per Microsoft's Exchange Team. In the worldwide cloud, starting October 10, 2026, an EWSAllowedAppIDs list is required wherever EWSEnabled = True. Tenants that were True with no list on October 2 get a list built by Microsoft on October 8-9 from the previous 60 days of usage; anyone who set True after October 2 builds their own, and list changes take 24 hours to apply. Tenants still at Null are switched off in a later phase, each with a 7-day Message Center warning, and Microsoft builds their list from 60 days of usage shortly before. Once a tenant is set to False, EWS is blocked for all applications until an admin sets it back to True. 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 list that exists with no entries allows no EWS at all. An auto-populated list is a worse version of the one you would build yourself, and a self-built list is never overwritten. 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 October 10, 2026 change lands, the project intake form takes about three minutes. We'll come back 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.