What Microsoft's EWS Retirement Means for Calendar Sync

Exchange Web Services starts switching off on 1 October 2026 and goes dark on 1 April 2027. Here is what actually breaks, what does not, and the two tenant settings that decide which group you are in.

Microsoft is retiring Exchange Web Services (EWS) in Exchange Online. Disablement begins globally on 1 October 2026 and EWS is fully switched off on 1 April 2027. Calendar sync that runs on Microsoft Graph is unaffected. What breaks is cross-tenant free/busy between partner organizations, mailboxes on Kiosk, F1 and F3 licences, and any third-party app still calling EWS.

The timeline, with dates

Four things happen on four different dates. They are frequently reported as one event, which is why so many admins have the wrong deadline in mind.

Microsoft first announced in 2018 that EWS would stop receiving functionality updates, and set the October 2026 disablement date in 2023. The Midnight Blizzard incident in January 2024 involved EWS and widened the scope from third-party applications to Microsoft's own products, which is why Outlook, Office, Teams and Dynamics 365 are all being moved off it too.

The two settings that decide everything

EWS disablement is controlled by two tenant-level properties, and the interaction between them is where organizations get caught.

EWSEnabled

This has three values: True, False, and Null. Null is the default today, and it currently behaves like True. On 1 October 2026, as the rollout reaches your tenant, Null is changed to False. That single change blocks EWS for every application in the tenant at once.

If you still have an application that genuinely needs EWS between October 2026 and April 2027, you must explicitly set EWSEnabled to True. Leaving it at the default is not the same as leaving things as they are.

EWSAllowedAppIDs

Setting EWSEnabled to True is no longer sufficient on its own. From 1 October 2026 you also need a populated allow list naming the App IDs permitted to call EWS. Miss either half and EWS stops for everything that depends on it.

Microsoft is pre-populating this list before September 2026 for tenants that have not built one, based on each tenant's own observed usage. That helps, but it is built from what your tenant happened to call recently. An application that runs quarterly, or one that was idle during the sampling window, can be missing from a list you assume is complete.

How to check your own tenant

Connect to Exchange Online PowerShell and read the current state before planning anything:

Get-OrganizationConfig | Format-List EWSEnabled, EWSAllowedAppIDs, EWSApplicationAccessPolicy, EWSAllowList, EWSBlockList

Then find out whether anything is actually calling EWS. The EWS Usage Reports in the Microsoft 365 admin center show real traffic by application, which is more reliable than asking around internally.

If you share availability with partner organizations, check the three configurations that rely on EWS underneath:

Get-OrganizationRelationship | Format-List Name, DomainNames, FreeBusyAccessEnabled
Get-AvailabilityAddressSpace | Format-List Name, ForestName, AccessMethod
Get-SharingPolicy | Format-List Name, Domains, Enabled

Empty results across all three mean the cross-tenant piece does not apply to you. Microsoft sent the message center notice to every tenant, so a great many admins received a warning about something they do not use.

What breaks, and what does not

The distinction that matters is whether a tool talks to Exchange Online through EWS or through Microsoft Graph. Graph is the replacement API and is entirely unaffected by any of the dates above.

Does this affect CalendarBridge?

No. CalendarBridge connects to Microsoft 365 through Microsoft Graph, using the delegated Calendars.ReadWrite and User.Read scopes. It has no EWS dependency, so nothing about the October 2026 or April 2027 dates changes how your sync connections behave, and CalendarBridge does not need an entry in your EWSAllowedAppIDs allow list.

If you are auditing vendors ahead of the deadline, that is the question worth asking each of them: Graph or EWS. Any calendar tool still on EWS has a hard stop coming in April 2027, and a migration to complete before then.

How to migrate, by what you actually have

There is no single migration. What you do depends on which of the four things above applies to you, and most organizations have more than one.

Replacing cross-tenant free/busy with calendar sync

The cross-tenant piece is the one most likely to reach ordinary calendar users, and it is worth understanding the choice rather than defaulting to the like-for-like migration.

Cross-Tenant Access Policy keeps the current model: one tenant queries the other in real time whenever someone opens the scheduling assistant. It preserves live lookups, and it is the right answer if you need genuinely up-to-the-second availability across organizations. The cost is that you are migrating a cross-tenant trust configuration, and both tenants have to keep it healthy afterwards.

Calendar sync inverts the model. Instead of querying the partner tenant, CalendarBridge copies the events into a calendar in your own tenant, where they behave like any other events. They block time, they appear in the scheduling assistant and Find a Time, and they survive whatever happens to the relationship between the two tenants, because there is no live lookup to break.

