EWS Retirement: The Value That Keeps It On Is Null, Not True
From 1 October, EWSEnabled=True with an empty allow list blocks every EWS call in the tenant, and Null is the value that keeps EWS running. The end-of-August date is not a registration with Microsoft, and the kiosk block quietly moved to October.
Every write-up about the Exchange Web Services retirement hands you the same two dates: 1 October 2026 and 1 April 2027. Both are right. Neither tells you what your tenant will do, because that is decided by one organization-level property with three values, and one of the three reverses meaning on the first date.
The property is EWSEnabled. It holds True, False, or Null, and Null is the default that most tenants still have. Microsoft’s phased disablement post gives the behavior on both sides of October, and the row worth reading twice is the one where EWSEnabled is True and the new app allow list is empty. Before October that combination allows everything. From October it blocks everything. Dates and behavior below came off Microsoft’s own posts and Learn pages on 22 August 2026.
What the end of August actually buys
The August date circulating in vendor emails reads like “register your application with Microsoft before the end of August.” It is neither a registration nor with Microsoft. EWSAllowedAppIDs is a tenant-level allow list you set yourself in Exchange Online PowerShell, and the deal Microsoft offers is narrow: populate your own list and set EWSEnabled=True before the end of August 2026, and your tenant is excluded from the automatic flip to False on 1 October. There is no form and no exemption program.
Missing it is survivable, which is the part the urgency emails leave out. After the flip an admin can set EWSEnabled back to True with a list, or back to Null, which re-enables EWS with no restrictions at all until the April 2027 shutdown. Microsoft’s own text says a tenant taking that route sees a service interruption in the meantime, and that the Null route has to be done in PowerShell. So the real cost of missing August is an outage of however long it takes someone to notice and run one command, not the loss of a six-month extension.
There is a September step that argues for doing the work anyway. Microsoft says it will pre-populate the allow list for tenants that have not built one, based on that tenant’s own observed usage. A list assembled from observed traffic contains whatever has been calling EWS, including the scheduled job nobody owns and the vendor connector you were planning to cancel. Build your own list first and the automated pass leaves it alone.
Two traps in the cmdlets
The EWSAllowedAppIDs post has the syntax. Writing is ordinary:
Set-OrganizationConfig -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"Reading it back needs a switch you would never guess, because Exchange only retrieves the list when asked explicitly:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDsThe first trap: Set-OrganizationConfig writes the whole value. There is no incremental add or remove, so adding one app ID means reading the current list, appending, and writing the joined string back. Anyone who runs the naive single-ID version to add a vendor app deletes every other entry in the same keystroke.
The second: changes take up to 24 hours, because servers refresh the in-memory cache once a day. Test on Tuesday for a Wednesday answer.
Worth separating from all of this is the older EWSAllowList many tenants already have. That one matches on User-Agent, not app ID, and it applies to REST and Graph too. The two features coexist and an app has to pass both checks, so an app ID on the new list can still be rejected by a User-Agent rule written years ago.
The things that break are not all yours
The framing of “audit your applications” implies the blast radius is code your organization wrote. It is not. Microsoft’s baseline security mode page documents what stops working when EWS goes off, and the list is mostly first-party:
- Office web add-ins for Word, Excel, PowerPoint and Outlook need build 16.0.19725 or later, which reached Semi-Annual Enterprise Channel in July 2026. Win32 only.
- Teams panels need Teams app version 1449 or later.
- The Power Query Exchange connector stops working in Excel for Windows, Excel for the web, Power BI Desktop, dataflows, Power BI Report Server, Fabric, Power Platform dataflows and Dynamics 365 Customer Insights.
- Cross-tenant calendar sharing, free/busy and MailTips stop working. Those are moving to Cross-Tenant Access Policy separately.
- Server-side sync between Dynamics 365 on-premises and Exchange Online stops working.
- Certificate-based authentication for Exchange ActiveSync, the legacy Exchange flow rather than the Entra one, stops working.
Microsoft’s guidance is explicit that first-party client apps such as Office and Power Query for Excel belong on the allow list if you still need them. An audit that only covers your own code will miss every line above.
The kiosk block moved, and most coverage still has the old date
In December 2025 Microsoft announced that mailboxes licensed with Exchange Online Kiosk, Microsoft 365 F1 or F3 would start getting HTTP 403 from EWS on 1 March 2026, on the grounds that those licenses never included EWS rights and the restriction had simply never been enforced. On 11 June 2026 the same post was edited to move that date to 1 October 2026.
Search results, summaries and several vendor pages still carry March. If you were told that frontline mailboxes had already been cut off and nothing broke, that is not evidence of anything: the block had not happened yet. It lands on the same day as the tenant-wide flip, which means a frontline-heavy tenant gets both failure modes at once.
Graph gaps worth checking before you promise a date
Microsoft tracks parity on the EWS deprecation page, and it is more honest than most vendor roadmaps. As of 22 August 2026:
| Scenario | Status in Graph |
|---|---|
| Public folder CRUD | Will not be built |
| Create an event without inviting attendees | Will not be supported |
| Mailbox import and export | GA since 7 May 2026, primary and shared mailboxes only |
| Archive, public folder and group mailbox import/export | Not covered by that GA |
| In-place Archive | Open gap |
| Event delta for recurring events | Open gap |
| Sticky Notes CRUD | Open gap |
| User configuration, admin APIs | Preview |
The public folder line is the one to read carefully. It is not a gap awaiting a date. Microsoft said in 2025 that CRUD APIs for public folders will not be available after EWS goes away, so a product that manages public folders programmatically needs a different plan, not a longer wait.
The reason all of this accelerated is worth knowing too. The Learn page names the January 2024 Midnight Blizzard incident, which involved EWS, as the point where scope widened from third-party apps to Microsoft’s own. Outlook, Office, Teams and Dynamics have been getting EWS removed since. That is why this deadline has held while so many others slip.
The first move is a report, not a migration
The EWS usage report in the Microsoft 365 admin center lists app IDs that have called EWS, and it takes minutes rather than a planning cycle. Two cautions: it looks back 90 days, so a quarterly or annual job can be invisible in it, and third-party products usually appear under the vendor’s own app ID rather than anything recognizable as yours.
If the report comes back empty, set EWSEnabled=False now and stop thinking about October. If it comes back with rows, the cheap move this month is to write the list yourself before Microsoft writes one for you in September. The migration can take the rest of the window; the list cannot.