Microsoft has confirmed that Exchange Online will start blocking Exchange Web Services (EWS) requests from non-Microsoft applications on October 1, 2026, marking the beginning of the end for a protocol that has powered email integrations for over a decade. The move is part of a phased retirement that will conclude in April 2027, forcing any organization using third-party or custom EWS-based apps to migrate to Microsoft Graph or lose access.

The New Deadline

In a direct update to its 2018 announcement that EWS would no longer receive feature updates, Microsoft now says it will actively block traffic. Starting October 1, 2026, any app not published by Microsoft will find its EWS requests rejected. Microsoft’s own clients—Outlook for Windows, Mac, Teams, and others—are exempt. EWS on Exchange Server is unaffected; this applies only to Exchange Online and Microsoft 365 environments.

The retirement is not a single flick of a switch. Microsoft plans a tenant‑by‑tenant rollout, meaning some tenants will be blocked earlier than others within that final window. The company also says that if an administrator hasn’t created an allow‑list by September 2026, it will automatically populate an EWSAllowedAppIDs list based on observed activity. That sounds reassuring, but it is a double‑edged sword: the list may include abandoned scripts, unapproved vendor tools, or apps whose owners have left the organization.

Who’s Affected—and Who Isn’t

Home Users and Small Businesses

If you rely only on Outlook, the built‑in Mail app, or the web version of Outlook, you will not notice any difference. The change targets programmatic access, not human‑driven email clients. However, if you use a niche third‑party mail app, a legacy email‑archiving tool, or a home‑grown script to pull mail into a spreadsheet, that might break. Check with your software vendor or, if you built it yourself, start planning a move to Microsoft Graph.

IT Administrators and Enterprise Teams

The bulk of the work lands on Exchange Online admins. Every production tenant must identify which applications are using EWS, validate whether they still have a valid business reason to exist, and decide whether to migrate them or retire them. Microsoft provides tenant‑specific usage reports via the Message Center—look for a message titled “Active Exchange Web Services applications.” That report lists application names and AppIDs. But a name on a report is not proof of authorization. Many admins have discovered that tying an AppID back to a real‑world owner can be the hardest part.

A phased retirement also means your migration timeline isn’t infinite. Even after October 2026, you may be able to request temporary exceptions for critical apps while you finish Graph migrations. But those exceptions will have expiration dates, and Microsoft has made no promise that exceptions will be granted for all requests.

Developers

If you build or maintain an application that connects to Exchange Online mailboxes, calendars, or contacts via EWS, you need to re‑platform to Microsoft Graph. Microsoft’s own SDKs for Java and .NET are also being retired alongside EWS. The Graph API offers more modern authentication through Microsoft Entra, finer‑grained permissions, and access to a much broader set of Microsoft 365 data. However, known feature gaps persist: access to archive mailboxes, public folders, and certain Exchange‑specific management operations aren’t fully available yet. Microsoft says it is working on closing these gaps, with updated timelines promised “in the coming months.”

Why EWS Is Going Away

Exchange Web Services has been the backbone of Exchange programmatic access since Exchange 2007. It replaced earlier protocols like WebDAV and Exchange Web Services Managed API, offering SOAP‑based calls that were simpler than MAPI. But as cloud services evolved, Microsoft shifted its developer platform to Microsoft Graph, a unified REST API that spans not just email but also Teams, SharePoint, OneDrive, and more. EWS ceased receiving feature updates in 2018, and since then, all new capabilities have been Graph‑only.

Security and maintainability are the driving forces. EWS relies on legacy authentication patterns that are harder to monitor and protect in a zero‑trust world. Microsoft Graph, by contrast, integrates with conditional access, multi‑factor authentication, and continuous access evaluation. By forcing the migration, Microsoft can retire an aging infrastructure and focus investment on a single, secure API surface.

How to Prepare: An Action Plan

The following steps distill guidance from Microsoft’s announcements and from the community of administrators already working through the transition. The goal is not merely to collect AppIDs but to arrive at October 2026 with a clean, documented application register where every remaining dependency is known, owned, and on a path away from EWS.

