Exchange Online EWS Retirement: What Admins Must Do Before October 2026

Microsoft is entering the final phase of retiring Exchange Web Services (EWS) in Exchange Online. Phased, tenant-by-tenant disablement begins on or soon after October 1, 2026, and Microsoft plans to shut EWS down permanently in Exchange Online starting April 1, 2027.

The immediate business risk is not that Exchange Online itself is going away. It is that an older application, add-in, migration utility, archive, scheduling tool, or custom integration may still use EWS behind the scenes. If nobody owns that dependency, a routine-looking Microsoft 365 change can become a broken workflow in October.

There is also a nearer planning point. Microsoft recommends that organizations which still require temporary EWS access configure and test the new application-ID allow list before the end of August 2026. That leaves only a short window to inventory usage, identify owners, and make an intentional decision.

The dates that matter

This schedule applies to Exchange Online in Microsoft 365. Microsoft says the retirement does not change EWS in on-premises Exchange Server.

What changes in October

Microsoft is pairing the existing organization-level EWSEnabled setting with a new tenant-level EWSAllowedAppIDs list. The important outcome is straightforward:

• Tenants that leave EWS in its default, unrestricted state are scheduled to have EWS disabled as Microsoft’s phased rollout reaches them.
• Organizations that temporarily retain EWS must explicitly acknowledge the dependency and limit access to known application IDs.
• After enforcement begins, setting EWS to True without a populated application-ID allow list becomes a block-all configuration.
• The allow list is a transition control, not an extension of support beyond April 2027.

Microsoft may pre-populate an allow list for tenants that have not created one before September, using observed tenant usage. Treat that as a discovery aid—not as proof that every listed application is approved, required, or safe. The tenant administrator still owns validation.

Start with the EWS usage report

The Microsoft 365 admin center now provides an EWS usage report under Reports > Usage > Exchange > EWS usage. It can show:

• The application ID calling EWS
• The EWS SOAP action being used
• Call volume for the selected period
• The application’s last activity date
• Seven-, 30-, or 90-day reporting windows

Microsoft notes that the data is collected and aggregated weekly. Export the report to CSV, but do not stop at the export. An application ID is only the beginning of the investigation.

Turn application IDs into an owned inventory

For every active application ID, document:

• Application and vendor: what product or custom component is making the call?
• Business process: what fails if the integration stops?
• Technical owner: who can test, change, or retire it?
• Data accessed: which mailboxes, calendars, folders, or administrative functions are involved?
• Migration path: supported product update, Microsoft Graph redesign, alternate connector, or retirement?
• Target date: when will EWS use end?

Common places to investigate include line-of-business applications, CRM and ticketing integrations, signature and archive products, room or calendar systems, backup tools, service accounts, older scripts, and custom mailbox automations. Confirm each one from evidence rather than assuming a product still uses EWS because it once did.

Choose the right treatment for each dependency

Microsoft or packaged application

Update the client or service first, then monitor the usage report again. Microsoft says it is removing EWS dependencies from its own products, while many software vendors have already moved or are moving to Microsoft Graph. Ask the vendor for a specific supported version, migration instruction, and date—not a general statement that the product is “Microsoft 365 compatible.”

Custom application

Map the EWS operations to Microsoft Graph and test authentication, permission scope, throttling, notifications, recurrence behavior, and error handling. Microsoft publishes an EWS-to-Graph mapping and calls out remaining parity gaps. A rewrite should begin with the actual SOAP actions in the usage report rather than a broad estimate of the application.

Unknown or apparently dormant application

Do not place it on the allow list simply because it appears. Check the application registration in Microsoft Entra ID, sign-in or audit evidence, vendor documentation, and internal ownership records. If it cannot be tied to a valid process, investigate removal or controlled blocking.

A practical August readiness plan

1. Capture a 90-day baseline

Export the EWS usage report and retain it as the initial inventory. Because the report is weekly aggregated data, compare it with Message Center notices, application logs, Entra enterprise applications, and service-owner knowledge.

2. Assign a decision to every active app

Use four outcomes: migrate now, vendor update, temporarily allow, or retire. Give each item one accountable owner and a dated next action.

3. Build the smallest defensible allow list

Only applications with a confirmed business need and a documented exit plan should receive temporary EWS access. The allow list should not become a parking lot for unknown dependencies.

4. Test before setting the final configuration

Microsoft’s current behavior can enforce a populated allow list before October when EWSEnabled is set to True. Test each approved application and deliberately test one nonapproved application so the team can recognize the expected failure.

5. Create an October response runbook

Document who monitors, what symptoms indicate an EWS block, how to validate the application ID, who can authorize a temporary change, and how the incident will feed the permanent migration plan. A temporary re-enable may be available during the phased period, but it should not replace remediation.

6. Finish before the final cutoff

Set an internal migration deadline comfortably ahead of April 1, 2027. Leave time for vendor delays, Graph parity questions, security review, user acceptance testing, and change control.

Why Microsoft Graph is more than a new endpoint

Moving from EWS to Microsoft Graph is not a one-for-one URL change. Microsoft Graph uses modern REST patterns and offers more granular OAuth permission models than the historically broad access common in EWS integrations. That creates an opportunity to reduce mailbox reach, remove stale application permissions, and document exactly why an integration needs access.

Use the migration to improve the control model:

• Request only the permissions the application needs
• Separate interactive and application-only scenarios
• Use certificates or managed identities where the architecture supports them
• Establish an owner and review date for every enterprise application
• Monitor failed calls, throttling, consent changes, and credential expiration

Frequently Asked Questions

Does this mean Exchange Online is shutting down? No. Microsoft is retiring the EWS integration interface in Exchange Online, not the Exchange Online service.

Does this affect on-premises Exchange Server? Microsoft says no. The announced EWS retirement applies to Exchange Online.

Can we keep EWS by using the allow list? Only temporarily. EWSAllowedAppIDs is designed to control the transition; Microsoft plans a permanent Exchange Online shutdown starting April 1, 2027.

What if the usage report is empty? Recheck the 90-day window, confirm reporting permissions, review Message Center notices, and validate important applications with their owners. An empty view is encouraging, but it should not be the only evidence used for a critical integration.

What should we do first? Export the EWS usage report, identify the owner and business function behind every application ID, and schedule decisions before the end of August.