Microsoft Entra MFA: dal 2027 stop al servizio SMS e chiamate
- Introduzione
- Le date della transizione Microsoft Entra MFA
- Cosa cambierà dal 1° settembre 2026
- Cosa accadrà dal 1° febbraio 2027
- Quali tenant e utenti sono interessati
- SMS e chiamate vocali NON sono legacy authentication
- Perché Microsoft sta spostando gli utenti verso le passkey
- Scegliere i metodi di destinazione
- Preparare un pilota per le passkey
- Anticipare la Registration campaign
- Usare Conditional Access dopo la registrazione
- Impatto su SSPR e recupero dell’account
- Quando usare un provider di telecomunicazione
- Licensing e ruoli da considerare
- Piano operativo fino a febbraio 2027
- Considerazioni finali
Introduzione
Microsoft cambierà il modo in cui vengono gestiti SMS e chiamate vocali per l’autenticazione in Microsoft Entra ID. Dal 1° febbraio 2027, infatti, il servizio di telecomunicazione fornito direttamente da Microsoft non invierà più codici SMS e non effettuerà chiamate vocali per MFA e self-service password reset.
La modifica sarà preceduta da una fase di transizione; dal 1° settembre 2026, gli utenti ancora abilitati per SMS o chiamate vocali verranno inclusi nel percorso di adozione delle passkey: Microsoft Entra abiliterà per loro il metodo Passkey (FIDO2) e utilizzerà la Registration campaign per invitarli a registrare una credenziale resistente al phishing. La pianificazione pubblicata si applica agli ambienti public cloud; per gli altri cloud Microsoft comunicherà date separate.
Microsoft non sta eliminando MFA e non sta vietando in assoluto SMS e chiamate vocali. Dal 1° febbraio 2027 terminerà il servizio di consegna gestito direttamente da Microsoft. Le aziende con un requisito documentato potranno continuare a usare questi canali configurando un provider di telecomunicazione gestito dal cliente tramite Microsoft Security Store.
Le date della transizione Microsoft Entra MFA
La documentazione Microsoft individua cinque riferimenti temporali utili per pianificare la transizione: la disponibilità dell’opt-out temporaneo, l’abilitazione automatica delle passkey, la pubblicazione delle informazioni sui provider, l’apertura della relativa configurazione e il ritiro definitivo del servizio Microsoft per SMS e chiamate vocali.
Data | Modifica prevista |
|---|---|
1° agosto 2026 | Microsoft renderà disponibili le API e le istruzioni per richiedere l’opt-out temporaneo dall’abilitazione automatica delle passkey e della Registration campaign |
1° settembre 2026 | Gli utenti abilitati per SMS o chiamate vocali verranno abilitati automaticamente per le passkey e inclusi nella Registration campaign |
18 settembre 2026 | Microsoft pubblicherà nel Microsoft Security Store le informazioni sui provider di telecomunicazione disponibili |
30 ottobre 2026 | Le organizzazioni che devono mantenere SMS o voce potranno selezionare e configurare un provider gestito dal cliente |
1° febbraio 2027 | Terminerà il servizio Microsoft di consegna di SMS e chiamate vocali in Microsoft Entra ID |
L’opt-out disponibile dal 1° agosto consentirà di rimandare l’abilitazione automatica delle passkey e le modifiche alla Registration campaign previste dal 1° settembre, lasciando alle organizzazioni più tempo per migrare gli utenti o configurare un provider alternativo. Non consentirà però di continuare a utilizzare il servizio di telecomunicazione fornito da Microsoft dopo il 1° febbraio 2027.
L’opt-out rappresenta una misura temporanea e non permette di evitare l’enforcement del 1° febbraio 2027. Entro quella data gli utenti dovranno disporre di una passkey o di un altro metodo resistente al phishing; le organizzazioni che devono mantenere SMS o Voice calls dovranno invece configurare un provider di telecomunicazione tramite Microsoft Security Store. Per i dettagli, consultare la documentazione Microsoft sul ritiro di SMS e chiamate vocali.
Cosa cambierà dal 1° settembre 2026
A partire dal 1° settembre 2026, Microsoft Entra individuerà gli utenti abilitati per SMS o Voice calls nella Authentication methods policy oppure nelle impostazioni MFA legacy ancora presenti nel tenant. Per questi utenti verrà abilitato automaticamente Passkey (FIDO2), con l’assegnazione a un profilo che consente tutti i tipi di passkey; inoltre, la Registration campaign verrà impostata su Microsoft managed, utilizzerà le passkey come metodo di destinazione e includerà automaticamente gli utenti interessati. Dopo un accesso nel quale hanno completato MFA, gli utenti riceveranno quindi l’invito a registrare una passkey.
Nella configurazione gestita da Microsoft, il prompt potrà essere ignorato tramite Skip for now e, per impostazione predefinita, saranno consentiti rinvii illimitati. Gli amministratori che non intendono applicare questa esperienza possono anticipare la transizione configurando autonomamente la Registration campaign, rimuovere gli utenti dallo scope di SMS e voce prima del 1° settembre oppure utilizzare l’opt-out temporaneo che Microsoft renderà disponibile dal 1° agosto 2026. Quest’ultima opzione rimanderà l’abilitazione automatica delle passkey e della campagna, ma non consentirà di evitare l’enforcement previsto per il 1° febbraio 2027.
Con lo stato Microsoft managed, il metodo di destinazione, la durata del rinvio e il numero di rinvii vengono definiti da Microsoft e non sono configurabili dall’amministratore. Le impostazioni vengono distribuite progressivamente ai tenant; la documentazione corrente indica come valori gestiti una durata del rinvio di un giorno e un numero illimitato di rinvii. Se la policy Passkey (FIDO2) limita le credenziali a specifici AAGUID, il metodo target della campagna non viene modificato automaticamente in passkey: in questo caso occorre impostare la campagna su Enabled e configurarne manualmente il targeting.
Prima del 1° settembre 2026 è opportuno verificare lo stato effettivo della Registration campaign, gli utenti inclusi e gli eventuali profili Passkey con restrizioni AAGUID. Lo stato Microsoft managed consente a Microsoft di aggiornare progressivamente le impostazioni predefinite della campagna.
Cosa accadrà dal 1° febbraio 2027
Dal 1° febbraio 2027, i tenant che non avranno configurato un provider di telecomunicazione gestito dal cliente non potranno più utilizzare il servizio Microsoft per completare MFA tramite SMS o chiamata vocale. Gli utenti per i quali questi rappresentano gli unici metodi MFA disponibili riceveranno durante l’accesso una richiesta bloccante di registrazione di una passkey e dovranno completarla prima di poter proseguire. Microsoft precisa che non è previsto alcun opt-out da questo comportamento.
L’account non verrà disabilitato automaticamente, ma l’accesso potrà interrompersi quando l’utente non dispone di un dispositivo, un browser o un tipo di passkey compatibile con il flusso proposto. La registrazione cross-device, ad esempio, richiede una connessione Internet attiva e può dipendere dalla disponibilità del Bluetooth sui dispositivi coinvolti; requisiti e comportamento variano in base alla piattaforma e alla credenziale scelta.
Prima del 1° febbraio 2027 è necessario verificare che gli utenti non dipendano esclusivamente da SMS o Voice calls. La richiesta bloccante evita il mantenimento indefinito dei metodi telefonici forniti da Microsoft, ma può impedire il completamento del sign-in quando la registrazione della passkey non è tecnicamente o operativamente possibile.
Quali tenant e utenti sono interessati
La pianificazione pubblicata per il periodo 2026-2027 riguarda gli ambienti Microsoft Entra public cloud. Microsoft ha indicato che i cloud sovrani seguiranno una pianificazione successiva, che dovrà essere comunicata separatamente.
Il supporto delle passkey per utenti B2B e internal guest è previsto entro la fine del 2026 e questi account rientrano nello scope del ritiro del servizio SMS e voce. Al momento, tuttavia, la documentazione della Registration campaign specifica che gli utenti guest possono essere invitati a registrare Microsoft Authenticator, ma non una passkey, perché il relativo supporto non è ancora disponibile. Questo comportamento dovrà quindi essere verificato nuovamente durante il rollout.
Gli External MFA methods non vengono ritirati da questa modifica. Un utente che utilizza External MFA rientra però nello scope della transizione quando è anche abilitato per SMS o Voice calls nella Authentication methods policy oppure nelle impostazioni MFA legacy.
SMS e chiamate vocali NON sono legacy authentication
Il ritiro di SMS e chiamate vocali non coincide con la dismissione della legacy authentication. Quest’ultima riguarda i flussi di autenticazione che non supportano controlli interattivi come MFA e Conditional Access, spesso basati sull’invio diretto di nome utente e password. SMS e chiamate vocali sono invece metodi di verifica utilizzati da Microsoft Entra MFA e SSPR; dal 2027 cambierà il servizio che ne gestisce la consegna, non il supporto dei protocolli di accesso alle applicazioni.
Occorre inoltre evitare di classificare automaticamente POP, IMAP e SMTP AUTH come protocolli di autenticazione legacy, perché possono essere utilizzati anche con OAuth 2.0. La valutazione descritta in questo articolo deve concentrarsi sulla Authentication methods policy, sulle impostazioni MFA legacy ancora presenti, sui metodi registrati dagli utenti, sui sign-in logs e sulla configurazione SSPR. Aver già bloccato Basic Authentication o altri flussi legacy nel tenant non significa quindi aver completato la preparazione al ritiro del servizio SMS e voce.
Perché Microsoft sta spostando gli utenti verso le passkey
SMS e chiamate vocali dipendono dalla rete telefonica e offrono una protezione inferiore rispetto alle credenziali basate su FIDO2, perché possono essere esposti a phishing, SIM swapping, intercettazione e attacchi di replay. Le passkey utilizzano invece la crittografia a chiave pubblica e sono associate al servizio per il quale vengono registrate: durante l’autenticazione, il dispositivo produce una prova crittografica senza trasmettere un segreto che possa essere sottratto e riutilizzato. Per questo Microsoft ha scelto le passkey come metodo di destinazione per gli utenti che dipendono ancora da SMS e chiamate vocali.
Le notifiche push di Microsoft Authenticator continueranno a essere supportate e possono soddisfare un normale requisito MFA, ma costituiscono un metodo distinto dalle passkey e non soddisfano la built-in authentication strength Phishing-resistant MFA. Windows Hello for Business, le passkey supportate da Microsoft Entra e le chiavi di sicurezza FIDO2 rientrano invece tra i metodi resistenti al phishing riconosciuti dalla relativa authentication strength.
Verificare lo scope delle policy SMS e voce
Il primo controllo consiste nell’individuare gli utenti ancora abilitati a utilizzare SMS o chiamate vocali. Accedere al Microsoft Entra admin center con un account dotato almeno del ruolo Authentication Policy Administrator, quindi aprire Entra ID > Authentication methods > Policies e verificare lo stato e le assegnazioni dei metodi SMS, Voice calls e Passkey (FIDO2). Per i due metodi telefonici occorre esaminare gli utenti e i gruppi inclusi, le eventuali esclusioni e l’assegnazione ad All users, senza presumere che un metodo non utilizzato di recente sia anche disabilitato nella policy.
L’analisi deve comprendere anche le impostazioni MFA legacy ancora presenti nel tenant. Sebbene la gestione dei metodi tramite le policy legacy sia stata deprecata, Microsoft include nella transizione del 2026 gli utenti abilitati per SMS o voce sia nella Authentication methods policy sia nelle configurazioni MFA legacy; trascurare queste ultime potrebbe quindi produrre un inventario incompleto dello scope interessato.
Identificare chi usa realmente SMS o voce
Lo scope della policy mostra chi è autorizzato a usare un metodo, ma non indica necessariamente chi lo utilizza durante gli accessi. Per ottenere questa informazione aprire Entra ID > Authentication methods > Activity; il report è diviso nelle schede Registration e Usage. La prima mostra i metodi registrati e la capacità dell’utente di completare MFA, passwordless authentication e SSPR. La seconda mostra quali metodi vengono usati durante sign-in e password reset.
Nella scheda Registration bisogna individuare gli utenti che hanno registrato Mobile phone o Office phone e verificare se risultano già Passwordless capable, la scheda Usage permette invece di controllare gli accessi interattivi completati tramite SMS o chiamata telefonica.
Il report Authentication methods Activity può avere una latenza fino a 36 ore. Inoltre, il conteggio per metodo non include gli accessi nei quali il requisito MFA è stato soddisfatto da un claim già presente nel token. Il risultato deve essere confrontato con lo scope delle policy e con i sign-in logs.
Il report Usage and insights richiede Microsoft Entra ID P1 o P2. Tra i ruoli autorizzati abbiamo Reports Reader, Security Reader, Global Reader, Security Administrator e Global Administrator, oltre ad altri ruoli dotati delle permission richieste.
Eseguire lo scanner PowerShell pubblicato da Microsoft
Microsoft ha pubblicato il repository su GitHub chiamato entra-sms-voice-usage-analyzer, che contiene lo script Get-SmsVoicePolicyUsers.ps1. Lo script legge lo stato della Registration campaign, analizza lo scope delle policy SMS e voce, risolve utenti e gruppi inclusi o esclusi ed esporta i target in un file CSV. Lo script non analizza però l’utilizzo effettivo nei sign-in logs: per questo controllo servono il report Activity o una query dedicata sugli eventi di accesso.
Installare i moduli richiesti da una sessione PowerShell:
Install-Module Microsoft.Graph.Authentication -Scope CurrentUser
Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser
Install-Module Microsoft.Graph.Groups -Scope CurrentUser
Dopo aver scaricato e verificato il contenuto dello script dal repository Microsoft, eseguirlo specificando il dominio del tenant, ad esempio:
.\Get-SmsVoicePolicyUsers.ps1 -TenantId "contoso.onmicrosoft.com"
Lo script richiede le permission Microsoft Graph Policy.Read.All e Group.Read.All, inoltre il repository indica come ruoli minimi Global Reader, Authentication Policy Administrator oppure Security Reader.
Il README del repository Microsoft riporta ancora in alcuni punti la data del 28 gennaio 2027. La documentazione Microsoft Learn aggiornata indica come data ufficiale il 1° febbraio 2027. Per la pianificazione fare riferimento alla pagina Learn sul ritiro di SMS e voce.
Scegliere i metodi di destinazione
La scelta delle credenziali deve tenere conto dei dispositivi utilizzati, della mobilità degli utenti e delle procedure previste in caso di perdita o indisponibilità del metodo principale. Microsoft distingue tra credenziali portabili, utilizzabili anche per autenticarsi su altri dispositivi, e credenziali locali, associate al dispositivo sul quale vengono registrate; per la maggior parte degli utenti, il modello suggerito prevede almeno una credenziale portabile e una credenziale locale sui dispositivi utilizzati abitualmente.
Un possibile modello operativo è il seguente:
Scenario | Credenziale principale possibile | Credenziale alternativa |
|---|---|---|
Amministratori e ruoli privilegiati | Chiave di sicurezza FIDO2 | Seconda chiave FIDO2 o altra credenziale portabile resistente al phishing |
Utenti Windows con dispositivo assegnato | Windows Hello for Business | Passkey sincronizzata, passkey in Microsoft Authenticator o chiave FIDO2 |
Utenti mobili o che lavorano su più dispositivi | Passkey sincronizzata o passkey in Microsoft Authenticator | Seconda credenziale portabile registrata su un dispositivo differente |
Postazioni condivise | Credenziale portabile, ad esempio una chiave di sicurezza FIDO2 | Seconda credenziale portabile gestita |
Eccezioni che devono mantenere SMS o voce | Provider di telecomunicazione gestito dal cliente | Metodo passwordless compatibile, quando utilizzabile |
La tabella rappresenta un possibile modello operativo e non una configurazione obbligatoria. Microsoft raccomanda di classificare gli utenti per persona e di registrare almeno due metodi di autenticazione, così da mantenere un’alternativa in caso di perdita o indisponibilità della credenziale principale. Per approfondire, consultare la guida Microsoft alla distribuzione dell’autenticazione passwordless resistente al phishing.
Windows Hello for Business è indicato soprattutto per dispositivi sui quali ogni persona accede con la propria identità. Negli ambienti con postazioni condivise, Microsoft suggerisce di utilizzare Microsoft Entra passkey on Windows oppure credenziali portabili; quando il dispositivo deve supportare più di dieci utenti, una chiave di sicurezza FIDO2 può risultare più adatta rispetto a Windows Hello for Business.
Preparare un pilota per le passkey
La configurazione delle passkey è disponibile nel percorso Entra ID > Authentication methods > Policies > Passkey (FIDO2). Un Authentication Policy Administrator può creare un profilo, definire i tipi di passkey consentiti e assegnarlo a un gruppo di sicurezza pilota. I profili permettono di distinguere passkey sincronizzate e device-bound e di applicare requisiti di attestation o restrizioni sugli authenticator.
Il gruppo pilota dovrebbe includere sistemi operativi, browser e scenari di accesso rappresentativi. È utile verificare registrazione sullo stesso dispositivo, autenticazione cross-device, sostituzione dello smartphone, perdita della chiave, revoca della credenziale e bootstrap tramite Temporary Access Pass.
Registrate per primi utenti IT e volontari che utilizzano realmente Windows, macOS, iOS e Android presenti in produzione. Un pilota limitato a un solo browser o a dispositivi appena configurati non evidenzia le dipendenze che genereranno richieste al service desk.
Anticipare la Registration campaign
La Registration campaign può essere configurata prima dell’abilitazione automatica prevista dal 1° settembre 2026, dal percorso Entra ID > Authentication methods > Registration campaign.
La campagna invita gli utenti inclusi a registrare una passkey dopo il normale accesso e il completamento di Microsoft Entra MFA. Prima di attivarla, occorre verificare che Passkey (FIDO2) sia abilitato nella Authentication methods policy per gli utenti target e che l’opzione Allow self-service set up consenta loro di registrare autonomamente la credenziale. La Registration campaign non prevede un requisito di licenza specifico, ma il nudge viene mostrato soltanto agli utenti che completano MFA tramite Microsoft Entra.
Nel tenant può essere attiva una campagna di registrazione per un solo metodo alla volta: Passkey (FIDO2) oppure Microsoft Authenticator. Se è già in esecuzione una campagna per le notifiche push di Authenticator, il passaggio alle passkey deve essere pianificato verificando utenti inclusi, esclusioni e impostazioni di rinvio.
Non è quindi possibile mantenere contemporaneamente due campagne separate, una per Authenticator e una per le passkey. Prima di modificare il metodo target conviene controllare lo stato della campagna esistente e completare un pilota con utenti rappresentativi, evitando di cambiare l’esperienza di registrazione per gruppi che stanno già seguendo un percorso di adozione differente.
Usare Conditional Access dopo la registrazione
L’abilitazione delle passkey consente agli utenti di registrarle e utilizzarle, ma non ne impone l’uso per accedere alle risorse. Per richiedere un metodo resistente al phishing a utenti, gruppi o applicazioni specifiche è necessario configurare una Conditional Access policy con il controllo Require authentication strength > Phishing-resistant MFA. Microsoft Entra verifica quindi che il metodo utilizzato durante l’accesso sia compreso nella authentication strength selezionata.
Conditional Access richiede almeno Microsoft Entra ID P1. Prima dell’attivazione è consigliabile distribuire la policy in modalità Report-only e analizzare i sign-in logs, così da individuare gli utenti che non dispongono ancora di un metodo compatibile con Phishing-resistant MFA. Per i dettagli, consultare la documentazione Microsoft sulle authentication strengths.
La sequenza del rollout incide direttamente sul rischio di interruzione: occorre prima abilitare le passkey, consentire agli utenti di completarne la registrazione e verificare che possano utilizzarle nei flussi di accesso previsti, quindi applicare l’enforcement tramite Conditional Access. Se la authentication strength resistente al phishing viene assegnata in anticipo, gli utenti che dispongono soltanto di SMS, chiamate vocali, codici OTP o notifiche push non potranno soddisfare il controllo e non riusciranno ad accedere alle risorse protette. Microsoft raccomanda di verificare l’impatto delle nuove policy in modalità Report-only prima dell’attivazione.
Impatto su SSPR e recupero dell’account
Il ritiro del servizio Microsoft per SMS e chiamate vocali si applica anche a self-service password reset. Gli utenti che dipendono dal telefono come unico metodo potrebbero non riuscire a completare autonomamente il recupero della password dopo il 1° febbraio 2027. L’assessment deve quindi comprendere configurazione SSPR, numero di metodi richiesti, password writeback per gli account sincronizzati e procedura helpdesk per gli utenti che hanno perso tutte le credenziali disponibili.
Microsoft ha annunciato separatamente una funzionalità che consentirà agli utenti autenticati con passkey, chiave FIDO2 o Windows Hello for Business di cambiare la password senza conoscere quella precedente. Questa funzione agevola alcuni scenari passwordless, ma non sostituisce tutte le procedure di account recovery. L’argomento è approfondito nell’articolo Microsoft Entra: cambio password passwordless in My Sign-Ins pubblicato su Endpoint Ninja.
Temporary Access Pass può essere inserito nella procedura di bootstrap per consentire a un utente verificato di registrare una nuova credenziale passwordless. La generazione e la consegna del TAP devono seguire una procedura controllata, con durata e utilizzi compatibili con lo scenario.
Quando usare un provider di telecomunicazione
A partire dal 30 ottobre 2026, le aziende che devono continuare a utilizzare SMS o chiamate vocali potranno selezionare e configurare un provider di telecomunicazione gestito dal cliente tramite Microsoft Security Store. Microsoft presenta questa opzione per segmenti di utenti con esigenze normative, operative o tecniche documentate, ad esempio quando un requisito di conformità impone un canale fuori banda oppure non è possibile adottare un metodo alternativo. Prima della configurazione sarà quindi necessario individuare con precisione gli utenti interessati, documentare il requisito e verificare che il provider supporti le aree geografiche e le condizioni di conformità richieste.
Il rapporto contrattuale sarà gestito direttamente con il provider selezionato tramite Microsoft Security Store. Prezzi e condizioni dipenderanno dal fornitore, dalla regione, dai volumi e dalla distribuzione geografica degli utenti, con costi generalmente legati all’utilizzo del servizio. Secondo la documentazione Microsoft sul ritiro di SMS e chiamate vocali, la migrazione alle passkey non comporta un costo aggiuntivo specifico.
L’uso di un provider esterno dovrebbe essere riservato ai gruppi con un requisito normativo, operativo o tecnico verificabile. Mantenerlo per l’intera azienda prolungherebbe la dipendenza da metodi meno resistenti al phishing e introdurrebbe costi operativi ricorrenti.
Licensing e ruoli da considerare
L’abilitazione delle passkey e la configurazione della Authentication methods policy non richiedono una licenza Microsoft Entra ID Premium aggiuntiva, perché Passkey (FIDO2) è disponibile anche nell’edizione Free. I requisiti di licensing entrano in gioco quando si utilizzano i report avanzati oppure Conditional Access per imporre metodi resistenti al phishing.
Attività | Requisito |
|---|---|
Configurare Authentication methods policy e Passkey (FIDO2) | Ruolo Authentication Policy Administrator (nessuna licenza Premium aggiuntiva) |
Configurare la Registration campaign | Ruolo Authentication Policy Administrator; MFA abilitata (senza requisito di licenza specifico documentato) |
Consultare Authentication methods Usage and insights | Microsoft Entra ID P1 o P2 e un ruolo di lettura supportato |
Applicare Conditional Access e authentication strengths | Microsoft Entra ID P1 o P2 |
Utilizzare un provider di telecomunicazione esterno | Contratto, disponibilità geografica e costi stabiliti dal provider |
Prima del rollout occorre verificare che gli amministratori dispongano dei ruoli necessari. Microsoft Entra ID P1 o P2 deve essere considerato soltanto quando il progetto utilizza Authentication methods Usage and insights, Conditional Access o altre funzionalità Premium.
Piano operativo fino a febbraio 2027
Per gestire la transizione senza concentrare tutte le attività a ridosso della scadenza, converrebbe suddividere il lavoro in fasi successive. L’obiettivo è partire dall’inventario degli utenti ancora dipendenti da SMS e chiamate vocali, validare i metodi alternativi con un gruppo pilota e completare la migrazione prima che termini il servizio di telecomunicazione fornito da Microsoft.
Assessment
Entro agosto 2026 è opportuno esportare lo scope delle policy SMS e voce, confrontarlo con l’utilizzo effettivo dei due metodi e individuare gli utenti che non dispongono ancora di un’alternativa. L’analisi deve comprendere account amministrativi, guest, utenti che lavorano su postazioni condivise e processi SSPR, perché questi scenari possono richiedere credenziali e procedure di recupero differenti.
Pilota
Prima del 1° settembre conviene abilitare Passkey (FIDO2) per un gruppo pilota rappresentativo, verificando registrazione, autenticazione e compatibilità con dispositivi e browser realmente utilizzati in produzione. Nella stessa fase vanno predisposte le procedure per Temporary Access Pass, revoca e sostituzione delle credenziali; la Registration campaign può essere attivata sul gruppo pilota senza attendere l’intervento automatico di Microsoft.
Estensione
Tra settembre 2026 e gennaio 2027 la registrazione può essere estesa progressivamente ad altri gruppi, monitorando il report Authentication methods Activity e i sign-in logs per individuare errori, utenti ancora dipendenti dai canali telefonici e problemi di compatibilità. Quando un gruppo ha completato la migrazione e dispone di metodi alternativi verificati, può essere rimosso dallo scope di SMS e chiamate vocali.
Chiusura
Prima del 1° febbraio 2027 occorre verificare che nessun utente dipenda esclusivamente dal servizio telefonico fornito da Microsoft. Le eccezioni che devono continuare a usare SMS o voce dovranno disporre di un provider configurato e testato, mentre helpdesk e utenti dovranno conoscere le procedure da seguire in caso di perdita, revoca o indisponibilità della credenziale principale.
Considerazioni finali
Il cambiamento previsto per Microsoft Entra MFA nel 2027 richiede un inventario che non si limiti agli accessi recenti, perché un utente può risultare ancora abilitato per SMS o chiamate vocali anche se utilizza abitualmente Microsoft Authenticator o Windows Hello for Business. La valutazione deve quindi combinare lo scope delle policy, i metodi registrati, l’utilizzo effettivo e la capacità di recupero dell’account, così da individuare sia gli utenti ancora dipendenti dai canali telefonici sia quelli che dispongono già di un’alternativa adeguata.
Il 1° settembre 2026 rappresenta la prima scadenza operativa, con l’abilitazione delle passkey e l’aggiornamento della Registration campaign per gli utenti interessati, mentre dal 1° febbraio 2027 terminerà la consegna Microsoft di SMS e chiamate vocali. Avviare il pilota nel 2026 consente di verificare compatibilità, procedure di registrazione e scenari di recovery, oltre ad aggiornare in tempo utile le attività del service desk, evitando di concentrare la migrazione nelle settimane immediatamente precedenti alla scadenza.
