Prepare for Exchange Web Services Retirement with EWSAllowedAppIDs
Microsoft is entering the final phase of retiring Exchange Web Services (EWS) in Exchange Online. Organizations that still rely on EWS-based applications must act now to identify dependencies, control access, and accelerate migration to Microsoft Graph. One of the most important new controls introduced by Microsoft is EWSAllowedAppIDs, a feature designed to help administrators manage the transition safely and predictably.
Understanding the EWS Retirement Timeline
Exchange Web Services has been a cornerstone API for many messaging, calendar, and mailbox integration solutions for years. However, Microsoft has been encouraging customers to move to Microsoft Graph, which provides a modern, secure, and scalable API framework for Microsoft 365 services.
Key milestones include:
- October 1, 2026: Microsoft begins phased disablement of EWS in Exchange Online.
- April 1, 2027: EWS in Exchange Online is fully retired and all EWS requests will be blocked.
Organizations that continue to depend on EWS without proper preparation risk service disruptions, application failures, and loss of integration functionality.
What is EWSAllowedAppIDs?
EWSAllowedAppIDs is a tenant-level allow list that enables Exchange Online administrators to specify exactly which applications are permitted to access EWS based on their Microsoft Entra ID Application IDs.
This approach provides a more secure and manageable alternative to the legacy EWSAllowList, which relied on User-Agent strings and could be easily spoofed. EWSAllowedAppIDs uses application identities, making it more aligned with modern security and governance practices.
Benefits of EWSAllowedAppIDs
- Restricts EWS access to approved applications only.
- Helps identify remaining EWS dependencies.
- Supports compliance and security initiatives.
- Reduces the risk of unexpected outages during the retirement period.
- Provides administrators with better visibility and control over legacy workloads.
How EWSAllowedAppIDs Works
Microsoft combines the existing EWSEnabled setting with the new EWSAllowedAppIDs allow list.
Before October 2026
The environment remains relatively permissive, allowing organizations time to:
- Discover applications using EWS.
- Build and test allow lists.
- Validate business dependencies.
After October 2026
The behavior becomes more restrictive.
- Simply setting EWSEnabled = $true is no longer sufficient.
- Only applications included in the EWSAllowedAppIDs allow list will be permitted to use EWS.
- If no allow list exists, EWS access may be blocked even when EWS is enabled.
Step 1: Inventory Your EWS Dependencies
Before creating an allow list, administrators should identify all applications currently accessing EWS.
Microsoft provides reporting capabilities that help organizations discover EWS application usage across the tenant. These reports can be exported for analysis and mapped to application registrations in Microsoft Entra ID.
Important questions to ask:
- Which applications still use EWS?
- Are they internally developed or third-party applications?
- Is a Microsoft Graph alternative already available?
- Who owns the application?
- What is the migration timeline?
Step 2: Configure EWSAllowedAppIDs
Once application dependencies are identified, administrators can create an allow list using Exchange Online PowerShell. Administrators should regularly review and update the allow list to ensure only approved applications remain authorized.
Step 3: Validate and Test
After configuring the allow list:
- Monitor application behavior.
- Confirm that approved applications continue functioning.
- Identify any blocked applications.
- Document business justification for each allow-listed application.
- Establish a migration plan for every remaining EWS dependency.
Testing now helps prevent business disruptions when Microsoft’s enforcement phase begins.
Step 4: Accelerate Migration to Microsoft Graph
While EWSAllowedAppIDs provides a temporary bridge, it is not intended as a long-term solution. Microsoft’s strategic direction is clear: move integrations to Microsoft Graph.
Microsoft Graph offers:
- Modern REST-based APIs.
- Enhanced security controls.
- Better scalability.
- Broader Microsoft 365 integration capabilities.
- Ongoing feature investments and support.
Organizations should prioritize migration projects now to avoid last-minute challenges before the April 2027 retirement deadline.
Best Practices for Administrators
- Inventory all EWS-consuming applications.
- Create and maintain an EWSAllowedAppIDs allow list.
- Assign ownership for each EWS-dependent application.
- Review allow list entries regularly.
- Work with vendors to understand their Microsoft Graph roadmap.
- Test critical business applications before October 2026.
- Plan for complete EWS elimination before April 1, 2027.
Final Thoughts
Retirement of Exchange Web Services (EWS) is now an immediate priority, not a distant concern. With enforcement starting in October 2026 and full deprecation on April 1, 2027, Exchange Online administrators should begin preparation now. The EWSAllowedAppIDs setting offers a practical way to manage risk, surface dependencies, and ease the move to Microsoft Graph. By inventorying applications, enforcing allow lists, and planning migrations proactively, organizations can stay ahead of the timeline and reduce disruption.
Our Microsoft office 365 services team is here if you want to schedule a consultation on the above or require support.