Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement

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 AppID 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 AppID 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 AppID 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 (and it applies to REST/Graph not just EWS by the way). 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 AppID allow list, and validate which applications still require EWS.

Before October 2026

This pre-October phase gives administrators room to deploy and test an AppID 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 AppID 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 AppID 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 – 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 AppID 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 AppID allow list

Create an EWSAllowedAppIDs allow list containing only applications that are known to still require EWS. This includes Microsoft first-party client apps such as Office, Power Query for Excel etc. If the app shows up in your usage report, and you want to keep using it, you need to add it to the list. 

If an administrator already knows which applications they want to permit, they can create a new AppID 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. 

Changes to this list can take up to 24 hours to take effect. Again, for performance reasons, servers only refresh their in-memory cache once every 24 hours. 

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 AppID 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 AppID 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.

AppID Allow List FAQs

Can we set EWSEnabled=True in August without creating our own AppID Allow List?
Yes, but we’d rather your tenant admin creates it, to ensure it’s exactly meeting your needs. We will be populating AppID Allow Lists for our customers automatically (based on each tenant’s usage). If you only set EWSEnabled=True in August and we will populate your AppID Allow List for you, we might also include apps in there you weren’t aware of (if they show usage). We recommend that admins create their own AppID Allow Lists to control exactly which EWS applications they want to allow after October 2026. See Take control of your EWSAllowedAppIDs list before EWS access changes | Microsoft Community Hub for more information.

If we create our own AppID Allow List, will Microsoft change it during automatic AppID Allow List processing for all tenants?
No. If you create your own AppID Allow List, our automated process will not change your already created AppID Allow Lists. Your AppID Allow List will stay unchanged.

If Microsoft auto-populates the list in for a tenant, can an administrator manually overwrite or append to that list via PowerShell afterward?
Yes, Administrators will be able to change the content of AppID Allow List.

What about the EWSAllowList setting? Should we add application IDs there?
EWSAllowList and EWSBlockList settings are related to the EwsApplicationAccessPolicy feature that has existed for long time. This is not related to EWS deprecation in Exchange Online. EwsApplicationAccessPolicy is an older EWS application access control feature and requires USER AGENTS instead of AppIDs. Modifying EwsApplicationAccessPolicy simply adds additional "gate" a client application needs to pass to connect to Exchange Online, and application can pass it only after it has passed the AppID Allow List mentioned above. So, if you start to use this with EWSAllowedAppIDs, both the App ID and the correct User Agent for the request must both pass their individual logic, otherwise the request will be denied due to EWS being blocked.

What about on-prem Exchange, and hybrid scenarios?
EWS is not being retired on-prem. Hybrid scenarios vary depending on how apps access data. On-prem mailboxes may continue using EWS; cloud mailboxes must move to Graph access. Autodiscover will help apps determine mailbox location automatically. But note that only Exchange SE supports Graph for rich coexistence calls to Exchange Online starting with May 2026 update, so hybrid customers must use Exchange SE to host on-premises mailboxes after April 2027. Between October 2026 and April 2027, customers also have an option to enabling EWS on their Exchange Online tenant and adding their dedicated hybrid app into EWSAllowedAppIDs which will allow rich coexistence using EWS to continue working.

 

Updates to this blog post:

• 9/22/2026: Added a FAQ pair about impact of EWSAllowedAppIDs on Exchange hybrid scenarios.
• 9/4/2026: Modified the FAQ and text to reflect the timing that we have published about when Microsoft will create the AppID allow list for tenants who have not done so yet. See Take control of your EWSAllowedAppIDs list before EWS access changes | Microsoft Community Hub.
• 9/1/2026: Added FAQs related to AppID Allow List / EWSAllowedAppIDs property.
• 9/1/2026: Clarified all mentions of "Allow list" to be "AppID Allow List" (the allow list that takes Application IDs, as opposed to user agent strings used by EwsApplicationAccessPolicy and it's EWSAllowList setting).
• 8/14/2026: Updated the Allow List table to specify what happens when EWSEnabled = True and Allow List is populated.
• 8/7/2026: Added a link to Cross-tenant Free/Busy, MailTips, and Calendar Sharing are moving to Cross-Tenant Access Policy | Microsoft Community Hub related to Org Relationship announcement in MC1447678.
• 8/6/2026: Added a mention of Organization Relationships and that that EWS traffic is not related to or blocked by the state of Allow List (related to MC1447678).

The Exchange Team