1. Inventory Every EWS Application

Open the Microsoft 365 admin center, go to Health → Message Center, and locate the tenant‑specific report titled “Active Exchange Web Services applications.” Export or record every listed AppID and application name. Keep a copy of the original report and every subsequent update; do not discard older versions. An AppID that appears in one report but not another may still be active on a quarterly or annual schedule, so one snapshot is never enough.

2. Build an Evidence‑Backed Register

For each AppID, create a row in a controlled spreadsheet or configuration‑management database. Essential columns should include:
- AppID (GUID)
- Display name from report
- First and last report dates
- Owner (business and technical)
- Authentication pattern (delegated, application‑only, etc.)
- Affected mailboxes or workflows
- Replacement technology
- Migration or exception expiration date

Initially mark every row “Unverified.” The fact that an AppID appears in Microsoft’s report proves activity, not business necessity or organizational approval.

3. Correlate with Microsoft Entra

Use the Microsoft Entra admin center to look up each AppID in the sign‑in logs. Locate the corresponding enterprise application or service principal, and record its object ID, publisher, and assigned owners. If your organization registered the application, inspect the app registration for permissions and secrets. A PowerShell oneliner can speed the lookup: Get-MgServicePrincipal -Filter "appId eq '<appId>'". But if the Graph call returns nothing, do not assume the AppID is safe to delete—the identity may be provisioned through a different tenant or a multi‑tenant arrangement.

4. Validate Every Dependency

For each application, answer these six questions before you consider an exception:
- What is it? (product, workload, publisher)
- Who owns it? (named person or team)
- Why does it need EWS? (specific transaction)
- What breaks if blocked? (user‑visible failure)
- How was it tested? (end‑to‑end transaction recorded)
- When will the exception end? (migration or retirement date)

Only after all six are answered should you classify the row as an “Approved temporary exception.” Everything else is either a “Migration candidate,” an “Unknown shadow dependency,” or “Retired/unauthorized.”

5. Run a Controlled Pilot

Before October 2026, Microsoft will make an EWSAllowedAppIDs parameter available in Exchange Online PowerShell. Once it ships, do not immediately enforce the list in production. In a test tenant (or with extreme caution in production), add your approved AppIDs, verify that they still work, and confirm that everything not listed is indeed blocked. Make sure you can roll back: capture Get-OrganizationConfig before any change and know the exact command to restore the original state. Microsoft’s documentation states that an empty customer‑created list will be overridden by its own automated fallback, so leaving the list blank is not a safe “block everything” strategy.

6. Plan for the Road Ahead

For every application that stays on EWS—even temporarily—set a firm exit date. Work with vendors to get written confirmation of which product releases remove EWS dependency. For home‑grown code, search your repositories for outlook.office365.com/EWS or Exchange.asmx to find hidden references. The migration target is not always Microsoft Graph; some solutions may require a different architecture entirely. By October 1, 2026, your aim should be a register where every retained AppID has a designated owner, a documented business purpose, and a clear expiration path, while every unknown entry remains an open investigation, not a rubber‑stamped approval.

The Road Ahead

Microsoft’s staggered blocking schedule gives larger organizations some breathing room, but the final curtain falls in April 2027. In the interim, keep a close watch on Message Center posts and on the “What’s new in Microsoft Graph” page. The company has committed to closing high‑priority feature gaps—archive mailboxes, folder‑associated information, Exchange Online management—though timelines are still vague. Without those pieces, some migrations will be incomplete, forcing hard decisions about whether to retire a business function or seek an alternative product.

The key takeaway is that the October 2026 deadline is not far off. Starting now, building an accurate application register, and testing Graph equivalents will make the cutover manageable rather than a fire drill. The automated fallback list is a safety net, not a strategy. By taking ownership of the EWSAllowedAppIDs configuration before Microsoft fills it blindly, you control what stays connected and what gets left behind.