Microsoft Exchange Online: Review and configure EWSAllowedAppIDs before Exchange Web Services access changes

🚨 The Signal: Exchange Online will soon require explicit application IDs for EWS access, enhancing security by limiting which applications can use this legacy protocol. This change reduces the attack surface by preventing unauthorized EWS connections.

The Impact

Organizations using EWS are affected; the security risk is service disruption if EWSAllowedAppIDs are not properly configured.

  • Exchange Online administrators: Must identify and list all applications requiring EWS access to prevent service outages.
  • Applications using EWS: May cease to function if not explicitly allowed, impacting business operations.
  • Security teams: Benefit from a reduced attack surface, but must validate EWSAllowedAppIDs configurations.
  • Compliance officers: Can leverage this change to demonstrate stronger application access controls.

The Action

  1. Identify all applications in your environment that currently use Exchange Web Services (EWS).
  2. Review existing EWSAllowedAppIDs configuration using PowerShell: Get-OrganizationConfig | Select-Object EwsAllowedApplicationIds.
  3. Add required application IDs to the EWSAllowedAppIDs list using PowerShell: Set-OrganizationConfig -EwsAllowedApplicationIds @{Add='<AppID1>','<AppID2>'}.
  4. Test EWS-dependent applications to ensure continued functionality after configuration changes.
  5. Consider migrating applications away from EWS to modern APIs where possible before October 2026.

Domain: Exchange · Impact: high · Workload: Exchange Online · Essential Eight: Application Control · ISM: ISM-0843, ISM-1490, ISM-1544, ISM-1582, ISM-1656, ISM-1657, ISM-1658, ISM-1659, ISM-1660, ISM-1870, ISM-1871