On October 1, 2026, Microsoft starts disabling Exchange Web Services by default in every Exchange Online tenant whose EWSEnabled setting is still at its factory null value. That covers most tenants. If you manage Exchange Online environments for clients and haven't taken action yet, tools that today run quietly in the background will start throwing authentication failures in 20 days.

EWS is not something most users ever see. It's the API layer that backup tools, archiving platforms, and migration utilities use to read and write Exchange Online mailboxes. Outlook desktop doesn't use it for mail delivery; neither does Outlook on the web. But Veeam Backup for Microsoft 365, MailStore, Mimecast, and dozens of similar products do, and they will break unless you act before the deadline. IMAP, POP3, and SMTP are separate protocols and are not deprecated by this change.

This piece covers the exact timeline, which tool categories are at risk, how to buy temporary breathing room, and which clients are candidates for moving off Exchange Online entirely before April 2027 rather than managing two migration projects at once.

Table of Contents

Key Takeaways

Point Details
EWS blocked by default starting October 1, 2026 Any Exchange Online tenant with EWSEnabled still at its factory null value gets it set to false automatically as Microsoft's deployment rolls out. That is the majority of tenants.
Setting EWSEnabled = $true alone is no longer enough From October 1, Microsoft also requires an EWSAllowedAppIDs allowlist specifying each Entra ID app registration that may use EWS. Without that list, all EWS connections fail even when EWSEnabled is true.
Backup, archiving, and migration tools are the three risk areas Veeam, MailStore, Mimecast, MigrationWiz, and similar products use EWS. Each has a published migration path to Microsoft Graph, but you must apply updates and grant new API permissions before the deadline.
Full shutdown is April 1, 2027, no extensions beyond that The temporary allowlist deferral buys time until March 31, 2027 at the latest. After April 1, 2027, no EWS connection will work under any configuration.
IMAP, POP3, and SMTP are unaffected These are separate protocols. Email clients, white-label hosting platforms, and any tooling that connects via standard mail protocols continue without change.

What Exchange Web Services Is and Why MSPs Encounter It

Exchange Web Services is a SOAP-based API that Microsoft introduced in Exchange 2007 to give third-party applications programmatic access to mailbox data: reading messages, syncing calendars, managing contacts, pulling folders. It predates the modern OAuth and REST era and was designed for a world where Microsoft controlled both the server and the application layer.

Most end users have never interacted with EWS directly. Where MSPs encounter it is in the tooling layer sitting above the mailbox: the backup jobs running nightly against client Exchange Online tenants, the archiving platform ingesting messages for compliance retention, the migration utility copying mailboxes from one environment to another. That tooling assumed EWS would persist indefinitely; Microsoft's announcement in 2023 set the retirement clock, and October 1, 2026 is where it lands.

This is distinct from the Exchange Online Plan 1 deprecation of EWS for Outlook desktop scenarios, which was handled separately and earlier. The October 1 deadline applies to programmatic EWS access used by third-party apps, and it affects every Exchange Online plan, not just specific ones.

Exchange Online Kiosk, F1, and F3 plan users already lost EWS access in June 2026, per Mimecast's support documentation. If you manage clients on those lower-tier plans and haven't investigated backup failures yet, that investigation is overdue.

The Two-Phase Deprecation Timeline

Microsoft structured the retirement in two phases, with the option to defer the first phase via configuration:

Now to Sep 30 Oct 1 to Mar 31, 2027 Apr 1, 2027 onwards EWS (third-party apps) Active (default on) Blocked by default Permanently shut down IMAP / POP3 / SMTP Active Active Active
EWS is being phased out in two steps; IMAP, POP3, and SMTP are separate protocols and are not affected.

Phase 1, October 1, 2026: Any tenant with EWSEnabled at its factory null setting gets it flipped to false as Microsoft's deployment rolls out. This is not a single cutover date for everyone; Microsoft is rolling out the change across tenants in waves, so not every affected tenant will lose EWS access on exactly October 1, but you should not plan around the delay. Tenants that have explicitly set EWSEnabled = $true before October 1 are not automatically converted, but they must also configure an EWSAllowedAppIDs allowlist from that date forward, or EWS connections still fail for specific apps.

Phase 2, April 1, 2027: Complete and permanent shutdown. According to Microsoft's official deprecation documentation, there will be no extensions and no exceptions after this date. Any application still using EWS will stop working, regardless of tenant configuration.

