The details are in Microsoft 365 Message Center notice MC1540345, titled "Action required: Update permissions for Exchange Online Admin API." Microsoft published it on November 5, 2026. The good news is that the change is small. Your endpoints, API version and supported operations all stay the same. The only thing that changes is the permission an app needs to call them.
What's changing
There are two direct swaps, one for each way of signing in:
| Access type | Old permission (being retired) | New permission |
|---|---|---|
| Delegated (acts on behalf of a signed-in user) | Exchange.ManageV2 | Exchange.AdminAPI.Manage |
| Application-only (runs without a user) | Exchange.ManageAsAppV2 | Exchange.AdminAPI.ManageAsApp |
Microsoft states the scope clearly: the Exchange Online Admin API v2.0 endpoints are not being retired. Only the permissions used to access them are changing: Exchange.ManageV2 is being replaced by Exchange.AdminAPI.Manage. Exchange.ManageAsAppV2 is being replaced by Exchange.AdminAPI.ManageAsApp. The notice also says Exchange Online Admin API v2.0 endpoint URLs, API version, and supported operations are not changing as a result of this update.
Microsoft says the new names give apps that reach Exchange Online's admin endpoints their own, clearer set of permissions. The change also supports the ongoing modernization of Exchange Online administration, including migration from Exchange Web Services (EWS).
In short: this is a permission-name migration. Your code does not need to call a new API.
Deadlines by cloud
The dates depend on which Microsoft 365 cloud your tenant runs in:
- Worldwide (commercial): The new permissions became available on November 1, 2026. Microsoft asks you to finish migrating by November 30, 2026. The old permissions start deprecating on December 1, 2026.
- GCC, GCC High and DoD: Rollout starts during November 2026. The notice does not give an exact day. The old permissions are deprecated on January 1, 2027.
Government cloud admins get an extra month. December 1 is the deadline for worldwide tenants only, so don't apply it to government clouds.
The notice also says what happens if you do nothing. Applications that still rely only on the retired permissions after their deprecation date will no longer be able to access the APIs. December 1 is the start of permission deprecation for worldwide tenants. It is not the date the Admin API itself shuts down.
Who is affected
This change affects organizations that develop, own, or manage applications accessing Exchange Online Admin API v2.0 using Exchange.ManageV2 for delegated access or Exchange.ManageAsAppV2 for application-only access. If your tenant uses neither permission, Microsoft says you don't need to do anything.
Microsoft does not expect ordinary end users to notice anything directly. The risk is admin tooling that breaks quietly. For example, a reporting pipeline, a tool that manages calendar folder permissions or a delegate-management app could start failing one morning.
Don't confuse this with Exchange.ManageAsApp. That older permission has a similar name and is widely used for app-only connections to Exchange Online PowerShell. Microsoft's own Services Hub guidance tells admins to assign the Office 365 Exchange Online application permission Exchange.ManageAsApp to the app and grant admin consent for that PowerShell scenario. MC1540345 lists only the two V2 permissions. A community catalog of Microsoft's first-party Entra permissions shows them as separate entries, each with its own ID:
- Exchange.ManageAsApp has the ID dc50a0fb-09a3-484d-be87-e023b12c6440.
- Exchange.ManageAsAppV2 has the ID ea3d980d-ebc7-4be4-8298-a167e5b8797c.
- The new Exchange.AdminAPI.ManageAsApp has the ID 95930782-af91-4e2e-89b7-e34ce33a0450. Its description states that it replaces the previous Exchange.ManageAsAppV2 permission.
Before you remove anything, check which permission each app actually holds. Otherwise you could fix an app that was fine and break your PowerShell automation in the process.
Why the names changed
The new names have been on the way for a while. Microsoft's Exchange Team announced the public preview of the Exchange Online Admin API on November 17, 2025. It described the API as a REST-based, cmdlet-style admin interface built mainly to help organizations move off EWS. It is not a full replacement for Exchange Online PowerShell.
Microsoft MVP Vasil Michev documented the preview, where the permissions needed to access the new endpoints were named Exchange.ManageV2 (for delegate permissions scenarios) and Exchange.ManageAsAppV2 (for application permissions one). He later added an update: for the GA version of the API Microsoft decided to remove the AcceptedDomain endpoint (to be deprecated going forward), and rename the required permissions as Exchange.AdminAPI.Manage (delegate access) and Exchange.AdminAPI.ManageAsApp (app context), respectively.
MC1540345 sets the dates for that renaming. Builders who followed the preview closely have had some warning. Everyone else has a few weeks.
How to migrate
Here are MC1540345's recommended steps, in order, with practical notes added:
- Find affected apps. Review applications using Exchange.ManageV2 or Exchange.ManageAsAppV2. In the Microsoft Entra admin center, open each relevant app registration's API permissions page. Look for entries under Office 365 Exchange Online. If you prefer to search by script, the permission IDs listed above can help, but Microsoft has not published an official tenant-wide discovery script.
- Add the new permission. Add the corresponding Exchange.AdminAPI.Manage or Exchange.AdminAPI.ManageAsApp permission. Microsoft Learn's current procedure is: Add a permission > APIs my organization uses tab > search for Office 365 Exchange Online > choose Delegated permissions or Application permissions > expand Exchange.
- Grant admin consent where it's required. An added permission that hasn't been consented to does nothing.
- Check Exchange RBAC. Confirm that the application or delegated user has the necessary Exchange roles.
- Test before you remove anything. Run the affected workflows using the new permissions. Make sure your apps request fresh tokens so the newly consented permissions are actually in use.
- Remove the old permissions only after testing succeeds.
- Update scripts and configurations that use the old permission names. Infrastructure-as-code templates, onboarding scripts and consent workflows all count.
- Contact your third-party vendors. If a vendor owns the integration or its app registration, you may not be able to fix it yourself. Ask the vendor whether it needs an update and when that update will ship. The notice doesn't name any affected products.
What success looks like: each affected app lists only the new Exchange.AdminAPI.* permission, with admin consent granted, and its Admin API calls return results as they did before.
The 403 trap: permissions are only half the setup
The most common failure here won't be the token. It will be authorization. Existing Exchange Online RBAC requirements continue to apply.
Microsoft's authentication documentation for the Admin API explains why. OAuth permissions let an app get a token. Exchange RBAC decides which cmdlets and objects the caller can actually manage. Without the right role assignments, even a valid token gets a 403 Forbidden error.
What that means in practice:
- Delegated apps: The user signing in needs Exchange roles. Microsoft Learn gives examples: Recipient Management for mailbox and folder operations, Organization Management for organization-level settings, and View-Only Organization Management for read-only organization operations.
- App-only apps: The app's service principal needs authorization. One option is an Entra role such as Exchange Administrator. The other, closer to least privilege, is a built-in or custom Exchange role group that contains only the cmdlets the app needs.
- Service principals in Exchange: Michev has pointed out on Microsoft Q&A that for app-only access you need to provision the corresponding service principal object in Exchange Online, there is no automatic sync for that.
If an app returns 403 after you swap permissions, check its RBAC assignments before you blame the new permission. Swapping the permission does not change Exchange roles.
Microsoft Learn still shows the old names
Microsoft Learn's article "Authentication and authorization for the Exchange Online Admin API" (last updated September 25, 2026) still tells readers to select Exchange.ManageV2 and Exchange.ManageAsAppV2. It also still labels the features as preview. Developers who follow that guide today will set up the permissions that are about to be retired.
Until Microsoft updates the page, use MC1540345 for the new names and dates, and use the Learn article only for the general setup steps. Also double-check what your Entra portal actually shows before you change production app registrations.
Bottom line
This is not an emergency, but it does have a hard deadline. For most tenants the fix is to add a permission, grant consent, test and then remove the old one. The work goes faster if you already have an inventory of app registrations and know which vendors use your Admin API. The risk is in what you might miss: an app built by someone who has since left, a vendor tool nobody remembers approving, or an RBAC gap that only shows up as 403 errors in December.
Worldwide tenants should finish by November 30, 2026. GCC, GCC High and DoD tenants have until January 1, 2027, but it's safer not to wait until the last week.