A scanner sends a PDF by email. A booking panel reads a shared calendar. An old business application pulls messages from a mailbox. All three can look like ordinary Microsoft 365 functions while relying on Exchange Web Services behind the scenes.

Microsoft starts disabling EWS in Exchange Online on 1 October 2026. The final shutdown is 1 April 2027. These dates follow Microsoft's current EWS retirement schedule (checked: 2026-08-20).

If nobody has checked which devices and applications still depend on it, a routine platform change can appear as several unrelated faults across the business.

What EWS retirement can actually break

EWS is an interface that software uses to work with Exchange mailboxes, calendars, contacts and related data. It isn't the Outlook application, and the retirement doesn't mean Exchange Online email is closing. The risk sits in the connections built on top of Exchange.

Common candidates include:

  • line-of-business applications that read or file mailbox messages
  • booking displays and room-management tools that read calendars
  • archiving, backup or compliance products with an older Exchange connector
  • CRM integrations that copy emails or appointments
  • custom scripts and unattended services written years ago
  • multifunction devices where a supplier installed a mailbox-based workflow

A device that only sends mail through SMTP isn't automatically an EWS dependency. The same applies to an application that already uses Microsoft Graph. Product names alone aren't enough to decide. You need evidence from the tenant, the application owner and the supplier.

The business symptom is usually less technical than the cause. A scan never reaches the office. A reservation display stops updating. Customer correspondence no longer appears in the CRM. The owner sees a broken process, not a retired API.

Which business steps depend on software reaching an Exchange Online mailbox?

Why the October 2026 date matters

The first action date is 31 August 2026. Organisations that must keep EWS working during the transition should populate EWSAllowedAppIDs and set EWSEnabled to True by then. In September, Microsoft plans to populate empty allow lists automatically from detected tenant usage, which may include applications the organisation hasn't reviewed.

From 1 October 2026, Exchange Online tenants that haven't taken the specified administrative action enter phased EWS blocking. After enforcement starts, EWSEnabled=True with an empty allow list blocks all EWS traffic. Microsoft documents both the August action and this change in its current transition guidance and the EWSAllowedAppIDs behaviour table (checked: 2026-08-20).

That is transition control, not a migration. The allow list narrows which application IDs may use EWS while the organisation moves them to supported alternatives. It doesn't extend the final deadline.

On 1 April 2027, Microsoft plans to disable EWS in Exchange Online permanently. The tenant control is then removed and Microsoft says there will be no extensions. The retirement applies to Exchange Online. It doesn't retire EWS in on-premises Exchange Server, although hybrid scenarios need separate assessment because cloud mailboxes are still in scope.

The short-term risk is an interruption in October. The fixed risk is April. A good plan deals with both:

  • keep only a known, justified dependency operating during the transition
  • replace or retire that dependency before the permanent cutoff

How to find hidden EWS dependencies

Start with an inventory, not a switch. The aim is to connect technical usage to a device, supplier, owner and business outcome.

1. Review tenant evidence

Microsoft provides EWS usage reporting and an Exchange application usage reporting script. Its current field guidance explains how the evidence can identify application registrations with EWS permissions and correlate them with recent sign-in activity (checked: 2026-08-20).

Treat the report as the start of the investigation. An application ID needs a recognisable owner. A quiet period doesn't always prove that a dependency is gone; seasonal processes and monthly jobs may not appear in a short observation window.

For each result, record:

  • application or App ID
  • last observed activity
  • mailboxes or users involved
  • internal owner
  • supplier or developer
  • business process supported

If an entry has no owner, that is a finding in its own right. An unidentified integration shouldn't receive permanent access simply because removing it feels risky.

2. Walk through devices and business applications

Tenant reporting won't replace a practical walk-through. Ask where email and calendar data enter or leave daily operations.

Look at scanners, warehouse systems, field-service tools, booking panels, finance applications, CRM connectors and scripts running on a server or workstation. Ask suppliers which Exchange interface their current version uses. “Microsoft 365 compatible” doesn't answer whether the connector uses EWS, Graph, SMTP or another route.

This is where the Microsoft 365 and Cloud service connects technical configuration to the work it supports. The useful deliverable is a map of what could stop, who owns it and what happens next.

3. Give every dependency a decision

