Exchange Online EWS Retirement: October 2026

Exchange Web Services is entering its final retirement phase in Exchange Online. Microsoft says phased disablement starts in October 2026 and EWS will be fully disabled in April 2027.

That does not mean every tenant stops on the same day in October. It does mean waiting for a failed application is now a poor migration strategy.

The practical job is to find the remaining EWS traffic, work out which business process creates it, and get a dated answer from the application owner or supplier.

Quick answer

Before October 2026:

1. Export the Exchange Online EWS usage report for the last 90 days.
2. Map each application ID to an owner, supplier and business process.
3. Remove obsolete dependencies and test supported replacements.
4. Use EWSAllowedAppIDs only as a controlled transition measure.
5. Keep evidence showing what was tested and who accepted any remaining exception.

An allow list is not a permanent alternative to migration. Microsoft describes Microsoft Graph as the long-term platform for most Exchange Online integration scenarios.

What actually changes

Microsoft has introduced a tenant-level EWSAllowedAppIDs list. It works with the organisation-level EWSEnabled setting and allows only named application IDs to use EWS.

The important behaviour changes when retirement enforcement begins:

The easily missed case is EWSEnabled=True with an empty list. Once enforcement applies, that becomes block-all, not allow-all.

Microsoft also warns that writing EWSAllowedAppIDs replaces the full current value. Administrators need to read the existing list, calculate the complete new list, then write it back. Treat that as a controlled change with before-and-after evidence.

Find the dependencies first

The EWS usage report is in the Microsoft 365 admin centre under Reports, Usage, Exchange, EWS usage. It can show 7, 30 or 90 days and is aggregated weekly.

Export the 90-day view. It includes:

• application ID
• SOAP action
• call volume
• last activity date in UTC

Do not stop at the application ID. A useful inventory explains what breaks if that app stops.

If the report shows an unfamiliar ID, check Enterprise Applications in Microsoft Entra ID. Also review the relevant Microsoft 365 Message Center posts because Microsoft is sending tenant-specific usage information.

Questions to send suppliers

Avoid asking only, "Do you support modern authentication?" That can produce a technically true but useless answer.

Ask instead:

1. Does the current version of your product call Exchange Online through EWS?
2. Which application ID should appear in our tenant report?
3. Which supported version removes the EWS dependency?
4. What replacement API or integration method does it use?
5. What functions change during migration?
6. What is your tested release date before October 2026?
7. If an exception is required, when will it no longer be required?

Keep the response with the change record. A sales assurance without a version number and date is not migration evidence.

A safe test sequence

Start with discovery, not a tenant-wide switch.

1. Take a fresh usage export and record current organisation settings.
2. Identify a low-risk application with a known owner.
3. Confirm its application ID from more than its display name.
4. Test the replacement in a non-critical mailbox or controlled user group.
5. Verify the full workflow, including calendar recurrence, delegated mailboxes, archives or service accounts where relevant.
6. Recheck EWS usage after the test window.
7. Add only approved temporary dependencies to the allow list.
8. Schedule a second review before phased disablement begins.

Some EWS scenarios still have Microsoft Graph parity work in progress. That makes early testing more important, not less. A genuine feature gap needs an owned exception and migration plan; it should not become a reason to leave all EWS access unrestricted.

Evidence to keep

A compact retirement pack should include:

• dated 90-day EWS usage export
• current EWSEnabled and EWSAllowedAppIDs state
• application-to-owner inventory
• supplier responses with product versions and dates
• test results for replacements
• approved exceptions and expiry dates
• final validation showing obsolete EWS traffic has stopped

This is enough to explain the risk to leadership and enough for an engineer to resume the work without repeating discovery.

Related route

If the EWS inventory exposes stale enterprise apps, broad permissions or ownerless integrations, fold the work into a wider Microsoft 365 security clean-up.

References

• Microsoft Learn: Deprecation of Exchange Web Services in Exchange Online
• Microsoft Learn: Exchange Web Services usage report
• Microsoft Exchange Team: Introducing EWSAllowedAppIDs