The practical risk is concentrated in software that users may not recognize as “Exchange integration”: mailbox migration tools, archiving products, line-of-business scheduling add-ins, compliance workflows, service desks, and internally developed automation. A missed dependency can look, from the user’s perspective, like calendar synchronization failures, missing mailbox data, broken import jobs, or a vendor connector that suddenly stops processing requests. The technical change may be made by a tenant administrator, but its consequences can land with help desks and ordinary Windows users.
October starts the transition; April ends EWS
Microsoft’s published retirement timetable has two distinct milestones.
- October 2026: EWS begins to be disabled globally for Exchange Online organizations.
- April 1, 2027: all EWS requests to Exchange Online are permanently blocked.
Those dates mean different things. October is the beginning of a transition process, not a single moment when every tenant necessarily receives the same configuration change. Microsoft describes enforcement as phased and tenant-by-tenant. Administrators should therefore avoid both complacency and false precision: an organization should not assume it has until the last possible day, but it also should not assume every tenant experiences the October transition at exactly the same hour.
April is different. An application that depends on EWS must be replaced, redesigned, or retired by then. An EWS app allow list can help control access during the transition, but it does not preserve EWS after final retirement.
That distinction should shape planning. Access management is a continuity measure for the months before retirement; migration work is the long-term requirement.
Why application IDs now matter
The transition guidance centers on EwsAllowedAppIDs, an Exchange Online access-control setting associated with Entra application identities. In practical terms, this shifts the conversation away from a vague question—“Which product uses EWS?”—to a more precise operational question: “Which Entra application ID is making these EWS calls, who owns it, and what business function does it support?”
Microsoft’s documented model describes EwsAllowedAppIDs as applying to direct EWS SOAP access, not to Microsoft Graph or the REST endpoint. That limitation matters in both directions:
- Adding an application identity to an EWS-focused control is not a general approval for all Microsoft 365 APIs.
- Moving an application from EWS to Graph should not be treated as merely a policy-list change; it is an application migration that may involve different permissions, authentication flows, data models, throttling behavior, and testing.
The settings must also be understood as a combination rather than as a simple list, and their effect changes during the October transition. Before October 2026, a tenant with EwsEnabled=$true and an empty or null EwsAllowedAppIDs value still permits EWS. A populated list, however, limits direct EWS to the listed application IDs. Starting in October, an enabled tenant with an empty or null list moves to block-all behavior, while a populated list continues to permit only listed application IDs. If EwsEnabled=$false, the list cannot restore EWS access. If the setting is still $null, the AppID list is not yet the effective control—but that permissive state lasts only until Microsoft changes the tenant to $false as part of the phased rollout.
That distinction is material for an administrator deciding whether to populate a list now. Adding a partial list to an enabled tenant can restrict unlisted applications before the October enforcement behavior for an empty list takes effect. Conversely, leaving an enabled tenant with an empty list becomes unsafe once the October behavior applies. Administrators should verify their exact tenant state and available parameters before changing anything. Rollout stage can affect what a tenant can view or edit, and the phased enforcement model means that timing is not identical everywhere.
AppID allow-list behavior as of September 4, 2026
The following compact matrix separates the pre-October state from the behavior that starts in October 2026. It describes direct EWS access, not Graph or REST access.
EwsEnabled state | EwsAllowedAppIDs state | Before October 2026 | Starting in October 2026 |
|---|---|---|---|
$true | Empty or null | EWS permitted | EWS blocked for all applications |
$true | Populated | Only listed App IDs permitted | Only listed App IDs permitted |
$false | Any value | EWS blocked for all applications | EWS blocked for all applications |
$null | Any value | EWS remains permissive; the AppID list is not effective | Remains permissive only until Microsoft changes that tenant to $false in the phased rollout |
The matrix is a transition-management guide, not a promise that a particular tenant will be changed on a particular day. Microsoft’s rollout is phased. It also does not alter the April 1, 2027 retirement endpoint, when EWS requests are permanently blocked regardless of previous AppID-list configuration.
Build an inventory from observed use, not assumptions
The Microsoft 365 EWS usage report is the strongest starting point for an evidence-based inventory. It can expose an application’s Entra Application ID, the SOAP actions it uses, successful-call volume, and the date of last activity. This creates a useful bridge between an opaque identifier and a business decision.
Begin with the widest available reporting window: the report supports 7-, 30-, and 90-day views. A 90-day view is generally the best initial screen because it is more likely to capture monthly activities, quarterly processes, and workflows that do not run every day. Then use narrower views to distinguish continuing activity from an application that made a short-lived burst of calls.
The report has important limits. Its data is aggregated weekly and may take up to 10 days to appear. That means it cannot prove an application is inactive merely because it has not appeared today. It is especially weak as the sole evidence for low-frequency workloads, such as a migration utility used only during acquisitions, a recovery tool held for emergencies, or a year-end compliance export.
A sensible inventory process should therefore pair the report with tenant-specific knowledge:
- Export and preserve the application IDs found in the 90-day view. Record the apparent owner, vendor or internal product name, SOAP actions, call volume, and last activity.
- Ask application owners what each identity does. A high call count indicates active use, not necessarily business importance; a small number of calls may support an essential workflow.
- Review scheduled and exceptional processes. Include migration, backup, legal, recovery, HR, finance, and incident-response teams rather than only everyday collaboration-tool owners.
- Check vendor roadmaps and support statements. Determine whether an update uses Graph, whether a new consent process is required, and whether the vendor has deadlines that are earlier than Microsoft’s final EWS shutdown.
- Classify each dependency. Use clear categories such as migrate, replace, retire, temporarily permit, or investigate.
For internal Windows applications and PowerShell-driven operational tooling, ownership is particularly important. The person who registered an Entra application may have moved teams, while the people affected by a failure may only know the tool by its executable name, server task, or scheduled-job label.
Treat automatic population as a baseline, not a complete audit
Microsoft says an EWS AppID list may be pre-populated from a tenant’s EWS usage telemetry. This can reduce the immediate danger of accidentally cutting off an actively used application during the transition. It is useful automation, but it is not a substitute for an inventory.
Usage-based discovery has unavoidable blind spots. A workload may not have run during the relevant observation period. Recent reporting data can lag. A business may have provisioned an application for an imminent project that has not yet generated normal production activity. And telemetry cannot decide whether a technically active app remains approved from a security, procurement, or data-governance perspective.
Do not rely on an assumed universal date for automatic population. Microsoft’s current framing links the list creation to each tenant’s relevant enforcement change, while the broader retirement process is phased. Organizations should watch their tenant configuration, communications, and usage data rather than schedule their work around an unverified calendar assumption.
The same caution applies to the often-repeated assertion that generated lists use an exact 60-day lookback. Microsoft confirms the broader usage-telemetry approach, but administrators should not build a risk decision around a particular lookback duration without validating the current guidance applicable to their tenant.
Avoid the allow-list naming trap
Exchange Online contains similarly named EWS controls that serve different purposes. EwsAllowedAppIDs concerns Entra application GUIDs in the retirement-related access model. The older EwsAllowList belongs to the User-Agent-based EwsApplicationAccessPolicy approach.
These are not interchangeable fields. An administrator should not paste application GUIDs into a User-Agent allow list and expect the AppID transition control to work. Where both controls are in use, an application can need to satisfy both, creating a potential source of confusing access failures.
Before any change, document which policy mechanism is already deployed, why it exists, and who owns it. Older User-Agent restrictions may have been put in place for security hardening years earlier and may be poorly documented. Removing or overwriting them without understanding their role can broaden access unexpectedly; leaving them unexamined can block a correctly identified application later.
Change management matters as much as discovery
The administrative danger is not limited to choosing the wrong AppID. Microsoft’s guidance warns that setting EwsAllowedAppIDs writes the full value, rather than automatically merging a new identifier into the existing list. In other words, omitting a valid existing AppID during an update can remove it from the permitted set.
Use an explicit change procedure:
- Retrieve and preserve the current configuration before editing.
- Treat the approved AppID set as a controlled record, with application owner and business justification for each entry.
- Have a second administrator review additions and removals, especially for high-impact integrations.
- Make the smallest practical changes and keep a rollback-ready copy of the prior complete value.
- Allow for propagation time. Microsoft indicates policy changes can take up to 24 hours to take effect, so avoid making an untested change immediately before a critical business run.
- Test with representative accounts and workloads, then monitor application-side logs and support queues for failures.
This is also the point to decide whether an app truly warrants temporary EWS access. The allow list should not become a forgotten catalog of historic integrations. Every retained identity should have an owner, a documented purpose, and a deadline for migration or retirement.
Microsoft Graph is the destination, but not every gap is closed
Microsoft recommends Microsoft Graph as the strategic replacement for EWS. That is the correct direction, but “move to Graph” is not a complete engineering plan. Microsoft still identifies parity work and gaps in areas including public-folder and Microsoft 365 Group import and export, recurring-event delta, Sticky Notes create/read/update/delete operations, user configuration, and administration APIs.
These gaps are an important counterargument to simplistic migration advice. A team with a narrow EWS dependency may be able to switch quickly. A product built around one of the remaining gaps may need a vendor update, a redesigned workflow, or a temporary business-process alternative. The gap does not change the April 2027 cutoff; it changes the amount of work needed before that cutoff.
Application owners should map individual EWS operations to actual replacement requirements instead of declaring success because an app has some Graph support. Identify the SOAP actions in use, determine whether Graph offers a suitable supported equivalent, test functional and permission differences, and check edge cases such as recurring events, mailbox-scale exports, public folders, and administrative configuration.
For users, this is where migration quality becomes visible. A connector that can read mail but cannot preserve a required calendar behavior is not a complete replacement. A backup or import tool that changes its data scope or consent requirements may need fresh governance approval. Windows administrators and endpoint teams may also need to update packaged clients, deployment scripts, certificates, service accounts, or authentication configurations associated with the replacement.
A practical timeline for organizations
The most defensible plan is to work backward from permanent EWS blocking while preparing for the October transition now.
Now: Establish the EWS dependency inventory, beginning with the 90-day usage report and supplementing it with vendor, application-owner, and operational-process reviews. Identify every application ID that needs investigation.
Before your tenant’s transition takes effect: Validate the app identity policy, inspect any automatically populated AppID list, reconcile it against the inventory, and test the applications that require temporary EWS continuity. Do not assume a low-activity integration is unimportant simply because reporting data is delayed or sparse.
During the phased October period: Monitor failures, preserve the evidence needed to identify the calling app, and use a documented response path. The goal should be to decide quickly whether an incident is a missing identity, an old User-Agent policy, an unsupported application, or an incomplete Graph migration.
Well before April 1, 2027: Close every remaining EWS dependency. Maintain temporary access only for controlled transition work, with named owners and dates. Once EWS is permanently blocked, no allow-list correction can restore an EWS integration.
The central lesson is straightforward: the AppID list is an important safety control, but it is not the finish line. Organizations that use the coming months to turn EWS telemetry into a complete ownership and migration plan will be far less likely to discover a critical dependency only after Exchange Online has stopped accepting the calls it relies on.