Start with steps 1 and 2 to see where your tenant stands. Step 3 then sends you down one of two routes, depending on what step 2 reported:

If you still have the choice, take route 2: provided the allow list is complete, applying it changes nothing for your users.

1. Connect to Exchange Online PowerShell

Install the module and sign in as an administrator, following Connect to Exchange Online PowerShell.

Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser   # first time only
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName  <your-admin-upn>        # for example, admin@contoso.onmicrosoft.com

Replace <your-admin-upn>, including the angle brackets, with the full sign-in address of an account that holds the Exchange Administrator or Global Administrator role.

2. Check the current state of your tenant

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled, EwsAllowedAppIDs

Note the two values you are about to change. On most tenants EwsEnabled is blank (not configured) and EwsAllowedAppIDs is empty. If EwsAllowedAppIDs already contains application IDs, write them down — step 5 needs them. If EwsEnabled already shows False, the rollout has reached your tenant and EWS is currently blocked for everything; step 3 tells you what to do next.

3. Take route 1 or route 2:

Route 1 — the rollout has already reached you. Step 2 showed EwsEnabled as False and your users have stopped receiving Secure Mail notifications. The quickest way to restore the service is to set the value back to $null, which re-enables EWS without restrictions:

Set-OrganizationConfig -EwsEnabled $null

EwsAllowedAppIDs is ignored while the setting is $null, so no allow list is needed and you can skip steps 4 to 7. This holds until the final deprecation in April 2027, when EWS is switched off regardless of either setting. Note that it re-enables EWS for every application in the tenant, which is a wider exposure than an allow list; if you would rather keep EWS restricted to known applications, use steps 4 to 6 instead.

Route 2 — EWS is still working in your tenant. If you would rather notifications carried on uninterrupted, leave the setting as it is and continue with step 4.

4. Identify every application that uses EWS:

Open the EWS weekly usage report in the Microsoft 365 admin center under Reports > Usage, and note the application ID of everything that has to keep working. The Exchange Team Blog article Notes From the Field: Finding and Remediating EWS App Usage Before Retirement describes the process in more detail.

The report covers a rolling week, so an application that only runs monthly might not appear in it. Check with your application owners as well. Step 7 covers what to do if one turns up later.

5. Apply the allow list and enable EWS

Your list must contain 38e08503-850d-436a-843a-b4f0b9913a19, which is Secure Mail's own application ID, plus every ID from step 4. If you have set the CustomClientIdForOAuth MDX policy for Secure Mail, the app authenticates with that application ID instead, so add it as well — otherwise Secure Mail remains blocked even though the ID above is present. You can check the policy in the Endpoint Management console under Configure > Apps > Secure Mail.

If step 2 showed application IDs already in EwsAllowedAppIDs, include those as well. They were added for a reason, and they may cover an application that the weekly usage report missed. Set-OrganizationConfig replaces the entire list rather than appending to it, so any ID you leave out is dropped.

Set both values in a single command, so there is no moment in which EWS is enabled without a list:

Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs '38e08503-850d-436a-843a-b4f0b9913a19,'

The parameter takes one comma-separated string, not a list, so every ID goes inside the same pair of quotes, separated by commas and with no spaces. Replace  with the IDs you collected, or delete it — along with the comma before it — if Secure Mail is the only application that needs EWS. Check the command before you run it: the list you type is the list that ends up in force.

6. Confirm the settings

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled, EwsAllowedAppIDs

Changes take time to apply across the service, so allow up to a couple of hours before testing, then confirm with a user that notifications have returned.

7. If an application stops working

An application that was missed in step 4 is blocked as soon as the list takes effect. Find its application ID, add it to your list, and run the step 5 command again. The command replaces the whole list every time, so the corrected list has to include everything that was already in it as well as the ID you are adding