Microsoft has confirmed that starting October 1, 2026, Exchange Web Services (EWS) access in Exchange Online will be restricted to only applications explicitly added to an approved allow list, as the company phases out the legacy API in favor of Microsoft Graph. The move marks the beginning of a two-phase retirement that will culminate in a complete shutdown of EWS for Exchange Online on April 1, 2027. For Windows administrators and IT professionals managing hybrid or cloud-only Exchange environments, the clock is now ticking to migrate integrations, audit application dependencies, and ensure business continuity.
This retirement does not affect on-premises Exchange Server deployments. Only Exchange Online tenants are impacted, but given the widespread use of EWS in third-party backup tools, CRM connectors, messaging apps, and custom line-of-business applications, the ripple effects will touch nearly every organization that relies on Microsoft 365.
The End of an Era for EWS
Exchange Web Services has been the backbone of programmatic access to Exchange mailboxes since Exchange 2007. The SOAP-based API allowed developers to build everything from calendar sync apps to email archiving solutions. Microsoft shifted its recommended development path to Microsoft Graph in 2015, but EWS remained available for backward compatibility. Feature work on EWS effectively stopped in 2019, and the service has been in maintenance mode since.
With the retirement announcement, Microsoft is pushing the final nail in the coffin. The company first hinted at deprecation in 2021, and over the past year, Message Center posts (MC715749, MC834239) have reinforced the timeline. The new allow list mechanism, available now for tenant configuration, will become the only gatekeeper of EWS access after October 2026. Applications not on the list will receive errors when attempting to connect.
Critical Timeline at a Glance
| Phase | Date | Action |
|---|---|---|
| 1 | October 1, 2026 | EWS access restricted to apps on the tenant’s allow list. Unapproved apps are blocked. |
| 2 | April 1, 2027 | Complete EWS shutdown for Exchange Online. No exceptions. |
- Before October 2026: Admins must configure the allow list in the Exchange admin center or via PowerShell. Test in a sandbox tenant first.
- Between October 2026 and April 2027: Only explicitly allowed applications continue to function. This window is for final migrations.
- After April 1, 2027: EWS is dead for Exchange Online. Calls will fail permanently.
Why Microsoft Is Retiring EWS
Microsoft Graph represents a unified, more secure, and more performant API layer for Microsoft 365 services. It uses OAuth 2.0 authentication, granular permissions, and a single endpoint (graph.microsoft.com). EWS, by contrast, relies on basic authentication (which has been disabled for Exchange Online) or OAuth, but its feature set is frozen. Maintaining two parallel access stacks is costly and introduces security risks.
Graph APIs also enable richer scenarios: mail, calendar, contacts, tasks, and even Teams integration under one roof. Microsoft has been investing heavily in Graph, and all new Exchange Online features are exposed exclusively through it. The retirement of EWS is the logical conclusion of that strategy.
What the Allow List Means for Windows Admins
The allow list is a tenant-level list of application IDs (App GUIDs) that are permitted to use EWS. Microsoft has provided two ways to manage it:
- Exchange admin center (EAC): Under the new “EWS access” tab, admins can enter app IDs manually.
- Exchange Online PowerShell: Using the
*-EwsApplicationAccessPolicycmdlets, admins can script additions, removals, and auditing. Example:Set-EwsApplicationAccessPolicy -Identity "TenantName" -BlockList(switch to allow list mode).
Crucially, admins must first identify every app or service that uses EWS. This includes:
- Third-party migration tools (BitTitan, Quest)
- CRM/ERP email integrations (Salesforce, Dynamics)
- Backup and archiving solutions (Veeam, Commvault)
- Custom scripts and PowerShell modules that call EWS APIs
- Multifunction devices with Scan-to-Email using EWS
- Legacy email clients and add-ins
Microsoft recommends running the “EWS migration assessment” script available in the Microsoft 365 Admin Center. It scans your tenant for active EWS usage and lists the applications detected. This report is essential to populate the allow list accurately.
Which Applications and Scenarios Are Affected?
The retirement impacts any client that uses the EWS SOAP protocol to Exchange Online. This includes:
- Outlook for Mac (older versions that use EWS for calendar/contacts sync – newer versions use Graph)
- Skype for Business (if still using EWS for presence integration)
- Some Microsoft Teams features that rely on EWS for mailbox access (though Teams has largely moved to Graph)
- Third-party mobile email apps that use EWS instead of ActiveSync or Graph
- Enterprise Service Bus connectors (MuleSoft, SAP PI)
One often-overlooked area is RBAC and impersonation: many applications use EWS Impersonation to read multiple mailboxes. After April 2027, that will need to be replaced with Graph’s app-only permissions and the Mail.Read, Mail.ReadWrite, etc. scopes.
Migration Path to Microsoft Graph
Microsoft Graph provides equivalent functionality for most EWS use cases. The table below highlights common EWS operations and their Graph counterparts.
| EWS Operation | Microsoft Graph API |
|---|---|
GetItem |
GET /users/{id}/messages/{id} |
FindItem |
GET /users/{id}/messages (with OData queries) |
CreateItem |
POST /users/{id}/messages |
UpdateItem |
PATCH /users/{id}/messages/{id} |
SendItem |
POST /users/{id}/sendMail |
SyncFolderItems |
GET /users/{id}/mailFolders/{folderId}/messages/delta |
| Calendar operations | /users/{id}/calendar endpoints |
| Impersonation | Use app-only permissions with consent from admin |
Developing against Graph requires a different authentication model. App registrations in Azure AD must be configured with appropriate Microsoft Graph permissions rather than Exchange permissions. Many ISVs have already transitioned their solutions, but internal tools may need to be rewritten.
Microsoft offers the “EWS to Microsoft Graph migration guide” on Microsoft Learn, with sample code in C#, PowerShell, and JavaScript. For administrators, the primary task is not coding but ensuring all dependencies are inventoried and that vendors are providing Graph-compatible versions.
How to Prepare Your Organization
Time is short. Windows admins should follow this checklist:
- Run the EWS usage report from the Microsoft 365 admin center (Health > Service health > Message center > search for MC834239’s link).
- Audit all applications that appear. Reach out to vendors for update timelines.
- Configure the allow list in a test tenant. Add essential apps that cannot be migrated by October 2026.
- Enable the allow list policy to “enforce” in the test tenant and verify that only listed apps function.
- Begin migration projects for custom code. Move scripts to the Graph PowerShell SDK or REST calls.
- Educate users about potential changes, especially if they rely on custom add-ins.
- Check mobile device access – some older mobile mail apps depend on EWS; switch to Outlook mobile or another Graph-based client.
- Plan for the final cutoff on April 1, 2027. Even allow-listed apps will stop working then, so migration must be completed.
The phased approach buys time, but postponing migration only shrinks the window. Microsoft has stated that no extensions will be granted after April 2027.
Community Reactions and Real-World Concerns
Forum discussions among Windows IT professionals reveal a mix of frustration and cautious acceptance. Many administrators feel the retirement timeline is aggressive, particularly for organizations with hundreds of third-party integrations and limited development resources.
One common pain point is the lack of equivalent operations in Graph. For example, EWS’s GetUserAvailability returns detailed free/busy information, and while Graph has findMeetingTimes, it does not expose all the same nuances. Admins managing complex room booking systems face extra work.
Another concern is monitoring and alerting. Since EWS access will simply fail after the allow list enforcement or full shutdown, admins need proactive monitoring to detect broken integrations before users report them. Microsoft has provided Graph-based activity logs, but integrating those into existing SIEM tools requires effort.
Small businesses that rely on niche third-party tools are particularly vulnerable. Some vendors have a “we’ll update when forced” attitude, leaving customers in limbo. Consequently, admins are being urged to pressure their software providers for concrete migration roadmaps now.
On the positive side, many see the move as long overdue. Graph’s OAuth-only model is more secure, and centralized permissions management in Azure AD simplifies governance. The retirement also forces a cleanup of shadow IT – applications that access mailboxes without IT’s knowledge.
The Clock Is Ticking
Microsoft’s October 2026 allow list deadline is not a suggestion; it is a hard enforcement point. Windows administrators who have not yet begun their EWS exit strategy are already behind. The key takeaways are:
- Now: Start auditing EWS usage and compiling the application inventory.
- Early 2026: Test the allow list in a sandbox. Engage vendors.
- By October 1, 2026: Enable the allow list in production with only essential apps.
- By April 1, 2027: Complete all migrations to Microsoft Graph.
The end of EWS marks a significant shift in how Windows environments interact with Exchange Online. Proactive planning will ensure that the transition is a non-event rather than a service outage. The time to act is now.