Three Tool Categories That Break First

If you are an MSP managing Exchange Online tenants, three categories of tooling are in your immediate path:

1. Backup tools

Veeam Backup for Microsoft 365 is the most widely deployed backup solution in this category. Its current version uses EWS for Exchange Online mailbox backup jobs. Veeam's KB4820 confirms that backups will stop working for tenants where EWS is disabled, and that Veeam is releasing an update to switch to Microsoft Graph. Two actions are required before October 1: update to the new version AND grant the additional Microsoft Graph API permissions the updated product requires. Applying just one of the two leaves backups broken.

The practical risk: many MSPs have backup jobs running on a schedule with no monitoring for authentication errors specifically. An EWS failure can silently produce zero successful backups while the job still "completes" with a credentials error that nobody is watching. Check your Veeam job logs now, not after October 1.

2. Email archiving platforms

MailStore and Mimecast both use EWS for archiving Exchange Online mailbox content. MailStore version 26.1 migrated regular mailbox archiving to Microsoft Graph, but Exchange Online archive mailboxes and Public Folders are a harder problem. MailStore's own documentation confirms that archiving those two object types will no longer be possible after the EWS shutdown, regardless of MailStore version. If any of your Exchange Online clients rely on archive mailboxes or Public Folders for compliance retention, that gap needs a solution before April 2027, not just a software update.

Mimecast has published a similar impact statement: several of its services that use EWS for journal ingestion and email sync will be affected from October 2026, with customers able to defer disruption by configuring the AppID allowlist but not avoid the April 2027 hard stop.

3. Migration and admin scripting tools

MigrationWiz (BitTitan) uses EWS for Exchange Online source mailbox access. If you have in-flight migrations or regularly use MigrationWiz to move mailboxes between clients, check BitTitan's current release notes for their Graph migration. ShareGate, which some MSPs use for M365 migrations, also has an EWS dependency for certain mailbox operations. Any custom PowerShell scripts your team maintains that access Exchange Online mailboxes via EWS will need to be rewritten to use the Microsoft Graph SDK before April 2027.

This is also a natural point to audit the vendor concentration risk you carry across your Exchange Online client base: a single API deprecation touching backup, archiving, and migration simultaneously shows how tightly coupled that tooling stack has become.

The Temporary Extension: Buying Time Until April 2027

If you cannot complete all three migrations (backup, archiving, migration tools) before October 1, Microsoft provides a deferral mechanism. Setting EWSEnabled = $true in your Exchange Online organization configuration before October 1 protects that tenant from the automatic null-to-false conversion. But from October 1, EWSEnabled = $true alone is no longer sufficient: you must also configure an EWSAllowedAppIDs allowlist that names each specific Entra ID application registration allowed to use EWS.

In practice this means: register each third-party tool (Veeam, MailStore, Mimecast) as an Entra app or locate its existing app registration, then add that app's ID to the EWSAllowedAppIDs list. This is a per-tenant, per-app operation. For MSPs managing 20 or 50 Exchange Online client tenants, doing this manually at scale before October 1 is itself a project. Factor that in when estimating whether the temporary deferral actually saves you time versus completing the Graph migrations directly.

The deferral buys time until March 31, 2027 at the absolute latest. It is not a path to keeping EWS indefinitely. Plan the Graph migration regardless; the question is just whether you need the extra six months to execute it.

When Staying on Exchange Online Still Makes Sense

Not every Exchange Online client is a migration candidate. Exchange Online remains the right choice when:

  • The client actively uses the M365 suite. Teams, SharePoint Online, OneDrive, and Office desktop apps are tightly integrated with Exchange Online. For a client that uses all of these, email is just one component of a broader platform. The EWS migration project is real overhead, but it doesn't change the underlying value of the suite.
  • The client has compliance or archiving requirements tied to Exchange features. eDiscovery, in-place hold, litigation hold, and Purview integration are native to Exchange Online in ways that IMAP-based email hosting does not replicate. If these capabilities are contractually required, Exchange Online is the right home for that mailbox.
  • The client uses native Outlook with MAPI and calendar-intensive workflows. EWS deprecation does not affect Outlook desktop's primary MAPI connection. Calendar sharing, meeting invites, and resource mailboxes in an Outlook-heavy environment continue working. The disruption is limited to the tooling layer, not the end-user experience.
  • You have already migrated backup and archiving to Microsoft Graph. Once the tooling migration is done, Exchange Online clients can continue without further disruption until the April 2027 hard stop, and without any disruption after it.

