ISEC7 MAIL and the EWS deprecation in Microsoft 365

Hamburg, September 9, 2026 · Diese Seite auf Deutsch lesen

What Microsoft has changed

On October 1, 2026, Microsoft disables Exchange Web Services in Exchange Online by default. The EwsEnabled property switches from null to false in every tenant that has not set the value itself. In tenants that have taken no action, applications that reach the mailbox over EWS no longer connect from that moment.

First the part that decides how urgent this is for you. ISEC7 MAIL, our secure mobile mail client, is moving to the Microsoft Graph API. That work is largely complete, Q4 2026 is reserved for the final touches and an extensive beta phase over iOS TestFlight and Android Beta, and the Graph-based release is planned for early Q1 2027. Until that release is on your devices, ISEC7 MAIL uses EWS, which is why the configuration below matters for the months in between.

What Microsoft changes on that date is the default, not the service. Microsoft calls it a phased, admin controllable disablement: EWS still exists, and it keeps working for tenants that set EwsEnabled to true and maintain an AppID allow list.

The end of the road has a date too. On April 1, 2027, EWS is fully and permanently disabled, and the ability to control EwsEnabled is removed from tenant administrators. Microsoft states there will be no exceptions past April 2027. Everything below is a bridge to that date, not a permanent fix.

The detail that catches people out

The allow list changes meaning on the same date. Until October, an empty list is permissive. From October, it is a block.

EwsEnabled	AppID allow list	Until Sept 2026	From Oct 2026
null	ignored	all EWS allowed	set to false during the rollout
true	empty	all EWS allowed	all EWS blocked
true	populated	only listed apps	only listed apps
false	any	all EWS blocked	all EWS blocked

Source: Exchange Team Blog, Introducing EWSAllowedAppIDs, June 19, 2026, last updated September 1, 2026.

Sources

Exchange Team Blog: Exchange Online EWS, Your Time is Almost Up, February 5, 2026, last updated September 1, 2026
Exchange Team Blog: Introducing EWSAllowedAppIDs, June 19, 2026
Microsoft Learn: Deprecation of Exchange Web Services in Exchange Online
Microsoft 365 Message Center, MC1227454 and MC1447678

Who is affected

Exchange Online

Affected. ISEC7 MAIL, our secure mobile mail client, uses EWS to talk to the mailbox. A tenant that lets EWS lapse loses mail, calendar and contact sync on the device.

Exchange On-Premises

Not affected. Microsoft is not retiring EWS on premises, and the announcement applies to Microsoft 365 and Exchange Online only. On-premises organizations have nothing to configure here.

Hybrid

Mailbox by mailbox. On-premises mailboxes may keep using EWS, cloud mailboxes have to move to Graph, and Autodiscover determines which is which. Microsoft states that only Exchange SE supports Graph for calls to Exchange Online.

We cannot see from our side which of our customers run Microsoft 365 and which run Exchange On-Premises. That is why every ISEC7 MAIL customer receives this information, including those who have nothing to do.

The four steps, before October 1, 2026

Microsoft's recommended order is allow list first, switch second. Doing it the other way round can block every application in the tenant for as long as the list stays empty.

1. Find the Application ID

Open the EWS usage report in the Microsoft 365 admin center and look up the Application ID that ISEC7 MAIL uses in your tenant. The report also shows every other application that still reaches your mailboxes over EWS, which is the more useful part of this exercise.

2. Read the allow list you already have

Since September 2026 Microsoft has been pre-populating the AppID allow list from tenant usage for organizations that had not created one. So the list is not necessarily empty, and the entries in it are not necessarily the ones you want. Reading it first is not optional.

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

The RetrieveEwsOperationAccessPolicy switch is not optional. Without it the property comes back empty, and an empty field looks exactly like a tenant with nothing configured. It is a blank, not an error message, which is what makes it worth saying out loud.

3. Write the list back in full, with ISEC7 MAIL added

Setting the property writes the complete value. There is no add and no remove operation, so every ID you omit is deleted. Microsoft's own pattern is to read, append, and write back:

$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
$newAppId = "ISEC7-MAIL-APP-ID-FROM-STEP-1"
$updated = @($current, $newAppId)
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

Microsoft states that first-party apps belong on the list as well, Office and Power Query for Excel among them. Those do not appear in a query over your own app registrations, which is the most likely way to end up with a list that looks complete and is not. Take it from the usage report.

4. Enable EWS for your organization

Set-OrganizationConfig -EwsEnabled $true

One warning from our own testing

Set-OrganizationConfig does not apply its parameters as one transaction. In our test tenant, a command whose EwsAllowedAppIDs argument failed validation still wrote EwsEnabled to true. A failed command is therefore not proof that nothing changed. Read the state back with the Get command above before you run it again.

Where we are in the calendar

Microsoft's recommended window for configuring the allow list ahead of the change closed at the end of August 2026. Tenants that had no list at that point are getting one pre-populated from their own observed usage. If you are reading this in September, you are not early, and your tenant may already carry entries that nobody in your organization chose.

Three things about timing

Changes to the allow list can take up to 24 hours to take effect, because the servers refresh their cache once a day. Microsoft honours an EwsEnabled value of true that is already in place when the rollout reaches the tenant. And the setting itself is still rolling out: every tenant can read the parameter with Get-OrganizationConfig, but not every tenant can write the list yet. If the write fails, the rollout has not arrived, and it is worth a retry rather than a ticket.

Which is the short version of: September 30 is the wrong day for this. Test the result on a device afterwards, because change control in regulated environments takes longer than a PowerShell session.

The second option, and why we do not put it first

Microsoft offers a second way to keep EWS after October: set EwsEnabled back to null in Exchange Online PowerShell, which restores unrestricted access and ignores the allow list until the final shutdown. It works, and for an organization that cannot get its inventory finished in time it is a legitimate emergency exit. We would not make it the first choice. It hands EWS back to every application in the tenant, known and unknown, and it ends on the same date as everything else.

One more reason to act rather than wait: Microsoft has announced possible temporary shutdowns before the cut-off, to expose hidden dependencies. Tenants that have EwsEnabled set to true are excluded from those.

Where ISEC7 MAIL is going

The move of ISEC7 MAIL from EWS to the Microsoft Graph API is largely complete. Q4 2026 is reserved for the final work and an extensive beta phase over iOS TestFlight and Android Beta. The Graph-based release is planned for early Q1 2027, ahead of Microsoft's April 2027 cut-off. Enabling EWS now buys you exactly that window.

The steps on this page apply to Exchange Online. Whether EWS still answers in your tenant after Microsoft's change is Microsoft's decision, not ours.