Sync is usually the better fit when the requirement is that people can see when their counterparts are booked. Cross-Tenant Access Policy is the better fit when you need real-time accuracy or genuine two-way visibility into a partner's calendar detail.

Setting it up for yourself

1. Connect both accounts to CalendarBridge. Microsoft 365 accounts connect through OAuth using the delegated Calendars.ReadWrite and User.Read Graph scopes, so there is no EWS involvement and no allow-list entry needed.
2. Create a one-way sync from the partner or secondary calendar into the calendar you actually work in.
3. In the sync connection's privacy settings, leave Subject, Description, Location and Attendees unchecked so each copy is a plain busy block. Tick All Private as well if you want the copies to read as busy in Outlook Scheduling Assistant and Google Find a Time.

Setting it up for the whole organization

If you are replacing an Organization Relationship that served an entire company, you want managed syncs rather than asking every user to configure their own:

1. Create a group account with sync licences rather than user licences.
2. Authorize access for managed syncs in each tenant that hosts calendars you need. On Microsoft 365 this is an application-permission grant by a tenant admin, again on Graph.
3. Connect the authorized domains to the group account, once per tenant.
4. Create the managed sync connections. Under twenty, assign them individually. Twenty or more, use a bulk job to import the whole mapping list in one run.

Because this runs on application permissions granted by each tenant's own admin, it does not depend on an Organization Relationship, an Availability Address Space, or a Sharing Policy. None of the three configurations being migrated in September 2026 are in the path.

If you only need to publish availability

Some cross-tenant relationships exist purely so an outside party can see when your people are free. For that, a public calendar feed is simpler than either option above. Pick the calendars, switch off every detail field, and share the resulting link or ICS subscription URL. The recipient does not need a Microsoft 365 tenant, a relationship with yours, or an account of any kind. See how to sync calendars without sharing event details for the field-by-field version.

What to do in the next six weeks

1. Read your current state. Run the Get-OrganizationConfig command above and write down what EWSEnabled is set to today.
2. Pull the usage report. Find out what is genuinely calling EWS rather than relying on institutional memory.
3. Check for cross-tenant configurations. If Get-OrganizationRelationship returns nothing, you can stop worrying about the September date.
4. Audit licence assignments. Kiosk, F1 and F3 users lose EWS with no exemption. If any of them depend on an EWS-based tool, they need a different licence.
5. Ask your vendors the Graph question. Get it in writing, and treat vagueness as an answer.

The allow list is a bridge, not a destination. Anything you add to it in October 2026 still stops working in April 2027, so use the window to migrate rather than to defer.

Frequently asked questions

When exactly does EWS stop working?

EWS starts being disabled globally on 1 October 2026 and is fully disabled on 1 April 2027. Between those dates, EWS can keep running only if the tenant has EWSEnabled set to True and the calling application's App ID is in the EWSAllowedAppIDs allow list. After 1 April 2027 no setting keeps it running.

Will my calendar sync stop working when EWS is retired?

Only if your calendar sync tool uses EWS. Tools built on Microsoft Graph are unaffected, because Graph is the replacement API rather than a casualty of the retirement. CalendarBridge uses Microsoft Graph and needs no allow-list entry or configuration change.

What happens if I do nothing before 1 October 2026?

Tenants with EWSEnabled still set to Null have it changed to False as the rollout reaches them, which blocks EWS for every application in the tenant. Null is the current default, so most tenants that take no action will be switched off automatically.

Does the EWS retirement affect cross-tenant free/busy?

Yes. Cross-tenant Free/Busy, MailTips and Calendar Sharing configured through Organization Relationship, Availability Address Space or Sharing Policy all run on EWS. Microsoft is migrating them to Microsoft 365 Cross-Tenant Access Policy, with rollout beginning August 2026 and completing by 1 September 2026.

Can Kiosk, F1 and F3 mailboxes keep EWS access?

No. From 1 October 2026, EWS requests from mailboxes holding only Exchange Online Kiosk, Microsoft 365 F1 or Office 365 F3 licences return HTTP 403. The allow list does not exempt them. Those users need a licence that includes EWS rights, such as Exchange Online Plan 1 or 2, or Microsoft 365 E3 or E5.

How do I find out which applications still use EWS?

Use the EWS Usage Reports in the Microsoft 365 admin center, which show actual EWS traffic broken down by application. Microsoft also publishes an EWS Analyzer tool for scanning in-house code for EWS calls.

Sources

Timeline and mechanism verified against Microsoft's own documentation: Deprecation of Exchange Web Services in Exchange Online, Exchange Online EWS, Your Time is Almost Up, Introducing EWSAllowedAppIDs, and Migrate to Microsoft 365 Cross-Tenant Access Policy. Message center references: MC1446796, MC1227454, MC1191578.