Il problema: due permessi che cambiano nome, con una scadenza vera

Se la vostra organizzazione gestisce applicazioni che parlano con Exchange Online tramite la Exchange Online Admin API v2.0 (quella usata, ad esempio, da tool di terze parti per l’amministrazione di cassette postali, policy e configurazioni di tenant), c’è un cambiamento di permessi da Microsoft Entra che merita attenzione prima che diventi un incidente in produzione.

Non si tratta del ritiro di un’API — Microsoft lo dice esplicitamente: “Exchange Online Admin API v2.0 endpoints are not being retired”. Endpoint, versione dell’API e operazioni supportate restano identici. Cambiano solo i nomi dei permessi OAuth con cui le app si autenticano, e la finestra per migrare è più stretta di quanto sembri.

Cosa cambia esattamente

I due permessi legacy vengono sostituiti da due permessi dedicati:

• Exchange.ManageV2 (accesso delegato, cioè nel contesto di un utente che ha fatto login) diventa Exchange.AdminAPI.Manage
• Exchange.ManageAsAppV2 (accesso application-only, il classico scenario di automazione headless con certificato o client secret) diventa Exchange.AdminAPI.ManageAsApp

Sono permessi “diversi” solo nel nome: la semantica, i ruoli RBAC di Exchange sottostanti e le operazioni consentite non cambiano. Ma finché un’app usa ancora il nome vecchio, dopo la data di deprecazione perderà l’accesso all’API — niente errori progressivi o warning via email, semplicemente le chiamate iniziano a fallire con 401/403.

Le date da segnare in calendario

Per i tenant commerciali, questo significa che la finestra di migrazione reale — tra la disponibilità dei nuovi permessi e la deprecazione dei vecchi — è di circa un mese, e si chiude il 30 novembre 2026. Chi gestisce tenant GCC ha un paio di mesi in più, ma la logica non cambia.

Come capire se siete esposti

Il primo passo è un audit dei permessi applicativi su Entra ID, per trovare quali app registration usano ancora Exchange.ManageV2 o Exchange.ManageAsAppV2. Potete farlo manualmente dal portale Entra (App registrations → ogni app → API permissions, filtrando per Office 365 Exchange Online), oppure via Microsoft Graph PowerShell interrogando i service principal e i loro appRoleAssignments:

Connect-MgGraph -Scopes "Application.Read.All"

$exchangeSP = Get-MgServicePrincipal -Filter "DisplayName eq 'Office 365 Exchange Online'"

Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $exchangeSP.Id |
    Where-Object { $_.AppRoleId -in @('', '') } |
    Select-Object PrincipalDisplayName, PrincipalId, AppRoleId

Per ottenere i GUID effettivi dei ruoli applicativi legacy e nuovi, conviene leggere l’oggetto AppRoles del service principal Exchange Online stesso ($exchangeSP.AppRoles | Select DisplayName, Id, Value) e confrontarlo prima e dopo il 1° novembre, quando i nuovi ruoli compaiono nell’elenco. In alternativa, chi usa già strumenti di reporting su Entra (molti dei tool community per l’audit dei consensi applicativi includono report dedicati ai permessi Exchange/Teams) può riutilizzare quegli script invece di scriverne uno da zero.

I passi concreti per la migrazione

1. Inventario: identificate tutte le applicazioni — interne, custom, o di terze parti — che usano i permessi legacy.
2. Aggiunta del nuovo permesso: nella registrazione dell’app, aggiungete Exchange.AdminAPI.Manage (delegato) o Exchange.AdminAPI.ManageAsApp (application), senza rimuovere ancora il vecchio.
3. Admin consent: concedete il consenso amministrativo per il nuovo permesso — resta un passaggio manuale per un tenant admin, non è automatico nemmeno se il vecchio permesso era già stato consentito.
4. Verifica dei ruoli RBAC: assicuratevi che l’app o l’utente delegato abbiano ancora i ruoli RBAC di Exchange necessari — questi non cambiano, ma vale la pena verificarli nello stesso passaggio.
5. Test in parallelo: fate girare i workflow critici con il nuovo permesso attivo, prima di toccare il vecchio.
6. Pulizia: rimuovete il permesso legacy dalla configurazione dell’app solo dopo aver confermato che tutto funziona.
7. Aggiornamento di script e configurazioni: cercate riferimenti hardcoded ai nomi dei vecchi permessi in script PowerShell, pipeline di provisioning, Terraform/Bicep che gestiscono le app registration, e aggiornateli.
8. Fornitori terzi: se usate SaaS o tool di backup/migrazione/compliance che si autenticano su Exchange Online Admin API, chiedete esplicitamente al vendor se è richiesto un aggiornamento dal loro lato — spesso il consenso applicativo è gestito dal fornitore stesso durante l’onboarding iniziale, e potrebbe non essere ovvio chi debba agire.

Perché conviene muoversi subito

Un mese per il tenant worldwide è poco se l’inventario delle app registration non è già tenuto sotto controllo — cosa comune in ambienti dove negli anni si sono accumulate integrazioni di backup, DLP, reportistica di compliance e tool di migrazione, ognuno con il proprio service principal. L’impatto di un downtime non è visibile fino a che l’automazione non fallisce silenziosamente: un job notturno di backup delle cassette postali, o una pipeline di provisioning utenti, può continuare a “sembrare” funzionante nei log fino al giorno della deprecazione.

Non sono previsti requisiti di compliance diversi da quelli già in vigore, e Microsoft non ha indicato la necessità di licenze aggiuntive per i nuovi permessi: è un cambiamento puramente di naming e consenso, ma con una scadenza secca.

Fonte: Microsoft 365 Message Center, MC1540345 — Action required: Update permissions for Exchange Online Admin API.