Exchange Online | EWS shutdown May 2027

The end of Exchange Web Services (EWS) in Exchange Online is no longer a theoretical scenario, but a timed process that must dominate your infrastructure planning from now on. Microsoft has released the final timeline for disabling and completely removing EWS, turning migration to the Microsoft Graph API from a recommendation to an acute necessity.

EWS comes from an era when on-premises data centers were the standard and security threats seemed trivial compared to today's attack scenarios. The protocol allows deep access to mailboxes, but is structurally not designed for the granular authorization models and security requirements of modern cloud environments. To reduce your tenant's attack surface, Microsoft will gradually eliminate EWS, which will have a direct impact on backup solutions, CRM integrations, and archiving tools.

Microsoft does not act impulsively here, but follows a causal deactivation path so as not to interrupt critical business workflows unprepared. Nevertheless, the timeline remains inexorable.

From October 2026 , Microsoft will initiate the first technical hurdle. In all Exchange Online tenants, the hard property EWSEnabled is set to True . False This step immediately blocks all EWS-based connections. At this stage, you still have the administrative authority to manually reset the value to True or leave it on Null to temporarily save the operation of your legacy apps. However, this is not a solution, but merely a postponement for troubleshooting.

The final cut will take place on April 1, 2027. From this date, the permanent deactivation begins. By May 2027 , EWS will be completely removed from the Exchange Online infrastructure. Reactivation via PowerShell or the Admin Center is then technically impossible.

Since many organizations rely on third-party apps that have not yet made the switch to Graph, Microsoft is introducing a new "Allow List" for EWS applications. This list takes precedence over the previous EWSApplicationAccessPolicy.

Microsoft plans to proactively create this list based on the actual observed EWS usage in your tenant. While this is a helpful service, it does not relieve you of the obligation to critically examine this list. You need to understand which app is tapping into which data. An automated list can contain outdated or insecure integrations that you should eliminate in the sense of the Principle of Least Privilege (PoLP).

To perform the inventory, you should analyze the EWS usage reports in the admin center. This is the only way to identify shadow IT or legacy scripts that would quit the service on day X.

Microsoft's strategy is clear: the Graph API is the only way forward. However, switching is not a simple 1-to-1 exchange of endpoints. EWS offered features that were previously only partially available in Graph or in a roundabout way.

Microsoft is working hard to close these gaps. Recent releases such as the Exchange Admin API (a wrapper for PowerShell cmdlets) and the Graph userConfiguration API are important building blocks. Nevertheless, critical areas such as access to archive mailboxes or public folders remain problematic. It's likely that some niche EWS features will never make their way into the Graph API. This is where you need to architecturally re-evaluate your workflows.

Another risk for developers: Many of the new Exchange-relevant graph endpoints are currently still in beta. This means that Microsoft can change or remove these APIs without much notice. This is an uncertain state of affairs for productive enterprise solutions, which is why pressure is growing on Microsoft to transition these endpoints to V1.0 status as quickly as possible.

If you're running a hybrid configuration, the situation is exacerbated by the dependency on Exchange Server Edition (SE). Microsoft has clarified that Exchange SE is mandatory for smooth coexistence (e.g. free/busy queries or MailTips) between on-premises and cloud.

Once EWS is disabled in the cloud in October 2026, hybrid deployments will need to switch to graph-based queries. Technically, this only works if the on-premises mailboxes are hosted on Exchange SE. If you still rely on Exchange 2019 or older, you will notice that the bridge to the cloud is becoming brittle. While EWS continues to work for purely internal on-premises applications, communication with Exchange Online breaks down without switching to Graph and Exchange SE.

The discontinuation of EWS is the logical continuation of Microsoft's "Secure Future Initiative". From a technical perspective, the removal of a nearly 20-year-old protocol is overdue, as EWS seems like a foreign body in a world of Zero Trust and granular API permissions. In the past, the dependence on a single, powerful protocol has often led to lateral movements in attacks, which is made much more difficult by the delicate scoping of the Graph API.

For you as an administrator, however, this means a massive effort. It is not enough to just adapt your own scripts. You are dependent on the release speed of your software suppliers. If your backup vendor or archiving system doesn't offer native Graph support by April 2027, you risk data loss or compliance violations.

I am particularly critical of the current gap in archive mailboxes and public folders. Many companies use these for legally compliant storage. The fact that Microsoft is not yet delivering any final V1.0 APIs here so close to the deadline puts IT departments on an unnecessary defensive.