Exchange Web Services is being switched off in Exchange Online, and every application that still reads or writes mail, calendars or contacts through it will start failing with HTTP 403 unless it has been found, approved or migrated to Microsoft Graph. Microsoft's deprecation page says EWS starts to be disabled globally for all organisations in October 2026 and is fully disabled in April 2027. For security teams this is more than an API migration: EWS apps typically hold the broadest mailbox permissions in the tenant, with an all-or-nothing access model, and the Midnight Blizzard intrusion showed what an attacker can do with one. This guide covers how to find every EWS consumer, how the tenant controls work during the shutdown window, how to migrate app identities to scoped Graph access, and how to keep the result monitored. It is written for Microsoft 365 administrators, identity engineers and application owners. Consent governance in general is covered in the Entra ID Applications and Consent Guide; this page focuses on EWS.
Key takeaways
- The dates are month-level and staged. Microsoft Learn states October 2026 for the start of global disablement and April 2027 for full disablement. Treat any app still on EWS as already at risk of breaking, and check the Exchange team's current announcements before relying on an exception.
- The EWS usage report is the starting inventory. It lists Application ID, SOAP action, call volume and last activity for up to 90 days, which is enough to find owners and decide each app's fate.
- Two tenant controls decide who still gets in. EwsEnabled at organisation and mailbox level, and the EwsAllowedAppIDs list, evaluated together with any user-agent allow or block list. Both checks must pass.
- Migration is a chance to shrink permissions. EWS has no granular scoping; Graph permissions are per feature, and RBAC for Applications in Exchange Online can restrict an app to a defined set of mailboxes.
- Remove the old grants afterwards. A migrated app that keeps full_access_as_app or EWS.AccessAsUser.All still carries the risk the retirement was meant to remove.
What is changing and when
Microsoft announced in 2018 that there would be no further investment in EWS for Exchange Online, and its deprecation page sets out the path from there. The table below lists only what Microsoft Learn states; the deprecation page links to a separate Exchange team announcement for day-level detail, which should be checked for the current state of the rollout.
| When (as stated by Microsoft) | What happens | What it means for you |
|---|---|---|
| July 2018 | Deprecation announced, no new EWS functionality | Any EWS app built since then was built on a dead end |
| 2023 | Disablement date set to October 2026 | Vendors have had notice; ask for their Graph release |
| January 2024 | Midnight Blizzard incident raises urgency, scope widened to all Microsoft applications | Microsoft's own apps are being moved off EWS too |
| 2025 | EWS usage reports, EWS Analyzer, usage reporting tool released; admins can disable EWS at organisation and user level | The tooling to find and block EWS exists today |
| October 2026 | EWS starts to be disabled globally for all organisations; the behaviour of the EWSEnabled parameter changes | Unapproved apps fail; approval is via tenant settings while they remain available |
| April 2027 | EWS is fully disabled | No setting keeps an EWS app working against Exchange Online |
Scope: the retirement is for Exchange Online. Microsoft's Graph migration overview notes that Graph is not supported for Exchange on-premises, so EWS remains the API for Exchange Server mailboxes; hybrid organisations need to check which of their features call EWS against the cloud side. Parity gaps: Microsoft lists features still being added to Graph through the second half of 2026 (for example notes, contact lists, import and export, in-place archive access and an Exchange admin API), and some it will not add: generic public folder access, generic Microsoft 365 Group mailbox access and Discovery Mailbox access, for which it points to Graph group conversations and Microsoft Purview eDiscovery APIs. An app that depends on one of those needs a redesign, not a port.
Finding every EWS consumer
Build the inventory from several sources, because each misses something.
- EWS usage report: in the Microsoft 365 admin center, Reports, Usage, Exchange, EWS usage tab. It shows Application ID, SOAP Action, Call Volume and Last Activity date (UTC) over 7, 30 or 90 days, aggregated weekly, with up to 10 days' delay. Export the CSV and keep a dated copy as evidence.
- Resolve Application IDs to owners: match each ID against Enterprise applications in Microsoft Entra ID and against Microsoft's list of first-party application IDs, as the report documentation suggests. Unknown IDs are a security finding in their own right.
- Find permission holders, not only callers: list every service principal with the Office 365 Exchange Online application permission full_access_as_app and every delegated grant of EWS.AccessAsUser.All. Microsoft's Midnight Blizzard guidance names both and advises removing those that are no longer needed. Apps that hold the permission but have not called EWS in 90 days are candidates for immediate removal.
- Check legacy Exchange roles: service accounts granted ApplicationImpersonation, or RBAC for Applications assignments of the Application EWS.AccessAsApp role, which Microsoft describes as EWS access with full access to all mailboxes.
- Scan code: Microsoft provides the EWS Analyzer for code analysis. Search internal repositories for the EWS Managed API, SOAP calls to /EWS/Exchange.asmx and token requests for the Exchange Online resource.
- Ask the business: CRM plug-ins, archiving and backup tools, mail signature tools, meeting room and scheduling systems, ticketing systems that read a shared mailbox, migration tools, and scripts written years ago by people who have since left.
| Typical EWS consumer | Usual permission | Likely path |
|---|---|---|
| Backup, archiving or journaling tool | full_access_as_app or impersonation | Vendor Graph release; confirm import and export parity first |
| Ticketing or CRM reading a shared mailbox | full_access_as_app | Graph application Mail permission scoped to that one mailbox |
| Calendar, room booking or scheduling system | full_access_as_app or impersonation | Graph Calendars permission scoped to room and user mailboxes it serves |
| Desktop mail client or add-in | EWS.AccessAsUser.All (delegated) | Vendor update to Graph delegated permissions, or retire the client |
| Internal scripts and automation | Either, often with a stored secret | Rewrite on Graph with certificate or managed identity credentials |
| Migration and coexistence tools | Impersonation or full_access_as_app | Check vendor support; remove access when the project ends |
Tenant controls during the shutdown window
Microsoft's EWS access control documentation describes the settings that decide whether a given request is allowed. They are worth understanding precisely, because a misread setting either blocks a critical app or leaves EWS wide open.
- Organisation EwsEnabled: set with Set-OrganizationConfig. False blocks the whole organisation and also disables per-user overrides. Microsoft states that the default value Null is treated as True, and that the way the parameter operates changes in October 2026 as part of the deprecation.
- Mailbox EwsEnabled: set with Set-CASMailbox. False blocks one mailbox; True does not override an organisation-wide False.
- EwsAllowedAppIDs: a comma-separated list of Entra application IDs. Microsoft states that when EWSEnabled is True, only the application IDs in this list can use EWS. Read the current list with Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy. Changes can take up to 24 hours to apply because of caching.
- User-agent lists: EwsApplicationAccessPolicy set to EnforceAllowList or EnforceBlockList, with EwsAllowList or EwsBlockList. Microsoft warns that user-agent blocking also affects REST and Graph connections, and that the app ID list and user-agent lists are both evaluated: a connection must pass both. Its example is the Teams application ID, which also needs the Teams calendar user agent on the allow list or Teams calendar access is blocked.
| X-EWS-Policy-Reason header | Meaning | Where to look |
|---|---|---|
| EWS is disabled for this user or tenant | Organisation or mailbox EwsEnabled blocks the request | Get-OrganizationConfig and Get-CASMailbox EwsEnabled; allow lists cannot fix this |
| EWS is blocked by policy for this user or tenant | App ID list or user-agent list blocked it (the header does not say which) | EwsAllowedAppIDs, EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList |
Exchange Online returns HTTP 403 with that header; Microsoft notes that a 403 on its own does not prove EWS policy caused the failure. Ask application owners to log the header value so the service desk can tell the two cases apart. The allow list is a bridge, not a destination: every entry should have an owner, a migration date and a removal date.
Migrating the app identity to Microsoft Graph
Both EWS and Graph use the Microsoft identity platform and OAuth 2.0, so the app registration usually survives. What changes is the permission model. Microsoft's documentation contrasts EWS's all-or-nothing mailbox access with Graph's granular permissions, notes that Graph has no service accounts (the app authenticates with its own identity through the client credentials flow) and that admin consent to an application permission covers all mailboxes by default unless an administrator limits it. Basic authentication is not supported by Graph.
- Map operations to permissions: use Microsoft's EWS to Graph API mapping to list each SOAP action the app uses (the usage report shows them) and the narrowest Graph permission that covers it, for example a read-only mail permission instead of read-write.
- Choose delegated or application: if a signed-in user is present, use delegated permissions, whose effective access is the intersection of the user's rights and the app's consent. Use application permissions only for genuine background services.
- Scope application access to mailboxes: RBAC for Applications in Exchange Online grants roles such as Application Mail.Read or Application Calendars.Read to a service principal with a management scope or administrative unit, and Microsoft says it replaces Application Access Policies. Create the Exchange service principal pointer with New-ServicePrincipal using the IDs from Enterprise applications (not App registrations), then New-ManagementRoleAssignment with the scope.
- Remove the unscoped Entra grant: Microsoft states that RBAC for Applications permissions act in addition to Entra ID grants, so an unscoped Mail.Read consent plus a scoped RBAC assignment results in no effective scoping. Verify with Test-ServicePrincipalAuthorization against in-scope and out-of-scope mailboxes. Allow 30 minutes to 2 hours for permission caching.
- Fix the credential: replace client secrets with certificates or, for Azure-hosted workloads, managed identities, and set an expiry and owner.
- Test, then cut over: run the Graph version in parallel against a pilot set of mailboxes, compare results, then switch production.
- Remove EWS access: delete full_access_as_app or EWS.AccessAsUser.All from the registration, revoke admin consent, remove any ApplicationImpersonation or Application EWS.AccessAsApp assignment, and take the app ID off EwsAllowedAppIDs.
Rollback: during the window when EWS can still be allowed, keep the EWS permission and allow-list entry for a short, dated period after cutover so you can fall back. After April 2027 there is no EWS to fall back to, which is why cutovers should finish well before then. See the Microsoft 365 Application Access Policies and RBAC for Applications Guide and How to review Microsoft 365 app registrations with mail permissions.
Decision guidance: migrate, replace, approve temporarily or retire
| Situation | Decision | Condition |
|---|---|---|
| No EWS calls in 90 days | Retire: remove permissions now | Owner confirms, or no owner can be found |
| Vendor has a Graph version | Upgrade, then remove EWS grant | Graph version requests no broader permissions than needed |
| Internal app, all operations have Graph equivalents | Migrate with scoped permissions | Code owner and test mailboxes available |
| Depends on a parity gap Microsoft is still closing | Approve temporarily on EwsAllowedAppIDs | Written exception, monitoring, review date before April 2027 |
| Depends on a feature Microsoft will not add to Graph | Redesign (for example Purview eDiscovery for discovery searches) | Start now; this is the longest path |
| Vendor has no plan | Replace the product | Procurement lead time counted backwards from the deadline |
Small organisations: the usage report and a list of consented apps are usually enough; most will find a handful of vendor tools and an old script or two. Large organisations: run it as a programme with an owner per app, a weekly burn-down from the usage report, and change control on EwsAllowedAppIDs, because the allow list becomes a high-value configuration in its own right.
Where identity fits
Every EWS app is a non-human identity with standing access to mailboxes, and many were registered years ago with client secrets that nobody rotates. Microsoft's guidance after the Microsoft Midnight Blizzard Breach explains why this matters: the actor found a legacy test OAuth application with elevated access and used it to grant the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes, and Microsoft detected the activity by reviewing EWS activity and audit logs. Treat the retirement as an NHI clean-up: each app gets an owner, a scoped permission, a strong credential and a review date, and the ones nobody claims are removed. See the APT29 (Midnight Blizzard) Threat Actor Profile and the Consent Phishing and Illicit OAuth Grants Guide.
Detection and measurement
| Signal | Source | Why it matters |
|---|---|---|
| EWS calls by Application ID and SOAP action | EWS usage report | Burn-down of remaining consumers; new IDs are unexpected |
| Grants of full_access_as_app or EWS.AccessAsUser.All | Entra audit log (consent and app role assignment events) | New EWS access during a retirement is almost never legitimate |
| Changes to EwsEnabled, EwsAllowedAppIDs and user-agent lists | Exchange admin audit log (Set-OrganizationConfig, Set-CASMailbox) | The allow list decides who keeps mailbox access |
| Apps with application permissions reading many mailboxes | Defender for Cloud Apps alert "App with application-only permissions accessing numerous emails" | Named by Microsoft in its Midnight Blizzard guidance |
| EWS call spikes after a credential change | Defender for Cloud Apps alert "Increase in app API calls to EWS after a credential update" | Pattern of a hijacked app credential |
| HTTP 403 with X-EWS-Policy-Reason in application logs | Application telemetry | Separates retirement breakage from other failures |
Metrics:
- Remaining EWS apps: count of Application IDs with EWS calls in the last 30 days, falling to zero before April 2027.
- Unowned apps: EWS-permissioned apps with no named owner (target zero).
- Allow-list hygiene: entries on EwsAllowedAppIDs without an approved exception and review date (target zero).
- Permission reduction: migrated apps whose Graph access is mailbox-scoped, as a percentage of all migrated application-permission apps.
- Residual grants: apps still holding full_access_as_app or EWS.AccessAsUser.All after their Graph cutover (target zero).
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK | T1114.002 Remote Email Collection; T1550.001 Application Access Token; T1528 Steal Application Access Token | Broad EWS app access is a direct route to mailbox collection |
| NIST SP 800-53 Rev. 5 | CM-8 System Component Inventory; SA-22 Unsupported System Components | Inventory EWS consumers; replace components that depend on a retired API |
| NIST SP 800-53 Rev. 5 | AC-6 Least Privilege; CM-7 Least Functionality | Scoped Graph permissions; disable EWS where unused |
| NIST SP 800-53 Rev. 5 | AU-12 Audit Record Generation; SI-4 System Monitoring | Audit consent and EWS setting changes; alert on mailbox enumeration |
| NIST CSF 2.0 | ID.AM-02; ID.AM-08; PR.PS-02 | Software and service inventory, life cycle management, replacing software commensurate with risk |
| CIS Controls v8.1 | Control 2 Inventory and Control of Software Assets; Control 6 Access Control Management | Authorised software list and least-privilege application access |
| ISO/IEC 27001:2022 Annex A | A.5.15 Access control; A.8.2 Privileged access rights | Mailbox-wide application access is privileged access |
Common failure patterns
- Allow-listing everything to stop the noise: adding every Application ID from the usage report to EwsAllowedAppIDs keeps legacy access alive until April 2027 and hides the apps that should have been removed.
- Migrating to an equally broad Graph permission: moving from full_access_as_app to an unscoped application mail permission keeps tenant-wide mailbox access. Scope it with RBAC for Applications and remove the unscoped Entra grant.
- Leaving the EWS grant in place after cutover: the app works on Graph, but the old permission and secret remain usable by anyone who steals them until the API finally goes.
- Breaking Microsoft features with a user-agent list: user-agent allow lists also apply to REST and Graph, and must line up with the app ID list, as Microsoft's Teams calendar example shows.
- Ignoring legacy test and unowned apps: the Microsoft Midnight Blizzard Breach turned on a legacy test application with elevated access. The apps nobody claims are exactly the ones to remove first.
- Waiting for full parity: Microsoft advises not waiting for every gap to close. Apps that need a redesign take longest and are the ones that end up in emergency exceptions.
Practitioner checklist
- Export the EWS usage report for 90 days and resolve every Application ID to an owner.
- List every app with full_access_as_app, EWS.AccessAsUser.All, ApplicationImpersonation or Application EWS.AccessAsApp, and remove those with no recent EWS calls.
- Read the current EwsEnabled, EwsAllowedAppIDs and user-agent list settings, and put changes to them under change control and alerting.
- Decide migrate, upgrade, temporary approval, redesign or retire for each app, with a date before April 2027.
- Migrate to the narrowest Graph permissions, scoped with RBAC for Applications, with certificate or managed identity credentials.
- Verify scoping with Test-ServicePrincipalAuthorization and remove unscoped Entra grants.
- Remove EWS permissions, consent and allow-list entries after each cutover.
- Enable the Defender for Cloud Apps EWS alerts or equivalent mailbox-enumeration detections.
- Report the remaining-apps metric weekly until it reaches zero.
Standards and references
- Microsoft Learn: EWS retirement in Exchange Online
- Microsoft Learn: Control access to EWS in Exchange
- Microsoft Learn: EWS usage report
- Microsoft Learn: Migrate EWS apps to Microsoft Graph
- Microsoft Learn: Authentication differences between EWS and Microsoft Graph
- Microsoft Learn: Role Based Access Control for Applications in Exchange Online
- Microsoft Security: Midnight Blizzard, guidance for responders on nation-state attack
- MITRE ATT&CK: Remote Email Collection (T1114.002)
Related NHI Mgmt Group resources: Entra ID Applications and Consent Guide · Microsoft 365 Application Access Policies and RBAC for Applications Guide · Exchange Online Security Guide · How to review Microsoft 365 app registrations with mail permissions