Since October 1, 2026, Exchange Web Services (EWS) has been fully blocked in Exchange Online. Microsoft warned about this for years, yet in many of the tenants I've seen, nobody felt the impact until things actually broke. Calendar integrations fail, HR tools stop syncing, and ticketing systems throw vague errors. Troubleshooting a blocked EWS integration has turned into urgent and sometimes frantic work. Often you don't even know which legacy app, script or service account still depends on EWS until a business process stops cold.
A blocked EWS integration usually shows up as a vague error
Usually the first sign is an app that stops working, or an annoyed user who can't reach certain calendar features. Typical errors are "401 Unauthorized", "403 Forbidden" or something unspecific like "Unable to connect to Exchange Online." Modern Outlook clients aren't affected. Third-party scanners, room booking tools and older workflow engines are. In several organisations recently, I've come across old service principals, often with ApplicationImpersonation rights, that kept trying EWS calls after the shutdown. Hardly anyone had ever inventoried or reviewed these integrations, so just figuring out what's failing takes a good part of the effort. For a quick idea of where the problems are, check Entra ID for failed service principal sign-ins first.
The Entra sign-in logs show which app is failing
The most useful place to troubleshoot a blocked EWS app is the Entra admin center → Monitoring & health → Sign-in logs → Service principal sign-ins. Filter for failed attempts after October 1, 2026, then look for application names or resource paths containing 'EWS' or '/ews/exchange.asmx'. This requires Entra ID P1 or P2 licences, and service principal sign-in logging must be enabled. The failed sign-ins carry error messages such as "Client not allowed", "Blocked due to EWS deprecation" or just "interactive sign-in not possible." From there you can see which app broke and when it started failing. The Microsoft documentation on sign-in logs has more detail if you need it.
If you prefer PowerShell (PowerShell 7, Microsoft Graph PowerShell module, Identity Reader or above), try this:
Get-MgAuditLogSignIn -Filter "ResourceDisplayName eq 'Exchange Online' and AppDisplayName ne null and Status/ErrorCode ne 0 and DateTime gt 2026-10-01"
It returns every failed app-based sign-in to Exchange Online since EWS was blocked. In the portal, filter by app name and look for anything that seems old or odd. Don't rely on searching for 'EWS' alone, because some vendors use custom app names or labels that tell you nothing.
In my experience, the quickest way to a fix is a living inventory of all app registrations with EWS, Mail or Calendar permissions, reviewed on a regular basis. Most tenants never kept one until something broke, and at that point you're already behind.
Every broken app needs an owner and a written record
When you know which app registration is failing, find out who owns it and why it exists. Quite often the service principal is orphaned. The original developer has left, nobody knows the business owner, and no one remembers what the app was supposed to do. Check the owner field in the Entra admin center, or ask around in IT and the business teams. Sometimes the only thing left to do is document how it was used and decide to disable it. For accounts with ApplicationImpersonation that haven't been used in a long time, a cleanup is usually overdue anyway. Write everything down, so you can explain later what was affected and why.
Microsoft offers no exceptions in the short term
Microsoft's current announcement leaves no room for interpretation. There are no exceptions, no support tickets and no temporary re-enablement for EWS in Exchange Online. The block is complete and applies globally to all tenants. If line-of-business tools or third-party integrations still rely on EWS, contact the vendor or disable the app. Some tools have already moved to Microsoft Graph, others have simply reached end of life. In-house scripts and tools either get shut down or moved to a supported API. On-premises Exchange isn't affected, though that doesn't help much if all your mailboxes are in the cloud. Searching for a loophole is wasted time, because there isn't one.
In the long run the app moves to Microsoft Graph or gets retired
The only option that lasts is moving to supported modern APIs, Microsoft Graph above all. That usually means new authentication models and different permissions, and often you end up rethinking how app permissions are managed in general. Any service account or tool that still uses ApplicationImpersonation or EWS flows will take real work to modernize. Microsoft's migration guide is a good starting point: EWS to Microsoft Graph migration overview. If you're interested in what the early warning signs looked like back in January, have a look at my earlier post EWS shutdown Exchange Online: Identify and migrate now. My checklist for the last month before the shutdown, along with lessons learned, is in EWS shutdown checklist: The final month essentials.
Before you begin, a simple diagram of the workflow can help:
flowchart TD
App["Legacy app uses EWS"] --> Error["Fails after block"]
Error --> Logs["Review sign-in logs"]
Logs --> Owner["Identify app owner"]
Owner --> Plan["Plan Graph migration"]
Plan --> Fixed["App functional again"]
Figure: The steps I follow to troubleshoot and migrate apps after the EWS block.
I think now is the time to clean up because no shortcut exists
The EWS block in Exchange Online is final, and Microsoft won't grant exceptions. My advice is to put failed service principal sign-ins on your regular audit list. Also run a full inventory of app registrations with mail or calendar permissions before production users run into problems. Waiting for an EWS workaround wastes time and creates a security risk. The cleanup is tedious, but it's the only way to keep Exchange Online apps running safely. Migrating takes real effort, and in return you won't have to deal with this again for a long time.