Each confirmed item needs one of four outcomes:

  • migrate the integration to Microsoft Graph or another supported interface
  • upgrade or reconfigure the product using the supplier's supported path
  • replace the product when no supported migration exists
  • retire the connection because the business no longer needs it

An EWS allow-list entry can provide temporary continuity, but it should have an owner and a removal date. Without those, the exception becomes another forgotten setting.

4. Test the business process, not only authentication

A successful sign-in doesn't prove the workflow is ready. Test the whole path with the people who rely on it.

For a scanner, confirm that the message arrives, the attachment opens and failures are visible. For a CRM connector, confirm that the correct mailbox content is captured without duplicates. For a booking display, check updates, permissions and recovery after a connection failure.

Record the result and the rollback or escalation route. If the test fails, the person handling Monday morning operations should know whom to call without reconstructing the project history.

5. Monitor until EWS is gone

Run the usage review again after changes. A clean inventory today can change when an old device comes back online or a supplier re-enables a legacy connector during support work.

Microsoft says it will send monthly Message Center reminders and may use temporary disablement tests to expose dependencies in tenants that haven't opted out. The Exchange Team's transition guidance documents both measures (checked: 2026-08-20). Those notices help, but they don't replace an internal owner.

A useful first pass in 30 minutes

Thirty minutes won't complete an EWS migration. It can establish whether the business has a controlled project or an unknown risk. The goal is a short evidence pack for the next decision, not a rushed configuration change.

Check the organisation-level state

Ask the Exchange Online administrator to record the current EWSEnabled value and whether EWSAllowedAppIDs is configured. Preserve the output with the date and the tenant name. If continued EWS access is required and the 31 August action hasn't been completed, escalate it immediately to the tenant administrator. Otherwise, don't change either value during this first pass.

This establishes the administrative starting point. A Null, True or False value has different behaviour during Microsoft's phased rollout, and an existing allow list may reflect deliberate work by another supplier. Changing it before understanding that history can create the outage the review is meant to prevent.

Pull the available usage evidence

Open the EWS usage information available to the tenant or run Microsoft's reporting method with an appropriately privileged account. Capture the reporting period as well as the results. A list without its time window can be misleading.

Group the findings into three buckets:

  • recognised and still required
  • recognised but probably replaceable or obsolete
  • unidentified and requiring investigation

Don't label an unidentified entry as safe or dangerous yet. Give it an owner and a deadline for identification. This keeps uncertainty visible without turning it into a permanent exception.

Match the top entries to real work

Take the most active or most business-critical entries and ask one operational question for each: what would a colleague notice if this connection stopped tomorrow?

The answer converts telemetry into priorities. An App ID with a high call count is technical evidence. “Warehouse confirmations would stop reaching customers” is a business impact that can be scheduled, tested and owned.

At the end of the first pass, write down:

  • current tenant state and evidence date
  • known applications and owners
  • unidentified entries
  • processes with material operational impact
  • the next action and accountable person for each priority item

That page is enough to decide whether the organisation can handle the work internally, needs supplier answers, or should arrange a focused tenant assessment. It is not enough to approve broad EWS access or declare the migration finished.

What not to do

Don't enable EWS broadly “just in case”. That preserves uncertainty and gives every forgotten integration the same access as a known business-critical one.

Don't copy every observed App ID into an allow list without identifying it. Activity proves use, not legitimacy or future value.

Don't assume every scanner problem is EWS. Many devices use SMTP, and their migration path may be completely different. Diagnose the actual connection before changing it.

Don't wait for 1 April 2027 because October appears reversible. A temporary re-enable may restore service after an interruption, but the final shutdown remains fixed. Supplier lead times, testing and replacement hardware can turn six months into a narrow window.

Finally, don't treat Microsoft Graph as a like-for-like name change. Permissions, authentication and supported operations differ. The supplier or developer needs to confirm the correct replacement for the exact workload.

When you can handle this internally

An internal review is realistic when one person has Exchange Online administrative access, can interpret the usage evidence, knows the application owners and has time to test each workflow. Keep the scope disciplined: inventory, owner, decision, test, evidence.

Bring in help when the tenant has no clear owner, application IDs can't be matched to products, suppliers disagree about the migration route, or a failed connection would stop customer service, production or invoicing. The same applies when several old integrations share a service account and nobody can explain the permissions.

The immediate job is to prevent an October surprise. The durable job is to leave Exchange connections documented, owned and supportable after EWS has disappeared.