If email suddenly stops flowing from a “random” business app, it rarely feels random in the moment. It feels like invoices are stuck, tickets are piling up, and somebody is asking whether Microsoft is down.

This week’s change is a predictable one. Microsoft started blocking Exchange Web Services (EWS) access from non-Microsoft apps in Exchange Online on October 1, 2026, as part of EWS retirement. If you have any older integrations quietly using EWS, this is where you can get caught.

Here’s a practical checklist you can run to find what’s affected, prioritise it, and move those apps to supported paths like Microsoft Graph or vendor connectors.

First, what EWS is and why this change hits businesses

EWS is an older way that apps talk to Exchange Online for mail, calendars, contacts, and mailbox automation. A lot of third-party products adopted it years ago because it was straightforward.

The problem is you can have EWS usage without realising it. Think:

  • A CRM that “syncs your calendar”
  • A ticketing tool that reads a shared mailbox
  • A scanner or copier that emails PDFs
  • A line-of-business app that sends notifications “from” a shared mailbox

Microsoft has been signalling for a while that EWS in Exchange Online is going away, and that Microsoft Graph is the recommended replacement for Exchange Online access. The key date for most business owners is October 1, 2026, when Microsoft began blocking EWS requests from non-Microsoft apps, with a broader disablement process continuing into 2027.

Your EWS impact checklist (run this in order)

You do not need to do everything in one sitting. The goal is to build a simple, reliable list: “these apps touch email, and this is how they do it.”

  • Pull your EWS usage report. In the Microsoft 365 admin center, there’s an EWS usage report that shows which application IDs are calling EWS and what they’re doing (SOAP actions and call volume). Export it so you can work the list.

  • Translate “Application ID” into a real app name. Your report will include Entra application IDs. Some will be Microsoft first-party, some will be vendors, and some will be custom internal apps. Do not guess. Resolve each one in Entra (Enterprise Applications) so you know the actual product and owner.

  • Assign an owner for each app. For every app on the list, write down one accountable person (internal app owner, department lead, or vendor contact). This avoids the classic “everyone thought someone else owned it” stall.

  • Sort by business impact. Put a star next to anything that touches:

  • Shared mailboxes (billing@, support@, orders@)

  • Outbound notifications (quotes, job updates, appointment reminders)

  • Inbound processing (reading attachments, creating tickets, routing requests)

  • Identify the integration type. For each app, capture one sentence: “It sends mail”, “It reads a mailbox”, “It syncs calendars”, “It does all three.” This matters because the replacement path can differ.

Inventory the usual suspects (the ones people forget)

Your EWS report is your best starting point, but it’s not the only place EWS shows up. While you’re doing the inventory, check these common categories.

  • CRMs and sales tools. If it offers mailbox tracking, calendar sync, or “send as” from Outlook, it might have legacy EWS plumbing under the hood.

  • Ticketing and helpdesk platforms. Many older “email-to-ticket” features were built on EWS access to a shared mailbox.

  • Copiers, scanners, and line-of-business devices. Some devices do SMTP, some do EWS, and some do a mix depending on how they were set up years ago.

  • Backup, archiving, and eDiscovery utilities. If a tool is “pulling mailbox data” and it is not clearly using Microsoft Graph or a supported Microsoft method, treat it as suspicious until proven otherwise.

  • Custom scripts and automations. Anything written in-house that mentions “EWS Managed API”, “ExchangeService”, or “Autodiscover” is a prime candidate.

Choose the right replacement path (don’t just “turn it back on”)

Once you’ve got your list, the next step is choosing a supported way forward per app.

  • Ask the vendor for their EWS retirement plan. Your question is simple: “Do you still use EWS for Exchange Online, and if so, what’s your Microsoft Graph or supported connector alternative?” If the answer is vague, push for a specific version number and a migration guide.

  • Prefer Microsoft Graph where possible. Microsoft’s own guidance is clear that EWS apps that access Exchange Online should move to Microsoft Graph, and Microsoft provides EWS-to-Graph migration resources and API mappings.

  • For devices that only send email, consider SMTP with OAuth-capable options. A lot of scanners do not need mailbox access at all. They just need a reliable way to submit outbound mail. Your IT team should confirm the supported submission method for your tenant and device model, then modernise the configuration.

  • Use allow-listing only as a short runway, not a strategy. Microsoft introduced an AppID allow list (EwsAllowedAppIDs) so admins can explicitly control which apps can still use EWS while you migrate. That can buy you time for a stubborn vendor, but it should come with a deadline and a plan.

Test like you mean it (because “it worked in staging” doesn’t send invoices)

After each migration, do a real business test, not just an IT checkbox.

  • Outbound test. Send a message from the app, confirm it arrives externally (Gmail or a customer test address), and confirm replies land where you expect.

  • Inbound test. If the app reads a mailbox, send in a message with an attachment and confirm the app processes it correctly.

  • Calendar test. If the app books appointments or syncs calendars, create, move, and cancel an appointment and confirm it stays in sync.

  • Shared mailbox permissions test. Many breakages show up as “it can read but can’t send” or “it can send but not as the shared address.” Verify the exact behaviour your team relies on.

A simple 30-day plan to get out of the danger zone

If you want this to feel manageable, run it as a short project with clear outputs.

  • Week 1: Build the list. Export the EWS usage report, resolve app names, assign owners.
  • Week 2: Get vendor answers. For each vendor app, get the Graph or connector plan and a target date.
  • Week 3: Migrate the high-impact items first. Billing, support, order flow, anything customer-facing.
  • Week 4: Test, document, and set a clean-up date. Confirm what is fully migrated, what is temporarily allow-listed, and when the allow-list entries will be removed.

Want a second set of eyes on your EWS exposure?

This is one of those changes that’s easy to underestimate until a single forgotten integration breaks at the worst time. If you would like help inventorying EWS-dependent apps, coordinating vendor migrations, and testing the cutover, the Flexnet Networks team can help you get it cleaned up without disrupting day-to-day work.

Sources