Exchange Web Services (EWS) has been a foundational API for applications accessing Exchange Online, but Microsoft is retiring it in favor of Microsoft Graph.
If you haven't started already, now is the time to evaluate your environment, talk with application developers, and plan the move to Microsoft Graph.
You need to identify applications that still rely on EWS, understand the upcoming enforcement deadlines, and determine whether vendors and internal applications are prepared to migrate. This guide explains what is changing, how to assess your EWS exposure, and the steps you can take to reduce disruption and security risk before deprecation.
Figure 1: Microsoft 365 Admin center message center post (MC1469960)
EWS is a SOAP-based API (Simple Object Access Protocol) that allows applications to interact programmatically with Microsoft Exchange mailboxes and related services. SOAP relies on XML as its message format. Through EWS, software can create, read, update, move, and delete email messages, calendar appointments, contacts, tasks, and other mailbox data, as well as perform operations such as searching folders and managing meeting responses. EWS provides a standardized, server-side interface for integrating custom applications and business systems with Exchange, avoiding the need to interact directly with mailbox databases or depend on a full desktop email client. EWS has been widely used for Exchange and Outlook integration.
Historically, applications interacted with Exchange Online data by making SOAP requests over HTTPS to the EWS endpoint. Developers utilized specialized libraries, such as the EWS Managed API or various platform-specific wrappers, to construct these XML-based requests, which allowed them to perform granular operations like creating, reading, updating, deleting (CRUD), or syncing items directly within a user's mailbox without needing a local client like Outlook.
The most common applications that use EWS are backup and archiving software, CRM applications, and scheduling and calendar integration programs.
Exchange Web Services was introduced with Microsoft Exchange Server 2007 as a successor to WebDAV, CDO, ExOLEDB, and MAPI/RPC. Microsoft's goal was to provide a single, firewall-friendly API that exposed the full Exchange data model over HTTPS. It quickly became the strategic integration point for Exchange, and Microsoft reinforced this by shipping the EWS Managed API for .NET (2009) and a Java equivalent, along with Autodiscover for zero-configuration endpoint resolution.
EWS carried forward through Exchange 2010, 2013, 2016, and 2019, and became the primary programmatic interface for Office 365 and Exchange Online at launch.
EWS became so popular because of the following:
The characteristics that made EWS attractive are the same ones that make its retirement painful. Its breadth means Microsoft Graph has taken years to approach feature parity, and gaps still exist in areas like extended properties, archive mailbox access, and certain notification patterns. And its longevity created a vast installed base of production integrations (email signature platforms, backup and archiving suites, migration tools, CRM connectors, room-booking systems, and compliance products), all of which must now be re-engineered against a newer, narrower, and more tightly governed API.
EWS became indispensable because it was broad, portable, and frictionless.
Microsoft is retiring EWS in Exchange Online because the protocol has simply outlived the era it was designed for. Built in 2007 and originally shipped with Basic authentication, EWS is fundamentally at odds with modern security expectations.
It enabled credential-based access patterns that fueled password spray, token replay, and legacy-auth attacks, and it predates OAuth 2.0, Conditional Access, and the fine-grained, app-scoped permissions that now underpin Microsoft's Zero Trust strategy.
At the same time, EWS sits on an aging codebase that is expensive to maintain, receives only critical bug fixes, and has had no new feature investment since 2018, when Microsoft publicly designated Microsoft Graph as the single, strategic API for Microsoft 365.
Graph unifies mail, calendar, contacts, Teams, OneDrive, Entra ID, and the wider Microsoft 365 platform behind one REST endpoint, one identity model, and one consent framework, something a mailbox-only SOAP API from the on-premises era was never going to deliver.
Retiring EWS lets Microsoft consolidate its developer surface, close a long-standing security gap, reduce operational load on the Exchange Online service, and push the ecosystem onto a modern, governable, cloud-native foundation.
EWS played a central role in the Midnight Blizzard intrusion that Microsoft disclosed in January 2024, and in the closely related compromise of Hewlett Packard Enterprise disclosed around the same time.
The state-sponsored actor gained an initial foothold by password-spraying a legacy, non-production Microsoft tenant test account that lacked multi-factor authentication. From there, they were able to grant themselves the full_access_as_app role for EWS.
That single permission gave the attackers application-level access to read the contents of any Exchange Online mailbox in the tenant.
Figure 3: Microsoft's recommendation notice
We are now inside the final days before EWS becomes off by default, allow list only, from 1 October 2026.
You need to act fast. If you haven't reviewed which of your applications are and will be impacted, you need to view the usage report in Microsoft 365 Admin Center > Reports > Usage > Exchange.
Direct link to the EWS Weekly Usage report in the admin center
Figure 4: EWS Usage in Admin Center
If you have production workloads still calling EWS against Exchange Online today, you should assume they will be broken by the morning of 1 October 2026, unless you have added those applications to an allow list.
First, confirm the tenant's EwsEnabled state using Exchange Online PowerShell. The EwsEnabled property supports three values: True, False, and Null.
Get-OrganizationConfig | Format-List EwsEnabled EwsEnabled :
If it is null as in the above output, all EWS is allowed today. From 1 October 2026, it changes from null to False, which means that Microsoft will block EWS for all applications in the tenant at that time.
If it is set to True, then you should have an allow list of applications and only Apps in the AppID Allow List will be allowed*.
Get-OrganizationConfig | Format-List EwsAllowedAppIDs EwsAllowedAppIDs :Or
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs EwsAllowedAppIDs :
If EwsEnabled is set to False, all EWS applications are blocked today and will remain blocked.
* If you have not created a list, Microsoft will populate one to reduce the risk of an outage when the change hits the tenant, but EwsEnabled must be set to True. The list will be based on the previous 60 days of usage. The Exchange team explicitly recommends not relying on this, because the automated list may contain apps you did not realize were still calling EWS.
The EwsEnabled = True needs to be set today!
On-premises Exchange is not affected by this date. EWS continues to function on Exchange Server 2016, 2019, and Exchange Server Subscription Edition (SE). For hybrid environments, review the Exchange Server Security Changes for Hybrid Deployments | Microsoft Community Hub post.
The immediate takeaways are:
EwsEnabled and EwsAllowedAppIDs are the two properties that turn "EWS deprecation" from an abstract Microsoft announcement into a concrete configuration state on your tenant. From 1 October 2026, they are the settings that decide whether your EWS-dependent applications keep working or stop at the door.
From October 2026, enforcement begins: any tenant still showing EwsEnabled = Null will be flipped to False by Microsoft and EWS will be blocked for all applications in that tenant, at which point administrators must decide whether to leave EWS off (recommended if nothing has broken) or explicitly set EwsEnabled = True and rely on the EwsAllowedAppIDs list to keep a named set of critical apps working while migration completes.
Finally, in April 2027, the tail phase ends: Microsoft sets EwsEnabled = False across all tenants, the allow list stops mattering, and no further extensions or exceptions are possible.
From May 2027 onwards there is no EWS in Exchange Online, and any integration still calling it will be permanently broken.
October is the enforcement gate, but April 2027 is the true, unavoidable end of the road.
If your organization genuinely cannot migrate every workload before 1 October 2026, treat the extra time bought by EwsEnabled = True and EwsAllowedAppIDs as a short-term exception with an expiry date, not a reprieve.
Populate the allow list yourself rather than letting Microsoft auto-generate it from the last 60 days of usage, because the auto-generated list will happily include forgotten, dormant, or compromised apps that happened to authenticate recently.
Every AppID you add should have a named owner, a documented business reason, and a target Graph migration date recorded outside the tenant. Remember that applications with full_access_as_app permission are high risk and should be treated as a top-priority security review item.
Figure 5: Example of full_access_as_app permission
Kill Basic authentication entirely and require OAuth 2.0 with certificate credentials or managed identities for every remaining EWS caller.
Apply least-privilege Graph and EWS permissions and, wherever possible, use RBAC for Applications to scope each app to only the mailboxes it actually needs, which is the single most effective mitigation against the Midnight Blizzard style of abuse.
Enforce Conditional Access on the service principals, monitor the Entra sign-in logs and Exchange audit logs for those AppIDs specifically, and set a calendar reminder to review the allow list monthly and remove entries as workloads move to Graph.
Finally, remember that April 2027 is a hard wall with no extensions, so any AppID still on the list at that point is a guaranteed outage, not an open question.
The fastest way to surface these apps is through Microsoft Graph PowerShell or the Entra admin center, because the permission is recorded as an app role assignment on the Office 365 Exchange Online service principal (AppId 00000002-0000-0ff1-ce00-000000000000), not on the app registration itself.
In Microsoft Graph PowerShell, connect with
$exoSpId = (Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'").Id $fullAccessRoleId = "dc890d15-9560-4a4c-9b7f-a736ec74ec40" Get-MgServicePrincipal -All | ForEach-Object { $assignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $_.Id -ErrorAction SilentlyContinue $match = $assignments | Where-Object { $_.ResourceId -eq $exoSpId -and $_.AppRoleId -eq $fullAccessRoleId } if ($match) { [pscustomobject]@{ DisplayName = $_.DisplayName AppId = $_.AppId ObjectId = $_.Id GrantedOn = $match.CreatedDateTime } } }
Any app that comes back from these queries should be treated as a priority security review, because it holds tenant-wide, unattended mailbox access, exactly the class of permission Midnight Blizzard exploited. Confirm the owner and business justification, verify it is still needed, and where it is, migrate it to Graph with the narrowest possible application scope (for example Mail.Read combined with RBAC for Applications to restrict which mailboxes it can touch) rather than a like-for-like Mail.ReadWrite.All grant.
Finding every app with full_access_as_app by hand is exactly the effort that ENow makes easy. The free AppGov Score scans your tenant for applications holding high-risk Exchange permissions, and the ENow App Governance Accelerator enables deep analysis of your Entra ID applications without PowerShell. With a 7-day trial, you can use ENow AppGov to discover which of your enterprise applications and app registrations would be impacted by the EWS deprecation.
With the Enterprise Applications with API Permissions and App Registrations with API Permissions dashboards, you can search for specific EWS permissions like full_access_as_app and see every app that holds it. You can also layer in additional information on the affected applications to inform a cleaner EWS allow list. With a continuously updated application inventory, your team can track those applications, owners, and permissions over time, so governance holds long after the initial deadline.
Microsoft starts enforcing EWS deprecation on October 1, 2026. From that date, any tenant still showing EwsEnabled as Null is switched to False, which blocks EWS for every application. EWS in Exchange Online is fully retired after April 2027, with no further extensions or exceptions.
No. The October 1, 2026 change applies only to Exchange Online. EWS keeps working on Exchange Server 2016, 2019, and Exchange Server Subscription Edition. If you run a hybrid deployment, review Microsoft's guidance on Exchange Server security changes for hybrid before you make tenant-level changes.
Open the Microsoft 365 admin center and go to Reports > Usage > Exchange, then check the EWS Weekly Usage report. For a permissions view, use Microsoft Graph PowerShell to list every service principal that holds the full_access_as_app role on the Office 365 Exchange Online app. Or use an application inventory governance tool like ENow App Governance Accelerator.
EwsEnabled is a tenant-wide switch with three valid values: True, False, or Null. EwsAllowedAppIDs is the list of application IDs permitted to call EWS when EwsEnabled is True. Setting EwsEnabled to True without a curated allow list leaves EWS open to every app, so treat the list as a security control.
Microsoft Graph is the replacement API. Map each EWS operation to its Graph equivalent using Microsoft's EWS-to-Graph mapping, then rebuild each integration against Graph with least-privilege permissions. Where an app needs mailbox access, scope it with RBAC for Applications instead of granting tenant-wide access. If you're utilizing third-party applications that are still using EWS permissions for Exchange Online, contact the vendor for guidance.
full_access_as_app grants an application read and write access to every mailbox in the tenant. That is the permission the Midnight Blizzard attackers abused in January 2024 after compromising a legacy test account. Any app holding it should get a priority review, tighter scoping, and a migration plan.
EWS deprecation is not only an API migration project. It is also an opportunity to inventory the applications accessing Exchange Online, eliminate unnecessary access, reduce overly broad permissions, and establish stronger application governance before legacy access disappears.