EWS Retirement in Exchange Online: The 2026 Admin Checklist

The EWS retirement in Exchange Online is entering its final phase, and there is a date before which you need to act if you want any say in how it happens for your tenant.

Exchange Web Services, or EWS, is an older Exchange API that applications use to reach mailbox data — messages, calendar items, contacts and folders. Microsoft is moving Exchange Online integrations off EWS and onto Microsoft Graph.

Microsoft begins tenant-level enforcement on 1 October 2026. EWS is not permanently switched off until 1 April 2027. But the date that actually matters to administrators is sooner than both: if you configure an allow list and explicitly enable EWS before the end of August 2026, your tenant is excluded from the automatic switch to EwsEnabled = $false on 1 October. Miss it, and EWS is turned off for you on Microsoft’s schedule rather than yours.

This guide covers how to find out whether anything in your tenant still uses EWS, how to buy yourself time if it does, and what the actual migration looks like.

Why This Is Moving Faster Than Earlier Deprecations

EWS has been formally deprecated since 2018, and for years the retirement felt theoretical. Two things changed that.

The Midnight Blizzard intrusion disclosed in January 2024 involved EWS, which made the retirement feel less like routine cleanup and more like a security-driven priority for many administrators. Around the same period, Microsoft widened the scope from third-party applications to include its own products — Outlook, Office, Teams and Dynamics 365 are all having EWS dependencies removed as part of the same effort.

That is why the timeline now has hard dates attached rather than an open-ended “at some point”.

The Dates That Matter

Microsoft’s published guidance states that Exchange Online EWS enforcement begins on 1 October 2026 with full retirement on 1 April 2027 — see the deprecation of EWS in Exchange Online documentation. Rollout details can change, so check your Microsoft 365 Message Center for tenant-specific notices before making any tenant-wide change. The Message Center is the authoritative source for your own tenant.

Quick Admin Checklist

• Run the EWS usage report in the Microsoft 365 admin centre
• Review Entra sign-in logs for applications accessing Office 365 Exchange Online
• Search the Unified Audit Log for EwsAccess events
• Inventory Entra app registrations holding EWS permissions, both application and delegated
• Run the EWS Analyzer against in-house code that may not appear in any log
• Identify a business owner for every app, vendor product, script and scheduled task you find
• Build the EwsAllowedAppIds list from all of the above, not from one source
• Set EwsEnabled to $true before the opt-out deadline if you still need EWS
• Plan the migration to Microsoft Graph before April 2027

Understanding the Three States of EwsEnabled

This setting is not a simple on/off switch, and the difference matters for what happens to your tenant in October.

Who Is Affected

EWS has been deprecated for years, so the instinct is to assume nothing in your environment depends on it. That assumption is usually wrong, because the dependencies tend to sit in tools nobody thinks of as “Exchange integrations”:

• Backup products — several mailbox backup tools still use EWS for item-level access
• Migration tools — tenant-to-tenant and on-premises migration utilities are heavy EWS consumers
• CRM and helpdesk sync — anything that files email against a customer record
• Signature management — several enterprise signature products
• Archiving, journaling and eDiscovery add-ons from third parties
• Room and resource booking panels — meeting-room displays are a common surprise
• In-house scripts — anything written against the EWS Managed API, often years ago by someone who has left

The last one is the dangerous category. Vendor products have vendors who send migration notices. A PowerShell script on a scheduled task has nobody.

This does not mean Outlook or Outlook on the web will simply stop working for your users on 1 October. Microsoft is removing EWS dependencies from its own products as part of the same programme. The risk you can directly control is third-party applications, vendor tools, legacy integrations and custom automation calling EWS directly.

Step 1: Find Out What Actually Uses EWS

Do not guess, and do not rely on a single source. Each method below sees something the others miss.

The EWS usage report

Start in the Microsoft 365 admin centre. The EWS usage report summarises activity across the tenant and breaks it down by which EWS SOAP actions are being called and in what volume over time. It is the fastest way to know whether you have obvious current activity.

Entra sign-in logs

In the Microsoft Entra admin centre, go to Monitoring & health → Sign-in logs and filter on the resource Office 365 Exchange Online. Review the Application column. This gives you named applications rather than raw activity counts, which is what you need in order to contact anyone.

Unified Audit Log

Search the Unified Audit Log for the EwsAccess activity. This catches usage the other two methods can under-report, particularly intermittent or scheduled jobs that only run monthly. If the audit log interface is unfamiliar, the same tooling is covered in our guide to audit and compliance workflows in Purview.

App registrations

Inventory your Entra app registrations for EWS-relevant permissions — full_access_as_app and EWS.AccessAsUser.All in particular. Check both application and delegated permissions: app-only access is typical of backup, migration and service integrations, while delegated EWS access shows up in tools acting on behalf of a signed-in user. An app holding the permission but showing no recent activity is still worth investigating, because quarterly jobs will not appear in a 30-day log window.

EWS Analyzer

Microsoft publishes an EWS Analyzer tool for the case that logs cannot catch: a scheduled task or old .NET service containing EWS calls that simply have not run inside any reporting window. If you have in-house code, this is the only method that finds dependencies before they fire.

Microsoft’s Exchange team has published detailed guidance on finding and remediating EWS app usage, including the discovery tooling and how to correlate results across sources.

Discovery Sources: What Each One Tells You

No single source is complete. This is why the checklist above lists five.

When an App ID has no obvious owner

