Ritiro dei controlli personalizzati di Entra ID: guida alla migrazione a External MFA prima di settembre 2026

Ritiro dei controlli personalizzati di Entra ID e metodi di autenticazione esterna: cosa cambia e perché

Il ritiro dei controlli personalizzati di Entra ID — i Custom Controls di Conditional Access — a favore dei metodi di autenticazione esterna ha ormai una scadenza fissata da Microsoft. Secondo la stessa documentazione Conditional Access di Microsoft Learn, a partire da settembre 2026 non sarà più possibile creare nuovi controlli personalizzati né modificare quelli esistenti, mentre il ritiro completo è previsto per inizio 2027. Un avviso del Message Center di Microsoft 365, MC1422061 ("Microsoft Entra ID: ritiro dei controlli personalizzati in Conditional Access e migrazione a External MFA"), conferma lo stesso blocco di settembre 2026 e fissa il ritiro completo a maggio 2027, data in cui i controlli personalizzati smetteranno del tutto di essere supportati. I metodi di autenticazione esterna (External Authentication Methods) — la funzionalità basata su standard che Microsoft ora commercializza come External MFA — sono l'unica sostituzione supportata.

I controlli personalizzati non sono mai stati una funzionalità Conditional Access disponibile al pubblico in disponibilità generale — Microsoft Learn li descrive fin dall'inizio come "una funzionalità in anteprima". Quando un criterio ne utilizzava uno, il browser dell'utente connesso veniva reindirizzato a un servizio di terze parti approvato, l'autenticazione veniva completata lì, e poi veniva reindirizzato a Entra ID, che verificava la risposta prima di proseguire il flusso di accesso. Questa indirezione è esattamente ciò che viene ritirato: lo stesso risultato — MFA di terze parti applicata all'interno di Conditional Access — passa ora attraverso un metodo di autenticazione nativo e in disponibilità generale, invece di un handshake di reindirizzamento e verifica.

Come funzionano i controlli personalizzati — e perché External MFA li sostituisce

Il ritiro non è cosmetico. Le linee guida di migrazione di Microsoft elencano lacune funzionali concrete che i controlli personalizzati hanno sempre avuto, lacune che External MFA colma:

Fonte: Microsoft Learn, "Migrate from custom controls to external MFA in Conditional Access".

La documentazione di Microsoft Learn sui controlli personalizzati elenca la stessa lacuna dall'altro punto di vista: i controlli personalizzati esplicitamente non possono essere usati per soddisfare il requisito di MFA automatizzata di Identity Protection, la reimpostazione autonoma della password di Microsoft Entra, i requisiti di attestazione MFA, i controlli di frequenza di accesso, l'attivazione dei ruoli PIM, la registrazione dei dispositivi Intune, la relazione di trust cross-tenant o il join del dispositivo. Un tenant che si affida a un controllo personalizzato per "fare MFA" ha, in pratica, fatto girare un sosia che diverse altre funzionalità di Entra non riconoscono affatto come MFA — un divario significativo rispetto ai metodi nativi trattati nella nostra analisi delle modifiche alla registrazione MFA senza password.

C'è anche una sottigliezza di denominazione da segnalare per evitare confusione durante la migrazione: la sostituzione è stata rilasciata in anteprima come "external authentication methods", per poi raggiungere la disponibilità generale con il nome External MFA (External Multifactor Authentication), secondo l'annuncio di disponibilità generale di Microsoft sul blog di Entra. Microsoft Learn, l'interfaccia dell'admin center e gli oggetti dell'API Graph (externalAuthenticationMethodConfiguration) continuano a usare internamente la terminologia "external authentication method", quindi aspettatevi di vedere entrambi i nomi a seconda di dove guardate.

Rilevamento: individuare ogni criterio di Conditional Access che usa controlli personalizzati

Prima di toccare qualsiasi cosa, fate l'inventario dei criteri Conditional Access che oggi utilizzano effettivamente un controllo personalizzato. Per un quadro più ampio delle configurazioni errate di Conditional Access oltre ai controlli personalizzati, consultate la nostra guida sulle lacune dell'accesso condizionale in Entra ID. Secondo le linee guida di migrazione di Microsoft, questo può essere fatto in due modi:

Portale: accedete all'admin center di Microsoft Entra almeno con il ruolo di Amministratore dei criteri di autenticazione, andate su Protection > Conditional Access > Policies, e verificate i controlli di concessione di ciascun criterio alla ricerca di un riferimento a un controllo personalizzato. Per ogni corrispondenza, annotate nome e ID del criterio, utenti/gruppi e app cloud target, il provider del controllo personalizzato referenziato, e le eventuali condizioni (posizioni, piattaforme del dispositivo).

