Secure Cyber Blog

Microsoft Is Shutting Off Exchange Web Services: What Connects Through It and Why Your Timeline Just Got Shorter

Written by SecureCyber | Sep 9, 2026, 5:48:01 PM

By Matthew Williams | Your Translator for Microsoft's Fine Print

The Short Version

Microsoft is retiring Exchange Web Services (EWS), the connection method thousands of third-party tools have used for almost two decades to reach mailboxes, calendars, and contacts in Exchange Online. Starting October 1, 2026, Microsoft will disable EWS by default for any tenant that hasn't explicitly kept it turned on. The full, permanent shutdown lands April 1, 2027, with no exceptions and no re-enabling after that date. If you don't already know what's still using EWS in your Microsoft 365 environment, that's the gap to close, and it needs to close before the end of August 2026, not October.

What's Actually Changing

Think of EWS as an old side door built into every Exchange Online mailbox. For almost twenty years, outside applications walked through that door to read or write mail, calendar, and contact data: backup tools, migration software, CRM email plugins, compliance archiving systems, helpdesk platforms. It worked, so vendors kept building on it.

Microsoft is closing that door and moving all that traffic to Microsoft Graph, a newer API with modern authentication and tighter security controls built in from the start. Microsoft first announced in 2018 that EWS would stop receiving functionality updates, and in 2023 announced EWS would be disabled in Exchange Online in October 2026. The company has since confirmed a phased, admin-controllable disablement plan starting October 2026 and concluding with a complete shutdown in 2027. This is an industry-wide change: it affects every vendor connecting to Microsoft 365 through EWS, not just custom in-house tools.

The mechanics: Beginning October 1, 2026, EWS will be blocked in each tenant unless that tenant has configured an AppID Allow List and set EWSEnabled=True. Admins who proactively configure that allow list and set EWSEnabled to True by the end of August 2026 will keep their tenant excluded from the automatic October 1 shutoff and can still re-enable EWS temporarily after that date if something breaks. That grace period ends for good on April 1, 2027. After that date, EWS access is permanently removed, with no re-enablement option.

Two scope notes worth flagging directly: this change applies only to Microsoft 365 and Exchange Online, not to on-premises Exchange Server, and if you run a hybrid environment, only Exchange Subscription Edition (SE) will support Graph calls back to Exchange Online, so hybrid customers will need Exchange SE to keep hosting on-premises mailboxes that talk to the cloud side.

Why Microsoft Is in a Hurry

This isn't routine housekeeping. The Midnight Blizzard security incident in January 2024 directly involved EWS, and elevated the urgency of the deprecation effort, widening its scope from third-party applications to include Microsoft's own applications as well. In that incident, Russian state-sponsored actors compromised a legacy test OAuth application with elevated access to Microsoft's corporate environment, then used that access to grant themselves permissions built on the EWS API, which let them reach mailboxes far beyond what the original app was ever meant to touch. Independent technical analysis of the breach traces the intrusion to a stretch from November 2023 to January 2024, confirming the attackers pivoted from a non-production test account into Microsoft's main corporate tenant before landing on unrestricted access to Exchange Online mailboxes.

That's the pattern Microsoft is trying to close off industry-wide: old, broad, poorly tracked API access sitting quietly in a tenant until someone finds a way to abuse it. EWS's age and its all-or-nothing permission model make it exactly that kind of risk.

What Actually Connects Through EWS

This is the part most IT Teams underestimate. EWS isn't one application, it's a connection method that a wide range of everyday tools quietly depend on. Common culprits include:

  • Email archiving and compliance/eDiscovery tools, which pull mail for legal hold and retention
  • Backup and mailbox migration platforms
  • CRM email-sync plugins (Salesforce, HubSpot, and similar connectors that log emails against contacts and deals)
  • Helpdesk and ticketing systems with a shared mailbox or email-to-ticket integration
  • Security and monitoring tools that pull mailbox audit or activity data
  • Older mobile device management profiles or legacy mobile mail clients
  • Public folder integrations, which are a particular concern: third-party applications will lose all EWS-based access to public folders when EWS is disabled, and Microsoft Graph currently offers limited support for public folder scenarios, so there may not be a clean like-for-like replacement available yet

If any of this sounds like something your organization runs, and nobody on your team can say with confidence whether it uses EWS, that's the exposure.

What To Do Now

Do these first:

  1. Inventory every application and integration using EWS in your tenant. Microsoft's admin center and published scripts can surface this, and Microsoft has introduced a dedicated allow-list feature (EWSAllowedAppIDs) specifically to help with this step.
  2. For each dependency you find, decide - migrate it to Microsoft Graph now, or, if migration isn't realistic yet, configure the AppID Allow List and set EWSEnabled=True before the end of August 2026 so you aren't caught by the automatic October 1 shutoff.
  3. Flag any public folder integrations specifically. Graph's current support gap there means these may need a different fix entirely, not just a settings change.
  4. Contact every vendor behind a mailbox integration (backup, archiving, CRM, ticketing) and get their EWS migration plan and target date in writing. Don't assume "it still works today" means it's been fixed for October.
  5. If you run a hybrid Exchange environment, confirm your on-premises infrastructure's path to Exchange SE, since that's required for hybrid Graph connectivity.
  6. Expect Microsoft to run temporary "scream tests," short blocks meant to surface dependencies nobody remembered, in the run-up to October. Microsoft has flagged that these temporary scream tests may occur before October 2026 specifically to help identify remaining dependencies. Treat any resulting breakage as useful information, not just an inconvenience.

Then follow up:

How SecureCyber Can Help

This is exactly the kind of dependency that doesn't show up until it breaks something client-facing, a sync job, a compliance export, a support queue, on a random day after October 1. Most organizations have more of these connections than they think, and fewer than half can name them all off the top of their head.

That's the gap our Microsoft 365 Health Check is built to close. It's a focused review built around the ten questions we get asked most about the security of an M365 environment, EWS dependencies among them, and it comes back with plain-language findings and real-world recommendations your team can act on, not a 40-page audit nobody reads. If you want a clear answer on where you stand before October, reach out to us at (937) 388-4405 or info@secdef.com.

Sources