SMS e voce escono da Entra ID.
E la seconda data non si rinvia.

Microsoft ha deciso due cose distinte, e conviene tenerle separate. La prima: le passkey diventano l’esperienza di autenticazione predefinita in Microsoft Entra ID. La seconda, quella che conta davvero: SMS e chiamata vocale non saranno più forniti nativamente da Entra ID. Non è un incoraggiamento a modernizzare — è la rimozione di un metodo che oggi, in tante aziende, è l’unico secondo fattore configurato.

Le quattro date da segnare

Il 1 settembre si può rinviare. Il 1 febbraio no.

È la distinzione che rischia di costare più cara, perché la prima data è morbida e induce a rilassarsi. Il 1 settembre gli utenti abilitati a SMS o voce vengono messi in un profilo che consente tutti i tipi di passkey, e la campagna di registrazione li prende in carico automaticamente: al primo accesso con MFA vedono l’invito a registrarne una. Per impostazione predefinita quell’invito si rinvia un numero illimitato di volte. In pratica, la maggior parte degli utenti clicca «più tardi» e la cosa finisce lì.

Il 1 febbraio 2027 il comportamento cambia natura. Chi a quella data ha come unico metodo MFA disponibile SMS o chiamata vocale riceve al login una richiesta di registrazione della passkey che non si può più rinviare: senza completarla, non si entra. Microsoft lo scrive senza ambiguità — per la scadenza di febbraio non esiste opt-out e la regola si applica a tutti i tenant. Nessuno viene chiuso fuori definitivamente dal proprio account, ma di fatto la mattina del 1 febbraio una parte del personale si troverà davanti a una registrazione obbligatoria mai vista prima, senza preavviso e senza sapere cosa fare.

La trappola: quando «nessuna azione richiesta» è una risposta sbagliata

Microsoft mette a disposizione uno script per censire chi nel tenant usa ancora SMS o voce, eseguibile con i ruoli di lettore globale, amministratore delle policy di autenticazione o lettore di sicurezza. È il punto di partenza giusto, ma il suo esito va letto con prudenza: lo script guarda la policy moderna dei metodi di autenticazione.

Se il tenant non ha completato la migrazione da quella legacy — lo stato che il portale chiama «migration not started» — SMS e voce possono risultare disattivati nella policy moderna mentre gli utenti continuano a usarli attraverso le vecchie impostazioni MFA per singolo utente. Lo script restituisce un tranquillo «nessuna azione richiesta» e il tenant sembra a posto. Ma la documentazione Microsoft mette in perimetro gli utenti abilitati a SMS o voce nella policy dei metodi di autenticazione oppure nelle impostazioni MFA legacy. Il conto arriva a febbraio.

La verifica da fare prima di fidarsi del censimento è una sola: controllare lo stato della migrazione in Entra ID, sotto Protezione, Metodi di autenticazione, Gestisci migrazione. Se non è «Migration complete», il tenant vive in uno stato misto e l’inventario va rifatto guardando i metodi effettivamente registrati dagli utenti, non le impostazioni della policy.

Il telefono personale, e il GDPR dentro la soluzione ovvia

Qui la questione smette di essere tecnica. Lo scenario che si incontra più spesso nelle aziende di medie dimensioni è questo: l’MFA è attivo, il secondo fattore è un SMS, e il numero su cui arriva è il numero personale del dipendente. Microsoft Authenticator non è mai stato distribuito, e la ragione è sempre la stessa — non ci sono telefoni aziendali, quindi l’app dovrebbe finire sul dispositivo privato di qualcuno.

La reazione istintiva alla notizia sarà «allora installiamo Authenticator». Vale la pena fermarsi un momento, perché quella scelta porta con sé un aspetto che raramente viene valutato. Se in Conditional Access si usano le named location basate su GPS, Authenticator chiede il permesso di localizzazione in modalità «always allow» e il sistema raccoglie la posizione del telefono ogni ora — anche in modalità report-only. Su un dispositivo personale significa un flusso continuo di dati di posizione di un dipendente, con tutto quello che comporta in termini di base giuridica e proporzionalità del trattamento. Microsoft stessa raccomanda di riservare quelle policy alle applicazioni molto sensibili. Il number matching normale, per chiarezza, non fa nulla di tutto questo: mostra una posizione approssimativa ricavata dall’indirizzo IP, non le coordinate del telefono.

