Which Third-Party Apps Break When EWS Retires? MSP Checklist

Microsoft began EWS retirement enforcement in Exchange Online on October 1, 2026, and full retirement follows on April 1, 2027. Microsoft’s guidance directs Exchange Online administrators to identify EWS applications from their own tenant data rather than from a published list of affected products, so this post answers the question by application category. It covers which categories carry the most risk, why the work is harder across many customer tenants, and the questions to put to each vendor, with the tenant evidence that confirms or contradicts each answer.

EWS retirement enforcement is already running in customer tenants, and its effect depends on how each tenant’s EWSEnabled setting was left. Microsoft’s Message Center notice MC1485116 states that from October 10, 2026, affected Worldwide tenants with EWSEnabled set to True need a configured EWSAllowedAppIDs list, and applications not on that list may lose access to EWS. For qualifying tenants without a list, Microsoft populated one on October 8 to 9 using the previous 60 days of EWS activity.

The same notice states that tenants where EWSEnabled was never configured remain in Microsoft’s phased disablement and will have EWS disabled as that rollout reaches them. Tenants with EWSEnabled set to True and a configured allow list will not have that setting changed by Microsoft before April 2027. Microsoft also states that allow-list changes can take up to 24 hours to take effect, which matters when a client is waiting on a restored integration.

Published lists of affected products are a reasonable starting point, but they report what appeared in someone else’s tenant. Microsoft’s guidance is to investigate the EWS footprint of internal and third-party applications using EWS usage reports, and to work with vendors to prioritize their migration from EWS.

The reason is in how application identities work. Microsoft’s Entra documentation states that a service principal is created in each tenant where an application is used and references the globally unique application object. A vendor’s shared application ID can be matched across customer tenants, but consent, permissions, and the allow-list entry are held separately in each one. Where a vendor has customers create application registrations in Microsoft Entra ID inside their own tenant, the application ID differs per tenant and will not match a published list.

Classifying applications by what they do with Exchange mailbox data gives a more reliable first cut, because Microsoft documents its remaining Microsoft Graph gaps by capability. Use the category to set priority, and use tenant evidence to settle each vendor.

Applications that read or write archive mailboxes, Microsoft 365 Group mailboxes, or Public Folders carry the most risk, as do applications that move mailbox data in full fidelity. In practice, these are mailbox backup and restore, archiving and journaling, eDiscovery, and tenant-to-tenant migration tools. As an illustration, a backup product that has moved its primary-mailbox path to Microsoft Graph but not its archive path can complete jobs for primary mailboxes while skipping archive content, which is harder to detect than a failed job.

Microsoft’s parity roadmap on Microsoft Learn targets Q4 CY2026 for full-fidelity import and export of archive mailbox, Group mailbox, and Public Folder content, and for item access within an existing In-Place Archive. Microsoft describes these dates as targets that might change. The same page lists three capabilities that won’t be added to Microsoft Graph: generic Public Folder create, read, update, and delete operations; generic Microsoft 365 Group mailbox operations; and access to legacy Discovery Mailboxes, for which Microsoft points to Microsoft Purview eDiscovery APIs and workflows.

A Q4 CY2026 target leaves vendors in these categories a short window to ship and roll out Graph support before April 1, 2027. Put these vendors first in your follow-up, and ask each one which data paths will still depend on EWS after its Graph release.

On a phone, scroll the table sideways to see every column.

Microsoft’s guidance for printers and scanners describes SMTP client submission, direct send, and SMTP relay as the sending options, so scan-to-email devices generally sit outside this retirement. Some printer vendors call the device’s admin page the Embedded Web Server, also abbreviated EWS, which is unrelated to Exchange Web Services.

For an MSP, the EWS work is the same task repeated in each customer tenant, and Microsoft’s tools operate one tenant at a time. Microsoft’s documentation states that the EWS usage report shows the SOAP actions each application calls and the successful-call volume for each, filterable over the last 7, 30, or 90 days. Usage data is aggregated weekly and can take up to 10 days to appear. As of October 22, 2026, we did not find Microsoft 365 Lighthouse or Partner Center documentation that reports EWS usage across customer tenants.

Two documented behaviors can make allow lists drift apart across a portfolio. MC1485116 states that infrequently used applications may not be identified in the auto-populated lists, and that EWSAllowedAppIDs is a replacement list, so each update needs to include every required AppID. This puts month-end jobs, seasonal activities, and quarterly scripts at particular risk of missing the 60-day window. The notice also states that the older EWSAllowList setting is unrelated to EWS retirement and does not replace EWSAllowedAppIDs.

Delegated administration raises a further question. Microsoft’s Partner Center documentation lists Exchange Administrator among the roles that granular delegated admin privileges (GDAP) supports for Exchange admin center tasks. We did not find Microsoft documentation confirming that the tenant-level allow list can be managed through a GDAP relationship. Test it in one customer tenant before building a process around it.

Application vendors will answer EWS questions, but their answers describe intent. The tenant shows current behavior, so each question below is paired with the evidence that confirms or contradicts the answer.

On a phone, scroll the table sideways to see both columns.

Questions 1, 3, and 6 are the easiest for a vendor to answer in general terms. The SOAP action column in the usage report is the most direct check, because it lists the operations the application is still performing.

For capabilities Microsoft has said won’t be added to Graph, the vendor needs a redesign or a supported alternative. Microsoft Purview eDiscovery is that alternative for discovery workloads. Where a vendor has no dated Graph release, start the replacement evaluation now, while there is time to run it properly. Where your agreements make you responsible for a client’s third-party tools, review that language with the client now.

WME works as Microsoft-exclusive delivery capacity for MSPs. We can run the per-tenant EWS inventory, build the allow-list register, follow up with vendors against the checklist above, and carry out Microsoft Graph migration work in your customer tenants.