EWS is being switched off: what to do before 31 August

On 1 October 2026 Microsoft blocks Exchange Web Services in every tenant that has done nothing by then. What is affected is not the mailboxes themselves but the programs that reach into them: the archiving system, the CRM connector that syncs the calendar, the room booking display in the meeting room, the backup service. All things that have run quietly for years and are therefore on nobody’s list.

The window to handle this yourself closes on 31 August 2026.

What happens when

• 31 August 2026: Last day to set your own allow list and put EwsEnabled to $true. Do that, and October’s automatic block passes you by.
• September 2026: Microsoft creates an allow list for tenants that have none, based on what actually ran over EWS there. It is preparatory work, not a rescue.
• 1 October 2026: In every tenant where EwsEnabled is still Null, the value is set to False. That blocks EWS for all applications, including those on the list Microsoft built.
• 1 April 2027: Final retirement. After that EWS cannot be switched on again, not even through an allow list.

This is about EWS in Exchange Online only. A local Exchange server serving mailboxes on site is untouched. In a hybrid setup, look closer: a local server or a local tool that reaches mailboxes in the cloud over EWS very much falls under the block.

The common misreading: "Microsoft builds the list anyway"

True, and it still does not help. The reason sits in two switches that work independently.

The allow list says which applications may use EWS. The switch EwsEnabled says whether EWS is open at all. On 1 October that second switch is set to False in every tenant that has not set it. A closed door stays closed, no matter who is on the guest list.

Only those who set both themselves, list and switch, run on unchanged through 1 October. The list Microsoft builds saves work once somebody throws the switch; it does not replace that step.

Two further reasons not to lean on somebody else’s list, even with the switch set:

• It only knows what was running. The list is built from measured usage. An application that runs at quarter-end, at year-end or only during an incident was silent in that window and is therefore not on it. It then fails on the very day it is needed.
• It is not your own. You can read it out, but nobody decided what went on it, and changes leave no trail. For an environment that has to be described in an audit or a security concept, that is a step backwards.

And the case few think of: if you can show that nobody uses EWS, the automatic block is not the risk; it is the goal. It closes a door nobody walks through any more. The check is still worth doing, but it may well end in "nothing to do", and that is a good result.

How to find out who uses EWS at all

This is the real work, and it is smaller than it sounds. Microsoft provides an EWS usage report in the Microsoft 365 admin centre. Per application it shows the identifier (application ID), the operation called, the number of calls and the time of last activity.

The period you choose is the setting that matters. The shortest shows everyday traffic. The longest also shows what runs monthly or quarterly, precisely the part that slips through the automatic list. Which periods the report offers in your own tenant is visible in the view itself; the details have changed more than once.

The audit log in Microsoft Purview and the sign-in logs in Entra ID help alongside it. They show the same access from another angle and are useful where the usage report offers only a bare identifier with no recognisable name. For the sign-in logs in full, though, Entra ID P1 is required, and that is not in every plan.

No report sees everything. What runs once a year appears in no measurement window. Alongside the report, then, a second look belongs: go through the application registrations in Entra ID to see which ones hold EWS permissions at all, and ask the vendors of the line-of-business applications in use. The report shows what ran. The permissions show what could run.

At the end of this step there is a list of application identifiers. That some of them cannot be placed straight away is not an oversight; an environment collects such entries over years. Resolving them is the work that sits between the report and a defensible allow list.

One boundary worth naming, because it causes confusion: devices that send scanned documents by email generally work over SMTP, not EWS. They are not affected by this retirement, though they are affected by other changes Microsoft is running in parallel. Here too the usage report is the reliable answer: what does not appear there does not use EWS.

What to do before 31 August

One command in Exchange Online PowerShell:

Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "<app-id-1>,<app-id-2>"

EwsAllowedAppIDs takes the Entra application identifiers (GUIDs); anything not on it is blocked. EwsEnabled keeps the door open. Both belong in the same call. That is how Microsoft’s own example in the PowerShell documentation shows it.

To read back what is stored:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Two things that easily go wrong:

• Do not confuse them: there is an older parameter EwsAllowList that permits applications by name pattern and works together with EwsApplicationAccessPolicy. For the 2026 change the right one is EwsAllowedAppIDs; it works with Entra identifiers.
• The list is set, not extended. Run the command a second time with a single identifier and that is the only one permitted afterwards. Read it out first, then write it complete.

If you would rather work in the interface: Baseline security mode in the Microsoft 365 admin centre carries one recommendation for Exchange Online, and it is to block EWS. So it is the counterpart: useful for reducing attack surface when genuinely nobody needs EWS, but not a way to maintain an allow list.

The real path leads to Microsoft Graph

The allow list buys time until 1 April 2027, nothing more. The intended successor is Microsoft Graph; for many EWS operations Microsoft lists a documented equivalent there. Which ones those are in a given case is in Microsoft’s comparison, and it is still changing.

Not for all of them. Backup solutions and the import and export of public folders have no equivalent path in Graph today, and they are not the only gaps; Microsoft maintains the open points itself and revises the list. If you run a backup that works over EWS, take that up with the vendor directly, and now rather than in March.

Moving to Graph need not mean writing your own code. Where standard software is in use it usually means a newer version, provided the vendor has made the move, the licence covers it and the necessary permissions can be set up in Entra. The first question, then, is not "how do we rewrite this" but "what does the vendor say about their timeline".

What this means for a company in practice

• By 31 August: pull the usage report, resolve the identifiers, set the allow list, set EwsEnabled to $true. The automatic change on 1 October then no longer applies to you. Whether everything really keeps running depends on the list being complete, so a functional test belongs after setting it, not just a read-back.
• If the deadline is missed: access can be reopened after 1 October; Microsoft names this explicitly and points at the service interruption that runs until then. So the outage lasts as long as it takes somebody to notice what is wrong, and that is the expensive part, not the command itself.
• By 1 April 2027: for every application on the list, establish whether it has moved to Graph or can be moved. That is the hard date, because after it no switch helps.
• Not affected: local Exchange servers with local mailboxes, and anything working over other protocols.

Where we help

We pull the usage report, resolve the application identifiers, set the allow list and work out with the vendors what has to be on Graph by 2027, as part of managing Microsoft 365 or as a separate piece of work. For how hybrid environments play out otherwise, see hybrid infrastructure. And why the last local Exchange server can go since 2026 is set out in this article. A first conversation is on us.

Status: 23 August 2026, checked against the Exchange team announcements and the Microsoft PowerShell documentation. Dates and scope have shifted more than once during this retirement: before changing anything in your own tenant, check the current state there once more.