Updated 2 October 2026. Microsoft started retiring Exchange Web Services (EWS) in Exchange Online on 1 October 2026. If you expected your backup tool or CRM connector to stop that morning, it did not, and that is by design. The switch-off runs in steps: a rule change on 10 October, then tenants blocked a batch at a time with seven days' notice, and a permanent end on 1 April 2027. This post has the dates as Microsoft published them on 1 October, how to see where your tenant stands, and what to do with the time you have.
EWS is the interface that backup tools, CRM connectors, helpdesk systems, signature managers and in-house scripts have used to reach Microsoft 365 mailboxes for close to twenty years. The same material with an inventory checklist and a 30-day plan is available as a free PDF: the EWS Retirement Runbook.
The dates Microsoft published on 1 October
| Date | What happens |
|---|---|
| End of September 2026 | Last day to set EWSEnabled to True with your own allow list and stay out of the automatic change. This has passed. (Microsoft first said end of August and moved it in September.) |
| 2 October, end of day Pacific time | Microsoft records which tenants have EWSEnabled set to True but no allow list. From here on, an admin who sets it to True has to fill in the allow list personally. |
| 8 and 9 October | For the tenants on that list, Microsoft creates the allow list and fills it with the applications that used EWS in the previous 60 days. |
| From 10 October | In the worldwide cloud, EWSEnabled set to True works only together with an allow list. True with an empty list blocks all EWS. |
| After that, in batches | Tenants that never touched the setting are switched to False, which blocks EWS for every application. A tenant gets a seven-day warning in the Message Center when it is selected, and Microsoft fills in an allow list from 60 days of usage shortly before. |
| 1 April 2027 | EWS is disabled permanently and admins lose the setting. Microsoft has said there will be no exceptions. |
These dates are for Microsoft's worldwide cloud. Tenants in government and sovereign clouds get their own timeline through the Message Center.
Scope matters: this is Exchange Online only. EWS on Exchange Server in your own data centre is not being retired.
Where does your tenant stand?
One setting decides it. In Exchange Online PowerShell, run Get-OrganizationConfig | Format-List EwsEnabled and read the value.
| EwsEnabled | What it means now |
|---|---|
| Empty (never set) | EWS still works for everything today. Your tenant will be switched to False in one of the coming batches. Watch the Message Center for the seven-day notice. |
| True, with an allow list you made | Only the applications on your list can use EWS. Microsoft does not change a list you created. |
| True, without an allow list | If it was already True on 2 October, Microsoft builds the list for you on 8 and 9 October from the last 60 days of usage. Check it. Something that runs once a quarter will not be on it. |
| False | All EWS is blocked. |
The allow list, and how to turn EWS back on
The allow list is a tenant setting called EWSAllowedAppIDs. It holds the application IDs that may still use EWS. To see it:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs
To set it, pass every ID you want in one comma-separated value:
Set-OrganizationConfig -EwsAllowedAppIDs "id-one,id-two"
Three things catch people out:
- The command replaces the whole list. There is no add or remove. Read the current value, change it, and write the full list back.
- Changes are slow. Microsoft says a change to the allow list can take 24 hours to apply, and a change to EWSEnabled about an hour. If an application is already blocked, plan for that gap.
- EWSAllowList is a different setting. It is an older control that works on user-agent strings and has nothing to do with the retirement. Leave it alone.
If your tenant is switched to False and something important stops, an Exchange administrator sets EWSEnabled back to True and makes sure the allow list holds the right application IDs. Microsoft's February post also describes setting the value back to empty, which allows all EWS again until the final shutdown; its June post notes that a tenant left empty will be switched to False at some point in the rollout. Either way it is a bridge that ends on 1 April 2027. Log it as a change-control exception with an owner and an end date, because an auditor will ask why a retired interface is switched on.
Microsoft's own applications count too
An application made by Microsoft is not exempt. If it appears in your EWS usage report and you want it to keep working, it has to be on the allow list. From Microsoft's 1 October post:
- Outlook for Windows should be on a current build (August 2026, build 16.0.20430.20092 or later).
- Classic Outlook for Mac needs the "Microsoft Office" application ID on the allow list. The new Outlook for Mac is not affected.
- Excel Power Query and Power BI still use EWS in places. Microsoft has separate guidance for Excel and says a Power BI update is coming.
What breaks when the block reaches you
Mostly the systems that touch mail without a person in front of them:
- Backup and archiving tools that read mailboxes by EWS. Veeam has published its own notice; check each vendor you use.
- Journaling, compliance capture and eDiscovery connectors from third parties.
- CRM and ERP mail sync. Salesforce has its own EWS to Graph migration guidance; Dynamics, Zoho CRM, Tally add-ons and in-house connectors may all be on EWS.
- Helpdesk and ticketing systems polling a support mailbox.
- Signature managers, disclaimers, mail-merge and bulk-mail tools.
- HR, attendance and payroll systems that drop mail into a mailbox, and scanners configured against EWS.
- Custom applications written for Exchange years ago and pointed at the tenant during the 365 migration. These are the ones nobody remembers until they stop.
Hybrid: this connects to the Exchange 2016 and 2019 deadline
If some mailboxes are in Exchange Online and some on your own Exchange servers, the cloud mailboxes have to move to Microsoft Graph while the on-premise ones can keep using EWS. Microsoft adds a condition that matters this month: only Exchange Server Subscription Edition supports Graph for the calls between the two sides, so after April 2027 a hybrid organisation has to be on Exchange SE. Until then, the dedicated hybrid application can be added to the allow list so that the features shared between the two sides keep working over EWS. If your on-premise side is still Exchange 2016 or 2019, read what ends for those versions in October alongside this.
Inventory first, this week
- Open the EWS usage report in the Microsoft 365 admin center, under usage reports. Every application ID in it is in scope, including Microsoft's.
- List every application, appliance and script that authenticates to Exchange Online. Start from Entra ID: enterprise applications and app registrations with Exchange permissions, plus service accounts with mailbox access.
- Read the monthly Message Center post. Microsoft sends each tenant its own EWS usage summary there, and that is also where the seven-day notice will arrive.
- Ask each vendor in writing whether their product uses EWS, when the Graph version ships, and what the upgrade costs. Keep the replies.
- Search your own repositories and scheduled tasks for EWS endpoints and the EWS Managed API.
- Rank each item: business-critical, useful, or forgotten. The forgotten ones get retired, not migrated.
The decision: rewrite, replace, retire, or move
- Rewrite to Microsoft Graph for vendor products with a Graph version ready and for in-house code you will keep investing in. Check Microsoft's list of gaps first: some EWS features are due in Graph only in the last quarter of 2026, and a few, such as general access to public folders, are confirmed as not coming.
- Replace the integration on a standard protocol (IMAP, SMTP, CalDAV) or a vendor API when the application is old or the feature is small.
- Retire the forgotten ones. Most tenants find two or three.
- Move the mail platform if the rewrite list is long, the sector is regulated, or you do not want to run this exercise again at the next retirement.
Where XgenPlus fits, honestly
Every retirement in this cycle, basic authentication, EWS, the older Exchange editions, removes an interface your systems were built on and asks you to rebuild on the vendor's timetable. If you have a decade of integrations, that rebuild is happening either way. XgenPlus is enterprise email built in India, hosted in Indian data centres or on your own servers, and its integrations run on open, documented interfaces: IMAP and SMTP, CalDAV and CardDAV, ActiveSync, a documented SOAP API for provisioning, LDAP or Active Directory sign-in, and a RESTful API on the on-premise edition. None of them are on a retirement schedule.
Two honest limits. An XgenPlus migration is a project too, with an audit, a parallel run and a cutover evening. And your EWS code does not port to it unchanged; you replace the integration on a standard protocol, which is usually the smaller job.
Get the runbook PDF with the inventory checklist and the 30-day plan, or send us your tenant details for a migration scope you can put beside your Graph quotes. We reply within one business day.
Sources: Microsoft Exchange Team blog, "EWS Deprecation Is Here: What This Means To You" (1 October 2026), "Exchange Online EWS, Your Time is Almost Up" (updated 9 September 2026) and "Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement" (updated 22 September 2026); Microsoft Learn, "Deprecation of Exchange Web Services in Exchange Online"; Veeam KB4820; Salesforce EWS retirement guidance. Checked 2 October 2026. Microsoft is still adjusting the schedule, so confirm against the Message Center for your tenant.
