Microsoft is putting the final piece in place for the long-announced retirement of Exchange Web Services (EWS) in Exchange Online. In June 2026, the company will deploy a new control called EWSAllowedAppIDs, giving tenant administrators a precise whitelist mechanism to lock down EWS access to specific application IDs before the service is permanently disabled in October 2026.

The move is the last major milestone in a multi-year effort to push organizations off the legacy SOAP-based API and onto Microsoft Graph. Since the initial deprecation announcement in 2022, Microsoft has steadily tightened the screws: first blocking new tenants from using EWS, then disabling it for unused tenants, and now—with EWSAllowedAppIDs—handing admins a surgical instrument to control exactly which applications can still make EWS requests during the final months.

The Breaking Point: EWS Deprecation Is Real

Exchange Web Services has been the backbone of programmatic access to Exchange mailboxes for nearly two decades. Countless third-party applications, line-of-business integrations, and custom scripts rely on EWS to read mail, manage calendars, and perform administrative tasks. But Microsoft has declared that the sunset is irreversible. After October 1, 2026, EWS requests to Exchange Online will fail unless they originate from an application ID explicitly allowed in the tenant’s configuration.

That’s not a soft deadline. Microsoft has been unambiguous: on that date, the EWS endpoint will no longer accept calls from unlisted apps, and any remaining functionality will be cut off. The company has used the same playbook before—deprecating basic authentication, retiring older Outlook versions—and each time, organizations that waited until the last minute faced service disruptions.

What Is EWSAllowedAppIDs?

EWSAllowedAppIDs is a new parameter in the Exchange Online Organization Configuration, introduced via PowerShell. It lets administrators define an allow list of Azure AD application IDs (client IDs) that are still permitted to use EWS. Instead of a blanket on/off switch, admins can now specify a comma-separated list of GUIDs, each representing an app registered in Azure AD that may need EWS access during the transition.

Critically, the control works in tandem with the existing EWSBlockLevel setting. While EWSBlockLevel has long allowed tenants to block all EWS traffic or restrict it to certain protocol components, EWSAllowedAppIDs adds identity-level granularity. Think of it as an API key firewall: if your app’s ID isn’t on the list, the request won’t even reach the backend.

The Timeline: June to October 2026

The rollout is deliberately compressed:
- June 2026: EWSAllowedAppIDs becomes available in all Exchange Online tenants. Admins can immediately begin whitelisting application IDs.
- June–September 2026: Microsoft recommends testing EWS requests with the allow list enabled, monitoring for failures, and migrating apps to Microsoft Graph.
- October 1, 2026: The EWS service enters an enforcement phase. Applications not on the allow list will receive HTTP 403 Forbidden responses or equivalent errors. Microsoft may also begin throttling or rejecting non-compliant requests earlier in some environments to encourage compliance.

This schedule is tighter than many admins had hoped. Previous communications suggested a more gradual wind-down, but the June 2026 tooling drop means organizations will have less than four months to complete critical migrations once the whitelist feature lands.

How to Use the New Control

Administrators will manage EWSAllowedAppIDs through Exchange Online PowerShell. The parameter sits on the Set-OrganizationConfig cmdlet and accepts an array of application IDs.

To enable the allow list, an admin connects to Exchange Online and runs:

Set-OrganizationConfig -EWSAllowedAppIDs @("00000000-0000-0000-0000-000000000001", "00000000-0000-0000-0000-000000000002")

Each string must be a valid Azure AD application (client) ID, typically found in the Azure portal under App registrations. To view the current list, use:

Get-OrganizationConfig | Select-Object EWSAllowedAppIDs

To clear the list and revert to a completely locked-down state, run:

Set-OrganizationConfig -EWSAllowedAppIDs $null

Microsoft cautions that modifying the list has immediate effect. Adding or removing an ID should be tested in a non-production tenant first. Once the October deadline hits, any app not on the list—including those that may have been working for months—will abruptly stop functioning.

Impact on Applications and Migrations

The introduction of EWSAllowedAppIDs forces a hard conversation for many IT departments. Countless homegrown scripts and third-party tools that have never been modernized will need to be identified, catalogued, and either retired or migrated to Microsoft Graph. The problem is acute in organizations that have undergone mergers, have high developer turnover, or lack centralized application governance.

Even Microsoft’s own first-party apps are not exempt. The Outlook for Mac EWS support, for example, will need to be explicitly allowed if it remains in use after October 2026—though Microsoft has been pushing users to the newer REST-based sync. Similarly, any application using the old EWS Managed API or the raw SOAP endpoint must either be rewritten to call Graph APIs or its application ID added to the allow list, at least temporarily.

Microsoft’s guidance is unequivocal: the EWSAllowedAppIDs allow list is a last resort, not a long-term solution. The company expects organizations to use it only for a limited set of apps that cannot be migrated in time, while all other EWS calls should be redirected to the Microsoft Graph endpoints long before the deadline.

What IT Admins Should Do Now

Even though the feature isn’t available until June 2026, immediate action is necessary:

  • Inventory EWS usage: Use Azure AD sign-in logs, Exchange audit logs, and application monitoring to discover which apps and services are making EWS requests. Many organizations will be surprised by the number of forgotten scripts running in the background.
  • Identify application owners: For each app, determine whether it’s in-house or third-party, and whether a migration path exists. Contact vendors to confirm their planned support for Microsoft Graph.
  • Begin Graph migration pilots: For custom applications, start rewriting code to use the Microsoft Graph mail, calendar, and contacts APIs. The Graph SDKs are mature, and Microsoft provides migration guides and sample code.
  • Plan for the June configuration window: Design a governance process for adding application IDs to the allow list. Decide who will have permission to modify the list and under what circumstances new apps will be whitelisted.
  • Test with EWSBlockLevel: Before EWSAllowedAppIDs arrives, use the existing EWSBlockLevel parameter to simulate a hard block. Set it to EwsOnly or EwsAndRest in a test tenant to see which apps break.

A Final Tightening

Microsoft’s aggresive timeline underscores a broader strategic shift. The company has been systematically closing off legacy endpoints—basic authentication, Exchange ActiveSync for untrusted devices, and now EWS—to reduce the attack surface and force adoption of modern, token-based authentication. The EWSAllowedAppIDs control is, in many ways, the final safety net before the old bridge collapses entirely.

For admins who have already moved to Graph, the June rollout will be a non-event. For everyone else, it’s a four-month scramble that will demand coordination across development, operations, and security teams. The message from Redmond is clear: start planning now, or risk waking up on October 2, 2026, to a flood of broken integrations.