# Microsoft EWS deprecation for Office 365 This page describes what Cronofy is doing in response to Microsoft retiring Exchange Web Services (EWS) for Exchange Online, and the steps you need to take so your users' Office 365 calendars keep syncing. > **WARNING:** **Microsoft will disable EWS for Office 365 on October 1, 2026.** After that date, Office 365 calendars can no longer be synced via EWS and must be connected via Microsoft's Graph API instead. Cronofy has already begun emailing affected end-users directly. If you would like to provide information to your users yourself, or track migration progress, see [What do integrators need to do?](#what-do-integrators-need-to-do). ## Timeline - **February 2025** - Microsoft retired `ApplicationImpersonation`, as part of the EWS deprecation. - **September 2026** - Cronofy begins emailing affected end-users with their path to migrate - **October 1, 2026** - Microsoft starts blocking EWS requests. Any Office 365 calendar connection still using EWS on that date will stop syncing. - **April 2027** - Microsoft fully shuts down EWS in Exchange Online. ## What’s happening? Microsoft announced the [Retirement of Exchange Web Services in Exchange Online](https://techcommunity.microsoft.com/t5/exchange-team-blog/retirement-of-exchange-web-services-in-exchange-online/ba-p/3924440), retiring EWS in favour of the Graph API. This is a broader change than the `ApplicationImpersonation` retirement that took effect in February 2025. That earlier change affected only EWS Service Accounts that relied on impersonation. This change retires EWS for Exchange Online as a whole, so it affects **every** connection that reaches a Microsoft 365 hosted mailbox over EWS - including Individual Connect calendars and Free/Busy-only Enterprise Connect connections. On-premise Exchange is not affected, and this is not time-limited. Microsoft have confirmed there are no changes to EWS in Exchange Server, and that EWS remains fully supported for on-premise mailboxes. Neither the October 2026 nor the April 2027 date applies to on-premise Exchange, so EWS continues to be the connection method for on-premise Exchange servers, including [Exchange Server Subscription Edition](/developers/faqs/authorizations/exchange-se/index.md). The Individual Connect flow has been defaulting to connecting via Graph/Office 365 rather than Exchange/Office 365, so new connections are already on Graph. ## Who’s impacted? You are affected if any of your users' calendars are hosted on Microsoft 365 and currently connected through EWS. Specifically: - **Individual Connect calendars connected via Exchange/Office 365.** These need to migrate to Graph. - **Free/Busy-only Enterprise Connect connections via Exchange/Office 365.** These need to be reconnected via Graph - see [Free/Busy-only Enterprise Connect](#freebusy-only-enterprise-connect) below. - **EWS Service Accounts using `ApplicationImpersonation`.** These stopped syncing M365 calendars in February 2025 and should already have migrated. See [Migration from EWS to Graph API](/calendar-admins/faqs/ews-migration/index.md) if any remain. You are **not** affected for calendars connected to an on-premise Exchange server. Those continue to sync over EWS. ## What do integrators need to do? ### 1. Identify affected users Run an **Application Authorizations Report** from the Reporting tab of your application dashboard and look at the `has_exchange_office365_profile` column. See [our guide on generating reports](/developers/faqs/application-management/authorized-connections-report/index.md) for how to generate it. You can also check an individual user by calling the [UserInfo endpoint](/developers/api/identity/userinfo/index.md). The [`provider_protocol`](/developers/api/identity/userinfo/index.md) attribute is set to either `exchange_web_services` or `graph_api`, telling you which protocol Cronofy is using for that Office 365 calendar. Everyone who owns a connected EWS/Office 365 calendar profile in your generated report will have been emailed a relink URL to follow to migrate as well as an admin consent link in case they see a 'Need Admin Approval' error (see [step 3](#3-handle-need-admin-approval)). Our team can also provide the migration URL for a specific user or the admin consent link for your application if you contact support at [support@cronofy.com](mailto:support@cronofy.com). ### 2. Send the migration URL Use [`graph_api_migration_url`](/developers/api/identity/userinfo/index.md). It works for any Office 365 calendar still on EWS, whether or not the profile is currently connected, and [UserInfo](/developers/api/identity/userinfo/index.md) returns it for every profile whose [`provider_protocol`](/developers/api/identity/userinfo/index.md) is `exchange_web_services`. That means you can drive the migration for your whole affected population from the API, rather than waiting on the email Cronofy sends your users. Going through the URL takes the user through the standard Microsoft sign-in and consent screens. > **WARNING:** Relink URLs behave differently. Only a **connected** calendar migrates to Graph automatically through a relink URL, and [`profile_relink_url`](/developers/api/identity/userinfo/index.md) is only returned by UserInfo once a profile has already disconnected. Use [`graph_api_migration_url`](/developers/api/identity/userinfo/index.md) for migrations and you avoid the distinction entirely. ### 3. Handle “Need admin approval” Some tenants have Microsoft 365's [User Consent setting](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent) enabled, which blocks non-Microsoft applications from being authorized by ordinary users. Affected users will see a **"Need admin approval"** message part-way through the migration. The email Cronofy sends to users are still connected already includes your application's Microsoft Graph Calendar admin consent link for this reason, so in most cases the user will have it to hand and can pass it straight to their IT administrator. If a user needs that link again, or you would rather provide it yourself, it is available in the **Credentials** tab of your application dashboard. See our [admin consent link](/developers/faqs/calendar-permissions/admin-consent-link/index.md) FAQ for details. Note that Microsoft requires the **Global Administrator** role specifically to grant tenant-wide consent. Once the admin has approved the application, the user needs to go back through their original migration URL to complete the migration. For more on this error, including what your customers' IT admins see, refer them to our ["Need admin approval" error](/calendar-admins/faqs/need-admin-approval-error/index.md) guide. ### 4. Confirm the migration worked Call the [UserInfo endpoint](/developers/api/identity/userinfo/index.md) again and check that [`provider_protocol`](/developers/api/identity/userinfo/index.md) has changed from `exchange_web_services` to `graph_api`. Re-running the Application Authorizations Report also lets you track the number of affected users down to zero. See [How to acknowledge a calendar reconnection via Cronofy's API?](/developers/faqs/authorizations/profile-reconnection-process/index.md) for how to confirm a reconnection on your side. ## Free/Busy-only Enterprise Connect Service Accounts will be able to transition from EWS to Graph. We are building a migration path for this and will email Service Accounts with instructions shortly. ## A different Azure application Graph and EWS connections use two different Azure applications, so migrating a user moves them from one to the other:
Connection Application name Application ID
Graph/Office 365 Cronofy for Office 365 `f573e3d3-ea9c-4d8d-9d8f-20107b8cedbd`
Exchange/Office 365 Cronofy `820f153b-2593-41ba-8d8c-157eec4bb791`
If an end-user asks about the permissions they previously granted, those were set against the Exchange application `820f153b-2593-41ba-8d8c-157eec4bb791`. When they migrate they authorize **Cronofy for Office 365** instead. > **WARNING:** Once every account in a tenant has migrated, the Exchange application can be removed from the tenant. This is a destructive action if any user has not migrated successfully, so please [contact us](mailto:support@cronofy.com) to verify that all accounts migrated before removing it. ### Scopes For Individual Connect via Graph, Cronofy requests only the following delegated scopes: - `User.Read` - `Calendars.ReadWrite` - `offline_access` The full set of scopes Cronofy uses is documented in [Which Graph scopes does Cronofy utilize?](/calendar-admins/enterprise-connect-office365-graph/which-graph-scopes-does-cronofy-utilize/index.md). ## If a customer cannot migrate in time A customer's IT admin can extend EWS support until April 2027 by adding Cronofy's Exchange Application ID `820f153b-2593-41ba-8d8c-157eec4bb791` to their organisation's allowed apps. This only defers the deadline rather than removing it, and they will still need to migrate to Graph before April 2027. The steps are in our [Deprecation of EWS for Exchange Online](/calendar-admins/faqs/ews-exchange-online-retirement/index.md) guide, which is the version to send to your customers' IT administrators. ## Related guides - [Deprecation of EWS for Exchange Online](/calendar-admins/faqs/ews-exchange-online-retirement/index.md) - the customer-facing version of this page, covering both Individual and Enterprise Connect migration and how to extend EWS support to April 2027 - [Graph API for Office 365](/developers/office365-graph/index.md) - background on the Graph integration, including [Migrating existing EWS individual connections](/developers/office365-graph/index.md) - [Migration from EWS to Graph API](/calendar-admins/faqs/ews-migration/index.md) - the customer-facing migration steps for Enterprise Connect - [How to identify customers that need to migrate from EWS to Graph API?](/calendar-admins/faqs/verify-pending-graph-migration-status-for-customers/index.md) - [What are the differences between EWS and Graph API?](/calendar-admins/faqs/difference-ews-and-graph/index.md) - [What should I do if I receive a relink email from Cronofy?](/developers/faqs/authorizations/relink-email/index.md) --- [Read in HTML](/developers/faqs/authorizations/ews-deprecation/)