The M365 CSP reseller model also means that for clients where you are an indirect reseller, you don't always control the timeline for platform tooling updates. Confirm with your distributor that they have a plan for the shared tooling components before October 1.

Where Atriomail Fits: The Email-Only Exit Before October 1

The EWS deprecation creates a natural audit moment: which Exchange Online clients actually use Exchange Online, and which simply have a mailbox there because that's where you provisioned them years ago?

A client who uses Exchange Online for email only and has no active Teams usage, no SharePoint sites, no Office desktop app entitlements, and no calendar-dependent Outlook workflows is a different case from the clients described above. For that profile, the October 1 deadline creates a compressed migration timeline. Backup breaks, archiving may break, and migration tooling needs updating, all at once, for a client who doesn't get anything from the suite layer that justifies the added complexity.

Moving an email-only client to white-label email hosting before October 1 removes the EWS dependency completely. Atriomail provides IMAP, POP3, and SMTP access, which are separate protocols that are not affected by the deprecation. A mailbox on Atriomail today, after October 1, and after April 2027 looks identical from a protocol standpoint: there is no EWS layer to deprecate.

The wholesale price is $1.39 per mailbox per month, with 15 GB of storage included and $0.60 per additional 5 GB block. Domains, aliases, forwarders, and IMAP migration are free. At 50 mailboxes, that is $69.50/month wholesale, billed per usage with no contract, compared to Exchange Online Plan 1 at $4.00/user/month ($200/month for 50 seats) with the added overhead of the Graph API migration project you now have to run on top.

Migration itself can happen now, while EWS still works. Atriomail's built-in IMAP migration pulls existing mailbox content from Exchange Online, preserving folders and message dates. Doing it now rather than in the compressed March 2027 window means you're not competing for migration slots with every other MSP who put it off. DNS cutover and the full migration sequence can typically be completed in a single maintenance window per client.

Once email-only clients are on Atriomail, WHMCS or Blesta billing integration puts their mailbox line item on the same invoice as the rest of what you already bill. The provisioning, suspension, and password-reset lifecycle that today requires Exchange admin access moves to an API-driven panel with no Microsoft dependency. See the pricing page and margin calculator for the full reseller math.

Atriomail admin panel mailboxes screen showing IMAP-accessible mailboxes across multiple client domains

Atriomail mailboxes connect via IMAP, POP3, and SMTP, protocols that are not affected by the EWS deprecation timeline.

Frequently Asked Questions

Does the EWS deprecation affect Outlook desktop clients?

No, not directly. Outlook desktop connects to Exchange Online via MAPI over HTTPS, not EWS. End users running current versions of Outlook will not notice the EWS deprecation in their day-to-day email, calendar, or contacts experience. The disruption is limited to third-party applications, backup jobs, archiving platforms, and migration utilities that connect programmatically via EWS.

What happens if I do nothing before October 1?

Any Exchange Online tenant where EWSEnabled is still at its factory null value will have EWS disabled automatically as Microsoft's rollout reaches that tenant. Backup jobs using EWS will start failing authentication. Archiving ingestion via EWS will stop. The disruption may not be immediate on exactly October 1 for every tenant, since Microsoft is deploying the change in waves, but you should not rely on a delay to buy time.

Can I keep EWS running past April 1, 2027 under any configuration?

No. The EWSAllowedAppIDs allowlist and the EWSEnabled = $true configuration both stop working on April 1, 2027. Microsoft's documentation is explicit: the April 2027 shutdown is final, with no exceptions for any tenant configuration or application type. Any EWS-dependent process that has not migrated to Microsoft Graph by then will stop working permanently.

What does this mean for clients we might move off Exchange Online before April 2027?

If you move a client to IMAP-based email hosting before the April 2027 shutdown, the EWS dependency disappears with the Exchange Online tenant. You no longer need to maintain the Graph API migration for that client's backup or archiving tooling, because IMAP-based hosting does not expose an EWS endpoint at all. Migration now, while EWS still works for pulling historical mail, is simpler than migration later under time pressure when every other MSP is also rushing to complete moves before the hard stop.

Latest from the blog