Il punto interessante è che la migrazione forzata offre l’occasione di uscire dal problema invece di spostarlo. Una passkey su dispositivo aziendale o una chiave di sicurezza FIDO2 assegnata alla persona chiudono la questione all’origine: nessuna applicazione sul telefono privato, nessuna geolocalizzazione, nessun numero personale dentro i sistemi aziendali. Chi sta ragionando in ottica NIS2 ha in più un argomento solido: il metodo di autenticazione diventa un asset aziendale governabile, non un favore chiesto al dipendente.

Chi non ha smartphone, e chi lavora su Mac

Entra ID supporta due famiglie di passkey: quelle sincronizzate, salvate in un gestore di credenziali di piattaforma come iCloud Keychain o Google Password Manager e disponibili su tutti i dispositivi della persona, e quelle device-bound, che restano sul singolo dispositivo — passkey in Microsoft Authenticator, passkey Entra su Windows, chiavi di sicurezza FIDO2. Nessuna categoria di personale resta senza soluzione, ma le strade non sono equivalenti.

• Chi non ha uno smartphone, o non vuole app aziendali sul proprio — una chiave di sicurezza FIDO2 fisica, acquistata dall’azienda e assegnata alla persona. Nessuna licenza aggiuntiva, nessun dato raccolto dal dispositivo privato. È anche la scelta più solida per gli account amministrativi.
• Postazioni Windows — la passkey Entra sul dispositivo stesso, oppure Windows Hello for Business dove è già in uso. Chi ha già un deployment FIDO2 avviato è a metà del lavoro: abbiamo descritto la procedura completa nell’articolo su login a Windows senza password con FIDO2.
• Mac — tre strade, con implicazioni diverse. La passkey con Touch ID non richiede licenze e non richiede uno smartphone, ma resta legata all’Apple ID personale della persona, quindi riporta il problema dell’asset privato. Una chiave FIDO2 aziendale separa nettamente l’identità. Il Platform SSO con Secure Enclave è la soluzione gestita e device-bound, concettualmente analoga a Windows Hello for Business, ma richiede Intune.

Cosa fare adesso

• 1Censire chi usa SMS o voce, e verificare lo stato della migrazione — nell’ordine giusto. Prima si controlla se il tenant è in «Migration complete»; solo allora l’esito del censimento è affidabile.
• 2Decidere il metodo per ogni gruppo di personale prima di settembre — chi ha un dispositivo aziendale, chi lavora su Mac, chi non ha smartphone, chi ha ruoli privilegiati. Sono scelte diverse, e vanno fatte prima che gli utenti comincino a vedere prompt inattesi.
• 3Avviare la campagna di registrazione in modo controllato — abilitando prima Passkey (FIDO2) come metodo e mettendo nel perimetro il gruppo di sicurezza degli utenti SMS e voce, invece di farsi trovare dall’attivazione automatica di settembre. Non richiede licenze aggiuntive.
• 4Comunicare prima, non durante — Microsoft indica la comunicazione coordinata come il singolo fattore che più determina la riuscita del passaggio, e mette a disposizione modelli per email e Teams. Un avviso mandato dopo il primo prompt è già una chiamata all’assistenza in più.
• 5Valutare un provider telefonico solo per esigenze documentate — se esiste un vincolo regolatorio od operativo che impone un canale telefonico fuori banda, va scritto quale, per quale gruppo di utenti e su quale norma si fonda. Le informazioni sui provider arrivano dal 18 settembre, la configurazione dal 30 ottobre, e il costo dei messaggi passa a carico dell’azienda.

Cosa serve per governarlo davvero

Vale la pena essere precisi su un punto che nella comunicazione entusiasta sulle passkey si perde. Per abilitare le passkey e per lanciare una campagna di registrazione non serve alcuna licenza aggiuntiva: basta avere l’MFA attivo. Ma offrire un metodo e governarlo sono due cose diverse.

Imporre un metodo phishing-resistant per le applicazioni sensibili o per i ruoli amministrativi, escludere i metodi deboli in determinati contesti, differenziare le regole per gruppo: sono authentication strengths, cioè funzionalità di Conditional Access, e Conditional Access richiede Entra ID P1. Senza P1 si possono abilitare o disabilitare i metodi a livello di tenant e invitare gli utenti a registrarsi, ma non scrivere regole: restano i security defaults, un MFA generico tutto-o-niente. Per molte aziende questa scadenza sarà, di fatto, il momento in cui la domanda sulle licenze torna sul tavolo — ed è meglio affrontarla adesso che a gennaio.

Un ultimo chiarimento di perimetro, perché genera confusione: Azure AD B2C non è interessato da questo annuncio. Per Microsoft Entra External ID il cambiamento è previsto l’anno prossimo, con una comunicazione separata.