Your email connected apps need an owner before October

Why this is a business continuity issue

A mailbox can remain available while an important process around it stops. An application may use Exchange Web Services, or EWS, to read a shared mailbox, send notifications, create calendar items, archive messages or move email into another business system. When EWS access is blocked, Outlook can still work while the connected workflow fails.

That distinction matters in South African organisations where email often connects customer service, finance, legal, sales and operational processes. A missed case notification, unprocessed order email or failed archive job can become a service, audit or regulatory problem before the messaging team sees a conventional mailbox incident.

The owner is therefore not only the Exchange administrator. Every dependency needs a business owner who can explain what the workflow does, who relies on it, what an interruption would cost and whether the application is still required.

What Microsoft is changing

EWS is a legacy protocol introduced with Exchange Server 2007. Microsoft stopped active investment in EWS for Exchange Online and recommends Microsoft Graph for applications that access cloud mailboxes.

From 1 October 2026, Microsoft will begin moving Exchange Online tenants into a phased disablement process. A tenant that leaves the EWS setting at its default can have EWS disabled by Microsoft during that rollout. This applies to Exchange Online. Microsoft states that the retirement does not change EWS in Exchange Server.

Microsoft has also introduced EWSAllowedAppIds, a tenant-level list of application IDs that may continue to use EWS during the transition. The list is a temporary control, not a replacement for migration. After enforcement starts, setting EWS to enabled without a populated allow list can block all EWS traffic. Setting EWS to disabled blocks all EWS traffic, whether a list exists or not.

The phased process gives administrators limited control while applications are remediated. Microsoft still intends to shut EWS down permanently in Exchange Online from 1 April 2027. A temporary allow list must therefore have an expiry date, a migration owner and an approved reason.

Where hidden EWS dependencies usually sit

Start with systems that interact with mailboxes without a person opening Outlook. Common examples include archiving and journalling products, customer case systems, recruitment platforms, room-booking tools, multifunction devices, line-of-business applications, backup products and custom notification services.

Do not treat an application catalogue as proof. An application can have an EWS permission but no current use. Another can be actively using EWS through an app registration that nobody recognises. The useful inventory links four things: the Entra application or service principal, recent activity, the mailboxes involved and the business process being served.

Microsoft advises administrators to search the Microsoft 365 Message Center for “Update active Exchange Web Services Applications”. Microsoft began sending those notices to affected tenants in late December 2025. Its Exchange App Usage Reporting script can also identify registrations with EWS-related permissions, correlate them with sign-in activity, query audit logs and produce reports for application owners.

Four decisions are available

1. Retire the dependency. If the process is unused, duplicated or no longer justified, remove the permission and application cleanly.
2. Replace the product or connector. Ask the vendor for a Microsoft Graph-capable release, its required permissions, test guidance and support date.
3. Migrate custom code to Microsoft Graph. Map each EWS operation to Graph, redesign authentication and permissions, then test behaviour and error handling.
4. Use a controlled temporary bridge. Add only known application IDs to the allow list while an approved migration runs. Record an expiry date. Do not use the bridge as a permanent operating model.

Microsoft Graph is not simply a new address for the same call. EWS uses SOAP. Graph uses REST and JSON. Graph also supports more granular permissions, such as allowing an application to read mail without automatically granting access to calendars and contacts. That can improve control, but it means the permission and consent design must be reviewed rather than copied.

Decision owner

Primary owner: The Exchange Online platform owner controls tenant settings. Each dependency also needs a named application owner and business process owner. Security approves permissions and exceptions. The service desk owns the failure and escalation path.

Action within seven days

1. Day 1: Check Message Center notices, export the current EWS tenant settings and run the Microsoft usage report.
2. Day 2: Remove obvious false positives and enrich the list with recent sign-in and audit activity.
3. Day 3: Assign an application owner and business owner to every active dependency. Record the mailbox and process.
4. Day 4: Classify each dependency as retire, vendor upgrade, Graph migration or temporary allow list.
5. Day 5: Test the highest-impact workflow in a controlled environment with explicit EWS settings.
6. Day 6: Confirm the Graph permission model, vendor dates, rollback method and service-desk escalation path.
7. Day 7: Approve a dated remediation plan and report every unowned dependency as a risk.

Evidence to retain

• The dated EWS application register, including application IDs, owners, mailboxes and business processes.
• The Exchange Online configuration export and every allow-list approval.
• Usage, sign-in and audit evidence supporting the active or inactive classification.
• End-to-end test results for each high-impact workflow.
• The Graph migration backlog, vendor commitments, target dates and rollback records.
• The final permission review showing that obsolete EWS access was removed.

Questions decision-makers are asking

Will Outlook stop working on 1 October 2026?

No. This change targets applications using EWS to access Exchange Online. Outlook and a connected application are separate paths. Users may still send and receive email while an archive, case-management or booking workflow fails, which is why application discovery is required.

Does the change affect Exchange Server on premises?

Microsoft says the retirement applies to Microsoft 365 and Exchange Online, including hybrid environments where applications access cloud mailboxes. It does not change EWS in Exchange Server. Hybrid organisations still need to identify which mailbox location and endpoint each application uses.

Can we keep EWS enabled with an allow list?

Only as a controlled transition. The allow list restricts access to named application IDs during the phased period, but Microsoft is still retiring EWS permanently in Exchange Online. Every temporary exception needs an owner, purpose, expiry date and migration plan.

Why is Microsoft Graph a security improvement?

Microsoft Graph uses OAuth and supports permissions scoped to specific mailbox capabilities. EWS application access is broader and follows a more all-or-nothing model. The migration creates an opportunity to reduce privileges, but only if administrators review consent instead of reproducing the old access.

The Braintree view

Treat EWS retirement as an ownership exercise before treating it as a coding exercise. Discovery is the control. If the organisation cannot name the owner, process and mailbox behind an application ID, it cannot make a safe migration or exception decision.

Use the Braintree Briefing episode to align business and IT owners, then speak to a Braintree specialist to review the dependency register and migration plan.