Microsoft Graph PowerShell (più veloce per i tenant di grandi dimensioni — le linee guida di Microsoft segnalano che alcuni ambienti hanno decine o centinaia di criteri Conditional Access da verificare):

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

Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.GrantControls -and (
        @($_.GrantControls.CustomAuthenticationFactors) |
        Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }
    ).Count -gt 0
} | Select-Object Id, DisplayName, State, @{
    N = "CustomAuthFactors"
    E = { ($_.GrantControls.CustomAuthenticationFactors | Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }) -join "," }
}

Fonte: Microsoft Learn, "Migrate from custom controls to external MFA in Conditional Access".

Esportate i risultati prima di iniziare la migrazione. Se un criterio non ha alcun riferimento a un controllo personalizzato, secondo le stesse linee guida di Microsoft non è necessaria alcuna azione su di esso — non dedicate sforzi di migrazione ai criteri non interessati.

Rimedio: migrare ai metodi di autenticazione esterna prima della scadenza

Una volta completato l'inventario, le linee guida di migrazione di Microsoft delineano un percorso a fasi. Prima i prerequisiti: una licenza Microsoft Entra ID P1 o P2, il ruolo di Amministratore dei criteri di autenticazione (funziona anche Amministratore globale), il ruolo di Amministratore di ruolo con privilegi per concedere il consenso amministratore all'app del provider, e i metadati del vostro provider External MFA — Application ID, Client ID e URL di discovery OIDC.

1. Registrare il provider External MFA. Nell'admin center, andate su Protection > Authentication methods > Policies > Add external method, indicate il nome visualizzato (non modificabile dopo la creazione), il Client ID, l'App ID e l'endpoint di discovery, quindi concedete il consenso amministratore all'app del provider. La stessa configurazione è disponibile tramite l'API Graph (POST /policies/authenticationMethodsPolicy/authenticationMethodConfigurations con @odata.type: "#microsoft.graph.externalAuthenticationMethodConfiguration") o il cmdlet PowerShell New-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration, per i team che automatizzano il rollout.
2. Puntare solo a un gruppo di test — non a tutti gli utenti — quando si abilita il metodo, e registrare quegli utenti di test per il metodo di autenticazione esterna prima di proseguire.
3. Creare un nuovo criterio Conditional Access in modalità Solo report (Report-only) che usi il controllo di concessione standard Richiedi autenticazione a più fattori (non il controllo personalizzato), con lo stesso ambito di app cloud e condizioni del criterio legacy, mirato al gruppo di test, ed escludendo gli account di accesso di emergenza break-glass.

🚨 Pericolo: le linee guida di Microsoft sono esplicite: External MFA non è ancora compatibile con "Richiedi solidità dell'autenticazione" — solo il controllo di concessione standard "Richiedi autenticazione a più fattori" lo soddisfa. Costruire il criterio di test su un requisito di solidità dell'autenticazione fallirà silenziosamente, senza funzionare come previsto.

4. Verificare prima in modalità Solo report usando la scheda Conditional Access dei log di accesso, confermare che il criterio venga valutato come previsto e che il metodo MFA risulti come il vostro provider esterno, quindi impostare il criterio su Attivo.
5. Escludere il gruppo di test dal criterio legacy basato sul controllo personalizzato e confermare con lo strumento What If che solo il nuovo criterio si applica a loro, e che gli accessi di test vengono effettivamente sfidati dal provider esterno e non dal controllo personalizzato.
6. Effettuare il rollout a fasi — gruppo di test, poi IT/early adopter, poi reparto per reparto, poi tutti gli utenti — ampliando a ogni fase sia il gruppo target del metodo External MFA sia l'ambito del nuovo criterio Conditional Access.
7. Ritirare il criterio legacy per ultimo, non per primo. Disabilitate (senza eliminare) il vecchio criterio basato sul controllo personalizzato e monitorate i log di accesso per una o due settimane prima di eliminarlo e rimuovere la definizione del controllo personalizzato, mantenendo un percorso di rollback disponibile in caso di regressioni.

Come lo rileva EtcSec

I controlli Conditional Access di EtcSec segnalano la lacuna che questo ritiro porta allo scoperto: CA_NO_MFA_REQUIREMENT individua app cloud e ambiti utente privi di un criterio Conditional Access che richieda effettivamente la MFA — esattamente lo stato in cui cade un tenant se un criterio basato su un controllo personalizzato smette silenziosamente di funzionare senza essere sostituito. MFA_NOT_ENFORCED_ADMINS e MFA_NO_STRONG_METHOD individuano account con privilegi e configurazioni a metodo debole che un controllo personalizzato rotto o non migrato può mascherare, dato che i controlli personalizzati non sono mai stati riflessi come attestazione MFA nativa. CA_POLICY_REPORT_ONLY segnala i criteri — incluso il criterio di test in Solo report raccomandato da questa migrazione — mai passati alla modalità applicata, così che una migrazione in pausa non passi inosservata.