AzureFeeds

Exchange Web Services (EWS) retirement in Exchange Online is entering its final phase. Over the last several years, Microsoft has worked with product teams, independent software vendors (ISVs), and customers across the ecosystem to migrate workloads to Microsoft Graph and other modern APIs. Many of those migrations are complete, and many others are well underway.

As phased EWS disablement in Exchange Online approaches in October 2026, we are introducing a new capability to help administrators prepare in a controlled and predictable way: EWSAllowedAppIDs. This is the Allow List functionality that we mentioned in Exchange Online EWS, Your Time is Almost Up | Microsoft Community Hub.

EWSAllowedAppIDs gives administrators a practical way to identify remaining dependencies, limit EWS access to approved applications, and reduce the risk of disruption as retirement enforcement begins.

This feature is starting to roll out now. All tenants should be able to view the parameter when running Get-OrganizationConfig, but they won’t be able to set the list until the roll out reaches the tenant.

What is EWSAllowedAppIDs?

EWSAllowedAppIDs is a tenant-level allow list that lets Exchange Online administrators explicitly define which applications are still permitted to access EWS, based on their App ID.

When configured, only applications whose App IDs appear in the allow list can continue using EWS in the tenant when EWSEnabled at the tenant level is set to True.

This feature is designed to support the final transition away from broad, unrestricted EWS access and toward tightly scoped, intentional usage during the retirement window.

Note: The EWSAllowList feature Exchange has had for many years is based on User Agent, not App ID. Both can work together, but they operate on different aspects of the calling application.

Administrators can use the feature to:

• Identify which applications still require EWS


• Restrict EWS access to only approved applications


• Prepare for the final retirement of EWS in Exchange Online

How EWSAllowedAppIDs fits into the EWS endgame

We previously announced that phased EWS disablement in Exchange Online will begin in October 2026.

To understand why EWSAllowedAppIDs matters, it helps to look at how Exchange Online behavior changes before and after that date. The retirement model uses the existing EWSEnabled organization-level setting together with the new EWSAllowedAppIDs allow list. (Refresh yourself on how the EWSEnabled switch works and how to set it here)

Before October 2026, the behavior is intentionally permissive to give customers time to inventory dependencies, deploy an allow list, and validate which applications still require EWS.

Before October 2026

This pre-October phase gives administrators room to deploy and test an allow list without immediately breaking existing applications.

What changes in October 2026

Beginning in October 2026, Exchange Online starts transitioning tenants into retirement enforcement behavior.

At that point, enabling EWS without configuring an allow list will no longer act as an unrestricted “allow everything” mode.

Starting October 2026

This is the most important behavioral change administrators need to understand: after enforcement begins, setting EWSEnabled=True without an allow list effectively becomes a block-all configuration.

This change is intentional. The goal is not to keep EWS available indefinitely, but to require explicit acknowledgement that EWS is still needed and to scope that usage down to known, approved applications.

The goal of the retirement process is not simply to keep EWS “on” indefinitely, but to:

1. Force explicit acknowledgement that EWS is still required


2. Scope usage down to known, approved applications


3. Accelerate migration to Microsoft Graph and modern APIs

What happens if a tenant admin does nothing?

Today, many tenants still have EWSEnabled unset (Null), which behaves as unrestricted access.

As the phased retirement rollout starts in October 2026, those tenants will have EWS disabled (EWSEnabled set to False) as part of the staged shutdown process.

Administrators who still require EWS at that point will need to take explicit action.

The recommended path is:

1. Configure or validate the EWSAllowedAppIDs allow list (remember, we said we would populate this for tenants who have not done so in September – read more here – but the admin owns ensuring it’s correct).


2. Set EWSEnabled=True

Customers who complete this work proactively will be significantly less likely to experience disruption during the broader retirement rollout.

Why we strongly recommend enabling this feature now

Customers should not think of EWSAllowedAppIDs as a feature intended only for October 2026. Its greatest value is in the preparation period before enforcement begins.

Deploying and validating the allow list now gives administrators time to find unknown dependencies, remove obsolete applications, engage vendors that still rely on EWS, and begin migrations to Microsoft Graph.

• Discover unknown EWS dependencies


• Remove obsolete applications


• Contact vendors still requiring EWS


• Begin migrations to Graph APIs


• Validate which applications truly still require exceptions


• Reduce future support escalations and outages

Administrators who wait until they are already impacted by phased disablement will have a much smaller remediation window and a significantly higher likelihood of disruption.

Recommended next steps for administrators

We strongly recommend that Exchange Online administrators begin this work now:

Inventory EWS usage

Identify all applications and services currently using EWS in your organization. Use EWS usage reports where available in your tenant, and review Message Center posts that summarize tenant usage. Please see Notes From the Field: Finding and Remediating EWS App Usage Before Retirement | Microsoft Community Hub.

Build an allow list

Create an EWSAllowedAppIDs allow list containing only applications that are known to still require EWS.

If an administrator already knows which applications they want to permit, they can create a new allow list directly by specifying one or more App IDs.

For example:

Set-OrganizationConfig -EwsAllowedAppIDs “11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee”

This replaces the current value with the specified set of allowed applications.

After setting the value, administrators can confirm the configured list using:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

The use of “RetrieveEwsOperationAccessPolicy” is required for performance reasons – we only want to retrieve this list if the admin explicitly asks for it.

Administrators should be aware that setting the property writes the full list value. If the property already contains App IDs, they will be replaced unless included in the new command. See more below on this.

Test thoroughly

Validate that all applications on your allow list continue to work as expected, and check for any missed dependencies. If you need to add or remove an App ID, you must read the current list, compute the updated list, and then write the full value back. Today, this cmdlet does not support incremental add or remove operations.

Here are two examples that show how to update the list:

Example: add a new App ID

The common pattern is to read the current list, append the new App ID, and then write the full combined list back.

# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the new App ID to add
$newAppId = “99999999-8888-7777-6666-555555555555”
# Combine existing and new values
$updated = @($current, $newAppId)
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join “,”)

Example: remove an App ID

Because there is no single-item removal operation today, removal also requires recomputing the full list.

# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the App ID to remove
$removeAppId = “99999999-8888-7777-6666-555555555555”
# Split the comma-separated list into individual App IDs
$appIds = $current -split “,”
# Remove the specified App ID
$updated = $appIds | Where-Object { $_ -ne $removeAppId }
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join “,”)

The bigger picture

EWS served the Exchange ecosystem for nearly two decades.

However, modern requirements for security, reliability, compliance, and scale call for a more modern API platform. Microsoft Graph is the long-term strategic platform for most Exchange Online integration scenarios.

EWSAllowedAppIDs is designed to make the final transition manageable and predictable while still encouraging rapid migration off EWS.

Organizations that prepare early will navigate this transition most smoothly. Administrators who inventory dependencies now and validate their allow lists well before October 2026 will be far better positioned to avoid disruption as phased retirement begins.

The time to prepare is now.

For the latest on the overall plan, status on parity gaps and links to resources, please check the Deprecation of Exchange Web Services in Exchange Online page.

The Exchange Team