EWS returns 403 in Exchange Online: causes and fixes
An application that worked for years suddenly gets 403 Forbidden from EWS, although the account is active and the client secret has not expired. In Exchange Online four settings answer that way, and you can check all four in Exchange Online PowerShell.
What the application sees
The HTTP status is 403 and there is no EWS response to read. Code built on the EWS Managed API gets a ServiceRequestException:
Microsoft.Exchange.WebServices.Data.ServiceRequestException:
The request failed. The remote server returned an error: (403) Forbidden.A 401 is a different problem: the token or the credentials were refused. So is an EWS error inside a normal response, such as ErrorAccessDenied or ErrorImpersonateUserDenied: there EWS answered, and the application lacks a permission.
The four settings that answer 403
| Setting | Where | Blocks |
|---|---|---|
EwsEnabled is False | the organization | every application |
EwsAllowedAppIDs does not contain the application | the organization | that application, from October 10, 2026 when EwsEnabled is True |
EwsEnabled is False | one mailbox | every application that opens that mailbox |
EwsApplicationAccessPolicy with EwsAllowList or EwsBlockList | the organization or one mailbox | applications by their user agent string |
The first two belong to the EWS retirement. The last two are older settings that some tenants have used for years. They still apply, and a request has to pass all of them: EWS works only when both the organization and the mailbox allow it, and Microsoft states that the application ID list and the user agent lists are both checked on every connection.
Check the organization
Connect-ExchangeOnline
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled, EwsAllowedAppIDs
Get-OrganizationConfig | Format-List EwsApplicationAccessPolicy, EwsAllowList, EwsBlockListWithout -RetrieveEwsOperationAccessPolicy the allow list is not returned and looks empty.
EwsEnabledis False: EWS is off for the whole tenant. Either an administrator set it, or Microsoft did in the second phase of the retirement, after a 7-day warning in Message Center.EwsEnabledis True and the list lacks the application: from October 10, 2026 that application gets 403 while the listed ones keep working.EwsEnabledis empty: the tenant has not been switched yet and EWS still works for every application. A 403 then comes from one of the two older settings.
Check the mailbox
When one mailbox fails and another works with the same application, look at the mailbox:
Get-CASMailbox -Identity [email protected] | Format-List EwsEnabled, EwsApplicationAccessPolicy, EwsAllowList, EwsBlockListA mailbox can have EWS switched off on its own, or carry its own allow or block list of user agents. The EWS Managed API sends a user agent that starts with ExchangeServicesClient unless the application sets ExchangeService.UserAgent.
According to Microsoft’s documentation, the user agent lists also apply to connections through Microsoft Graph, so an application that has moved to Graph can still be blocked by them. The application ID list applies to EWS only.
Another common cause is a recent change that has not applied yet. Microsoft gives up to 24 hours for a change to the list of application IDs, and usually under an hour, at most four, for EwsEnabled.
Find the application ID
The allow list holds application (client) IDs from Microsoft Entra ID. For your own application it is on the Overview page of its app registration. For a product you bought, ask the vendor. The guide to the app list covers IDs that nobody recognizes.
The fix, and how long it lasts
An administrator can turn EWS back on for named applications:
Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "<app ID 1>,<app ID 2>"The command stores the whole list, so include every ID that should stay on it. Then wait for the change to apply before testing again.
This works until April 1, 2027. On that day Microsoft switches EWS off in Exchange Online for good, the setting goes away, and the 403 stays. The dates are in the retirement guide.
After the fix
The application runs again until April 1, 2027. What happens next depends on whose application it is:
- A product you bought: ask the vendor for the Microsoft Graph version.
- Your own .NET code on the EWS Managed API: rewrite it for Microsoft Graph, or keep the code and swap the package for Sunsetless EWS, which sends the same calls to Microsoft Graph. A free trial key runs it in your tenant for 14 days.
- Anything else you wrote: rewrite it for Microsoft Graph.