Many integrations in Exchange Online have relied on Exchange Web Services (EWS) and the ApplicationImpersonation RBAC role for years, mostly without anyone paying attention. I still come across old service accounts with these broad permissions all the time, usually in backup and archiving tools, booking systems or migration scripts. That won't last much longer. Microsoft will retire EWS in Exchange Online on October 1, 2026 (Microsoft's EWS retirement announcement), and ApplicationImpersonation is being phased out too. Since May 2024 you can't assign the role to new users or apps anymore, and from February 2025 existing assignments will be removed. So if an integration still uses EWS and ApplicationImpersonation, it needs a plan now, not at some point later.
EWS and ApplicationImpersonation are on a fixed retirement schedule
For a long time, EWS was the standard API for mailbox management, migrations and a lot of third-party products. Backup vendors and migration tools liked how much it could do, and they often paired it with ApplicationImpersonation so they could reach any mailbox in the tenant. By today's standards that model is genuinely risky. Microsoft has been moving away from it for a while, and the dates are now set. EWS goes away in October 2026, and ApplicationImpersonation role assignments will be removed from Exchange Online RBAC starting February 2025. New assignments haven't been possible since May 2024. In the environments I see, these legacy patterns are still common, sometimes with nobody clearly owning them and no documentation. You can still identify and migrate the affected apps, but the time left is shrinking quickly.
The flowchart below shows the usual path for these integrations:
flowchart TD
Start["Legacy EWS integration in use"] --> CheckImpersonation["ApplicationImpersonation assigned?"]
CheckImpersonation -->|"Yes"| Risk["Critical: Removal from Feb 2025"]
CheckImpersonation -->|"No"| EWSOnly["EWS permission only"]
Risk --> Migrate["Migration to Graph required"]
EWSOnly --> Migrate
Migrate --> EWSRetirement["EWS retires on 1 Oct 2026"]
Figure: Timeline for EWS and ApplicationImpersonation in Exchange Online
With many older backup, archiving or booking solutions, this adds up to a sizeable migration project. Scripts and tools you built in-house will also have to be updated if they're supposed to keep working after these dates.
Affected integrations rarely show up in any existing inventory
I've hardly ever seen a tenant with a complete list of the apps that still use EWS and ApplicationImpersonation. In practice you have to go looking, confirm what you find and write it down. The first step is to check the current role assignments in Exchange Online PowerShell:
# PowerShell 7, Exchange Online Management module, Compliance Management or Exchange Administrator role
Get-ManagementRoleAssignment -Role ApplicationImpersonation
The output lists every user, service account or app that still holds ApplicationImpersonation rights. After that, go through the app registrations in Entra ID and look for questionable API permissions, in particular delegated or application permissions such as EWS.AccessAsUser.All or full_access_as_app. You'll find them in the Entra portal → App registrations → filter by these API permissions. If you want to dig further, the Entra sign-in logs (Entra ID P1 required, sign-in logs enabled) show which apps authenticate against EWS scopes.
Practical tip: Plenty of backup vendors have had Graph-based integrations for some time, yet customers often stay on EWS simply because that's how it was set up. Read your vendor's documentation and migration guides. Sometimes all it takes is a configuration change and a license update.
Talk to your external vendors as well, above all the ones behind booking, archiving or compliance tools. For some of them, getting to a supported model means a major upgrade, or you may end up replacing the product entirely.
Microsoft Graph and Application RBAC replace the old model
After EWS and ApplicationImpersonation are gone, the Microsoft Graph API is the only supported way to build modern integrations (Microsoft Graph mail API overview). Graph now covers the features and scale needed for almost every scenario. Access control is where it gets tricky. The older Graph app permissions (like Mail.ReadWrite or Mail.Read.All) grant access to every mailbox, which is pretty much what ApplicationImpersonation did. This is the gap the new Exchange Online Application RBAC closes. With New-ServicePrincipal and targeted management role assignments, you can limit an app to specific mailboxes instead of the entire tenant.
The setup works like this:
- Register or identify the relevant service principal.
- Define a management scope (e.g., a specific set of mailboxes in Exchange Online PowerShell).
- Assign the required Exchange Online management role (e.g.,
Mailbox Import Export) to the service principal and restrict it with the new scope.
Microsoft keeps the current documentation and instructions at Application RBAC in Exchange Online. Application RBAC is still fairly new, but it has worked reliably in the projects where I've used it, as long as you're on the latest modules and have the right admin roles.
I recommend five steps you can start on today
The final EWS shutdown is still more than a year off, but this is the point to find and migrate whatever EWS and ApplicationImpersonation dependencies you have left. This is the order I'd follow:
- List all current ApplicationImpersonation role assignments (PowerShell)
- Review Entra app registrations for EWS permissions and document them
- Ask vendors about Graph support and published migration paths
- Pilot the move to Microsoft Graph and Application RBAC for key scenarios
- Retire service accounts and legacy scripts in a controlled way
Larger environments really need a staged migration with proper documentation and named owners. Don't leave it until the end, because fixing things is far easier when you aren't up against a deadline.
Security comes out ahead, even though the legacy pain is real
EWS and ApplicationImpersonation used to be convenient, but now they're a serious security risk. Retiring them is overdue in my view, even if a lot of organizations will have real work ahead to modernize. The Graph and Application RBAC model has its rough edges, yet it gives you much better security and control. Starting early spares you a last-minute rush and leaves you with a clean migration. If you want more on Exchange Online permissions and mailbox security, have a look at my earlier post /blog/secure-shared-mailboxes-exchange-online.
