The EWS shutdown in Exchange Online is nine months away, and anyone who still uses Exchange Web Services in the cloud should start planning. From October 1, 2026, Microsoft will block all EWS requests in Exchange Online tenants. On-premises Exchange isn't affected. Still, nearly every M365 environment I look at has a few EWS consumers running quietly in the background. If you haven't done it yet, find them now, talk to your vendors and move to Microsoft Graph before the deadline catches you off guard.

The EWS shutdown hits more of Exchange Online than most admins expect

A lot of people think the EWS retirement is a problem for developers and ISVs only. In practice it shows up in places you wouldn't expect. The usual suspects are third-party tools that have worked without complaint for years: archiving systems, CRM plug-ins, room and desk booking add-ons, signature management platforms, and the occasional legacy automation script built on the EWS Managed API. Nobody notices them until they stop working. Custom internal apps and monitoring tools can be affected as well, particularly if they need "EWS.AccessAsUser.All" or "full_access_as_app" (ApplicationImpersonation) permissions. Even in tenants that look modern, I'm regularly surprised by how deep these integrations go.

My advice is to start a systematic inventory of EWS permissions now. If you wait until things break, the migration turns into a messy last-minute rush.

The Entra admin center shows which apps hold EWS permissions

I always start in the Entra admin center under Enterprise applications. Filter for apps with explicit EWS permissions, above all "EWS.AccessAsUser.All" and "full_access_as_app". The Permissions column gives you a quick overview, and when you open an app you can see who uses it and when it last signed in. If you need more detail, the Sign-in logs are very useful for finding old or rarely used integrations.

The diagram below shows how a typical EWS-based integration talks to Exchange Online, which makes it easier to see where to look for connections and permissions:

flowchart TD
    User["User"] --> App["EWS client app"]
    App --> Entra["Microsoft Entra ID"]
    Entra --> Exchange["Exchange Online EWS endpoint"]
    Exchange --> Data["Mailbox data"]

Figure: An EWS client app authenticates via Entra ID to reach Exchange Online.

Apps with ApplicationImpersonation deserve extra attention because they expose a large attack surface. I went into how to handle and replace them in my post on the ApplicationImpersonation retirement in Exchange Online.

The same EWS integrations turn up in almost every audit

From what I see again and again, these integrations come up in nearly every EWS audit:

  • Email archiving solutions (journal export, compliance archiving)
  • CRM and ERP platforms with mail or calendar integration
  • Meeting room/desk booking systems
  • Signature management tools (e.g. server-side email signatures)
  • Custom automation scripts built on the EWS Managed API (see Microsoft docs)

Many vendors support Microsoft Graph by now, though some are still behind. There's no shortcut here. Contact your suppliers, ask where they stand on Graph, and check whether your in-house scripts can be rewritten to use it. Microsoft's official migration guide is the best place to begin.

Sign-in logs reveal which integrations still call EWS

To find out which service principals actually make EWS calls, I go to Entra admin center → Monitoring → Sign-in logs. Filter by application and check the API usage details. A filter on "application permissions" narrows things down to EWS. Looking at the last 90 days usually tells you whether an integration is still in use or is just technical debt that will fail one day.

Homegrown scripts need to move from EWS to Graph

If you have your own PowerShell or .NET scripts, there's no way around Microsoft Graph anymore. How much work it takes depends on the script, but most EWS APIs for mailbox, calendar, contacts and room management have a Graph equivalent. Authentication now goes entirely through Entra ID and OAuth 2.0. Here's a simple PowerShell example (PowerShell 7, Graph PowerShell SDK, Exchange Admin role):

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Mail.ReadWrite.All", "Calendars.ReadWrite.All"
# Example: List the last 10 inbox messages
Get-MgUserMailFolderMessage -UserId "[email protected]" -MailFolderId "inbox" -Top 10

For more complex scenarios, have a look at my earlier post on Automating Microsoft 365 with the Microsoft Graph PowerShell SDK: Life after AzureAD and MSOnline.

I would start migrating EWS dependencies now

Nine months isn't much time once you factor in vendor updates, thorough testing and change management. If anything in your Exchange Online tenant still depends on EWS, start the audit, review the results and migrate. Acting before the shutdown spares you outages, and moving to Graph usually gets you better security and modern OAuth flows as well. Keep an eye on the Microsoft documentation and your Message Center for the latest details and updates.