Reports give you GUIDs, not accountability. When an App ID appears with no clear owner, check the Entra app registration owner field, enterprise application sign-in activity, service principal notes, vendor documentation, the servers running your scheduled tasks, and your helpdesk or backup system configuration.

Do not approve an App ID simply because it appeared in a report. Tie every entry to a business owner and a named system before it goes on the allow list — an unexplained GUID you allow in August is an unexplained GUID you still cannot account for in April.

Step 2: Check Your Current Configuration

Connect to Exchange Online PowerShell and run two checks. This is the same connection you use for Exchange mail flow rules and other tenant-level Exchange work. The new allow list needs its own switch and will not appear in a standard Get-OrganizationConfig output:

Connect-ExchangeOnline

# Tenant-level EWS state and the older user-agent based controls
Get-OrganizationConfig | Format-List EwsEnabled,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockList

# The new application ID allow list
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

The second command matters. Without -RetrieveEwsOperationAccessPolicy the allow list does not come back, and it is easy to look at an empty result and conclude nothing is configured when something is.

If EwsEnabled returns blank, your tenant is in the $null default state — the one that gets automatically switched off on 1 October.

Step 3: Configure the Allow List Before the Deadline

If your discovery in Step 1 found applications that genuinely still need EWS and cannot be migrated in the next few weeks, configure the allow list now. This buys you time until April 2027 rather than having the decision made for you in October.

Microsoft will pre-populate an allow list in September 2026 for tenants that have not created one, derived from observed EWS usage. That is a helpful safety net, but it is built from telemetry — it cannot see a quarterly job that has not run, or an application that is dormant but still business-critical. Treat anything Microsoft populates as a starting point to validate, not a completed inventory.

Add to the list rather than replacing it

This is the step most likely to cause an outage. Set-OrganizationConfig -EwsAllowedAppIDs writes the whole list as a comma-separated string, so passing a single App ID silently removes everything already there — including anything Microsoft pre-populated or a colleague added.

Read the current list, append, then write the combined set back:

# Read what is already configured
$current = Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
  Select-Object -ExpandProperty EwsAllowedAppIDs

# Define the new App ID to add
$newAppId = "00000000-0000-0000-0000-000000000000"

# Combine existing and new values, dropping blanks and duplicates
$updated = @($current, $newAppId) | Where-Object { $_ } | Select-Object -Unique

# Write the combined list back as a comma-separated string
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

# Explicitly enable EWS at tenant level
Set-OrganizationConfig -EwsEnabled $true

# Confirm both settings applied
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
  Format-List EwsEnabled,EwsAllowedAppIDs

Note the -join ",". This parameter expects a comma-separated string rather than a PowerShell array, which is a common cause of the command not behaving as expected.

Replace the sample GUID with a real application ID from your Entra app registrations or your vendor’s documentation. The placeholder value is illustrative and will not match anything in your tenant.

Step 4: Plan the Migration to Microsoft Graph

The allow list is a stay of execution, not a solution. Everything moves to Microsoft Graph before April 2027.

For each application you identified, the path depends on who owns it:

• Vendor products: contact the vendor for their EWS retirement statement and the version that uses Graph. Most major vendors have published one. Budget for an upgrade, because Graph support is frequently gated behind a newer release rather than a patch.
• In-house code: run the EWS Analyzer first, then use Microsoft’s EWS-to-Graph mapping resources to identify which Graph APIs replace the operations your code actually calls. Microsoft has also published a tutorial for AI-assisted analysis and refactoring of EWS code, worth reviewing before anyone starts rewriting by hand.
• Anything unowned: if nobody can say what an app does or why it exists, that is your answer. Turn it off in a controlled way now rather than discovering its purpose when it breaks in April.

Expect the permissions model to be the real work. Graph uses granular scopes rather than the broad impersonation EWS relied on, so migration usually means revisiting how the application authenticates, not just swapping endpoints.

Prioritise by blast radius, not by ease. A backup product failing silently is far worse than a room booking panel showing an error, even though the panel is the more visible problem.

What Happens If You Do Nothing

On 1 October 2026 your tenant has EwsEnabled set to $false as part of the staged rollout. Every application depending on EWS stops working at that point. In practice that tends to mean:

• Mailbox backup jobs stop collecting new items
• Migration batches fail or stall part-way
• CRM and helpdesk sync stops filing messages against tickets
• Room booking panels stop showing availability
• Signature tools stop applying to new or updated mailboxes
• Custom scripts fail with authentication or access errors

The failure mode is what makes this worth acting on early. EWS applications do not usually fail loudly. Backups report success while backing up nothing. Sync jobs stop syncing without alerting. You often find out weeks later, when someone needs the thing that stopped working.

You can re-enable EWS and configure the allow list after 1 October. But you will be doing it under pressure, with something already broken, and without knowing which of the several things that failed that morning is the one you are being asked about.

Final Thoughts

This is one of those changes where the technical work is small and the discovery work is everything. Setting two PowerShell parameters takes five minutes. Working out which of your integrations depend on EWS, who owns them, and what happens when they stop is the actual project.

If you do nothing else this week, run the EWS usage report. It takes two minutes and tells you whether you have obvious current EWS activity. If it comes back empty, do not close the risk — an empty report only means nothing called EWS inside the reporting window. Check app registrations, sign-in logs, audit logs, vendor documentation and your own scheduled scripts before you decide the tenant is clear.

For the other requests that land on a Microsoft 365 administrator regularly, see our guide to common Microsoft 365 admin tasks.