Argo's New Dreams

TL;DR — Da inizio novembre 2026 il reset password self-service (SSPR) di Microsoft Entra ID accetta solo metodi di autenticazione registrati: telefono ed email presenti nel profilo ma mai registrati smettono di valere. Il Message Center MC1325414 fissa l’avvio dell’enforcement al 7 novembre e chiede di agire prima del 9 novembre 2026. Chi non ha metodi registrati non potrà più reimpostare la password da solo.

<

p class=”wp-block-paragraph”>Nella mia esperienza il reset della password è il processo più sottovalutato di un tenant Microsoft 365. Lo si configura una volta, al momento della migrazione, si spunta “abilitato per tutti”, si lascia che Entra Connect sincronizzi il cellulare dall’Active Directory e non ci si pensa più. Funziona, quindi nessuno lo guarda. Il problema è che in molti tenant “funziona” perché il sistema si fida di un numero di telefono scritto in un attributo anni fa, magari da un collega che non lavora più lì, e che nessuno ha mai verificato. Microsoft ha deciso che quella fiducia implicita finisce a novembre. Non è una legge, è un cambio di prodotto. Ma tocca esattamente il punto in cui identità, help desk e misure di sicurezza NIS2 si incontrano, e per questo l’ho scelto come tema della settimana.

Che cosa cambia nel reset password di Entra ID a novembre 2026?

Il reset password self-service di Microsoft Entra ID accetterà per la verifica dell’identità solo metodi di autenticazione registrati esplicitamente. Gli attributi di directory mobilePhone, businessPhone e otherMails, se non sono mai stati registrati come metodi, non varranno più. Secondo MC1325414 l’enforcement inizia il 7 novembre 2026 e l’azione è richiesta prima del 9 novembre 2026 (Microsoft, 2026a).

Il messaggio, pubblicato il 28 maggio 2026 e aggiornato il 4 agosto 2026, è classificato “Major change” con impatto su utenti e amministratori. Il testo spiega la ragione: oggi SSPR “may allow users to verify their identity using contact information stored in directory attributes such as mobile phone, business phone, and alternate email, even if those values were never explicitly registered as authentication methods” (Microsoft, 2026a). Il cambio rientra nella Secure Future Initiative, il programma con cui Microsoft sta chiudendo una per una le scorciatoie di autenticazione ereditate dal passato. Riguarda tutti i tenant con SSPR abilitato, amministratori compresi, nel cloud pubblico e nei cloud governativi statunitensi.

Per chi non mastica il gergo: un attributo di directory è un campo del profilo utente, come il numero di cellulare, compilato da un amministratore o sincronizzato dall’Active Directory locale. Un metodo di autenticazione registrato è invece un fattore che l’utente ha configurato e confermato di persona, per esempio l’app Microsoft Authenticator, un SMS verificato o una passkey. La differenza è tutta qui: il primo è un dato, il secondo è una prova di possesso.

Quali sono le date esatte, e perché le fonti non coincidono?

Il calendario di MC1325414 aggiornato al 4 agosto 2026 prevede: campagna di registrazione dal 5 ottobre 2026, avvio dell’enforcement il 7 novembre 2026, rilascio completo tra inizio e metà novembre, data “Act by” al 6 novembre e azione richiesta prima del 9 novembre 2026. La data prudente da usare in pianificazione è quindi il 6 novembre (Microsoft, 2026a).

Data	Cosa succede	Fonte
28 maggio 2026	Prima pubblicazione di MC1325414 (enforcement inizialmente previsto a settembre)	MC1325414
4 agosto 2026	Aggiornamento del calendario: date spostate a ottobre-novembre	MC1325414
5 ottobre 2026	Parte la campagna di registrazione che invita utenti e amministratori a registrare i metodi mancanti	MC1325414
6 novembre 2026	Data “Act by” indicata nel Message Center	MC1325414
7 novembre 2026	Inizio dell’enforcement: niente più attributi di directory non registrati	MC1325414
9 novembre 2026	Termine entro cui il messaggio chiede di aver completato le azioni	MC1325414

La confusione ha tre origini. La prima è il doppio slittamento: l’archivio del Message Center registra sei versioni del messaggio, “Updated 5 times since May 28, 2026”, e molti articoli pubblicati in estate riportano ancora settembre (Microsoft 365 Message Center Archive, 2026). La seconda è che lo stesso messaggio usa due date diverse, 7 e 9 novembre. La terza è una pagina di Microsoft Learn sulla prepopolazione dei dati di contatto per SSPR che, al momento della mia verifica, riporta le due date invertite: campagna “Starting Nov 9, 2026” ed enforcement “Starting Oct 5, 2026” (Microsoft Learn, 2026a) [VERIFY: inversione delle date nella pagina Learn “Prepopulate user authentication contact information for SSPR” rispetto a MC1325414 – fonte: Microsoft Learn, verifica successiva al 21/10/2026]. Nella mia esperienza, quando la documentazione di un vendor si contraddice, si pianifica sulla data più vicina. Qui significa chiudere il lavoro entro il 6 novembre.

Chi rischia di restare chiuso fuori?

Rischiano gli utenti di tenant con SSPR attivo che oggi riescono a reimpostare la password solo grazie a un numero o a un’email presenti nel profilo ma mai registrati come metodo. Microsoft stima che circa l’86% delle verifiche SSPR usi già metodi registrati; il restante 14% circa dipende dal fallback che verrà rimosso (Microsoft, 2026a).

Il 14% è una mia sottrazione dal dato Microsoft, non un numero pubblicato: va letto come ordine di grandezza sulle verifiche, non sugli utenti. Il testo di MC1325414 descrive l’effetto con precisione: gli utenti senza metodi registrati al momento dell’enforcement saranno “Unable to complete password resets” e verranno invitati a registrare un metodo o a contattare un amministratore (Microsoft, 2026a). Le categorie tipiche, secondo le analisi dei consulenti che stanno lavorando sui tenant, sono sempre le stesse: il titolare che non ha mai completato la configurazione, gli account condivisi, il personale operativo che accede di rado da browser (NetSys Group, 2026). Aggiungo dalla mia esperienza gli account sincronizzati da domini locali in cui il campo mobile è stato popolato in blocco durante una migrazione e mai più toccato.

C’è un effetto collaterale che pochi considerano. Ogni reset che non passa più dal self-service diventa una telefonata all’help desk, e la telefonata all’help desk è esattamente il canale preferito dagli attaccanti che si fingono un dipendente bloccato. Più chiamate significa più occasioni di social engineering, se la procedura di verifica dell’identità al telefono è debole.

Come si trovano gli utenti esposti prima del 7 novembre?

Gli utenti esposti si individuano nel Microsoft Entra admin center, in Authentication methods, User registration details, filtrando chi ha SSPR abilitato ma non risulta registrato. MC1325414 indica proprio questo percorso e chiede che ogni utente, amministratori inclusi, abbia almeno un metodo registrato che soddisfi la policy SSPR (Microsoft, 2026a).

Per chi preferisce la riga di comando, una delle guide operative pubblicate in questi giorni suggerisce una query Microsoft Graph PowerShell che restituisce l’elenco da sanare (NetSys Group, 2026):

Get-MgReportAuthenticationMethodUserRegistrationDetail -All -Filter "isSsprEnabled eq true and IsSsprRegistered eq false"

Il comando va eseguito con un account che abbia i permessi di lettura dei report di autenticazione; consiglio di provarlo prima su un tenant di test. Un dettaglio che conta: se la policy SSPR richiede due metodi, un solo metodo registrato non basta. Il controllo va fatto confrontando quanti metodi la policy esige con quanti l’utente ne ha davvero, non limitandosi al flag “registrato sì/no”.

Cosa fare in pratica, in ordine di priorità?

La sequenza che seguirei è: estrarre l’elenco degli utenti non registrati, verificare che la campagna di registrazione sia attiva e configurata, riallineare la policy SSPR, rafforzare la verifica dell’identità al telefono per l’help desk e, se non è già fatto, completare la migrazione alla Authentication methods policy unificata.

1. Estrarre l’elenco. Report o query Graph come sopra. Nella maggior parte dei tenant di PMI la lista è corta; il lavoro vero è contattare le persone.
2. Governare la campagna. La campagna Microsoft è partita il 5 ottobre per gli utenti la cui policy richiede la registrazione; configurarla in proprio permette di controllare chi viene invitato e quante volte si può rimandare (Microsoft, 2026a; NetSys Group, 2026).
3. Riallineare la policy. Verificare quanti metodi la policy SSPR richiede e quali sono abilitati. È l’occasione per spingere verso Microsoft Authenticator o passkey invece dell’SMS.
4. Proteggere l’help desk. Scrivere o aggiornare la procedura di verifica dell’identità per i reset telefonici: richiamata su numero noto, conferma del responsabile, Temporary Access Pass invece di password comunicate a voce.
5. Chiudere la migrazione. Microsoft Learn descrive una procedura guidata che consolida le impostazioni legacy di MFA e SSPR nella Authentication methods policy ed è “fully reversible” (Microsoft Learn, 2026b).
6. Documentare. Salvare report prima e dopo, con data: serve come evidenza interna e, per i soggetti NIS2, come prova di una misura di controllo degli accessi effettivamente gestita.

Un appunto sulle statistiche che girano in questi casi. Microsoft afferma, nella pagina sull’MFA obbligatoria per Azure, che “MFA can block more than 99.2% of account compromise attacks” (Microsoft Learn, 2026c). È un dato del vendor, non una misura indipendente, ma indica la direzione: un metodo registrato e verificato è la base su cui si costruisce tutto il resto, reset password compreso.

Che cosa c’entra un cambio di Entra ID con la NIS2?

Il cambio non è un obbligo NIS2, ma tocca un’area che le misure di sicurezza di base dell’ACN disciplinano: gestione delle identità, delle credenziali e dell’autenticazione. Per i soggetti NIS2 della prima coorte, che dovevano rendere operative le misure di base entro ottobre 2026, un processo di reset che si fida di attributi non verificati è un punto debole difficile da giustificare [VERIFY: requisiti PR.AA della Determinazione ACN 379907/2025 applicabili a credenziali e autenticazione – fonte: Determinazione ACN 379907/2025, Allegati 1 e 2].

Ho scritto la settimana scorsa cosa deve essere pronto e dimostrabile per le misure di base NIS2, e il pezzo sulle scadenze Windows del 13 ottobre seguiva la stessa logica: una decisione di prodotto del vendor diventa, per chi è soggetto a una norma, un tema di conformità. Qui il ragionamento è identico. Per chi invece non è soggetto NIS2 resta un fatto banale: il 7 novembre alcuni utenti non riusciranno più a reimpostare la password da soli, e il lunedì successivo il telefono dell’IT squillerà. Cosa dice la norma e cosa conviene fare nel singolo caso restano due piani distinti, e il secondo spetta a un professionista che conosca l’organizzazione.

Implicazioni pratiche per le PMI italiane

Nella mia esperienza la PMI italiana tipica ha un tenant Microsoft 365 configurato da un partner anni fa, SSPR attivo “perché era consigliato”, Entra Connect che sincronizza i dati anagrafici dall’AD locale e nessuno che guardi il report di registrazione dei metodi. È lo scenario in cui il fallback sugli attributi di directory ha lavorato in silenzio, ed è lo scenario che il 7 novembre si scopre.

L’opportunità è concreta e costa poco: in un’ora si estrae l’elenco, in una settimana si contattano le persone, e nel frattempo si può portare l’organizzazione su metodi più robusti dell’SMS. MC1325414 non indica licenze aggiuntive tra le azioni richieste. L’hype da evitare è doppio. Da un lato chi lo presenta come un’emergenza che richiede un progetto di “identity transformation”; dall’altro chi lo liquida come una modifica cosmetica. I dati Microsoft dicono che la grande maggioranza delle verifiche è già conforme: il lavoro è circoscritto, ma chi resta fuori resta fuori davvero. Il rischio vero non è tecnico, è organizzativo: un help desk che, sotto pressione, resetta password al telefono senza verificare chi chiama.

Da quando Entra ID SSPR accetta solo metodi registrati?

Secondo il Message Center MC1325414, aggiornato il 4 agosto 2026, l’enforcement inizia il 7 novembre 2026 con rilascio completo tra inizio e metà novembre; la data “Act by” è il 6 novembre e il messaggio chiede di agire prima del 9 novembre 2026. La campagna di registrazione è partita il 5 ottobre 2026.

Il numero di cellulare sincronizzato da Active Directory vale ancora per il reset?

No, se non è mai stato registrato come metodo di autenticazione. Dopo l’enforcement gli attributi mobilePhone, businessPhone e otherMails, sincronizzati da Entra Connect o inseriti da un amministratore, non sono più validi per la verifica SSPR. Valgono solo se l’utente ha registrato lo stesso numero o la stessa email come metodo.

Cosa succede a un utente senza metodi registrati dopo il 7 novembre 2026?

Non riesce a completare il reset self-service della password. Secondo MC1325414 viene invitato a registrare un metodo o a contattare un amministratore. In pratica il reset passa all’help desk, che deve verificare l’identità di chi chiama prima di intervenire, per esempio con richiamata su numero noto o Temporary Access Pass.

Serve una licenza aggiuntiva per adeguarsi?

Il Message Center MC1325414 non indica requisiti di licenza aggiuntivi: le azioni richieste sono verificare la copertura di registrazione nel Microsoft Entra admin center, abilitare la campagna di registrazione, prevedere percorsi assistiti per chi non può registrarsi da solo e comunicare il cambio a help desk e utenti.

Conclusioni

Questo cambio è piccolo nel codice e grande nelle abitudini. Microsoft smette di fidarsi di un dato che nessuno ha verificato, e ha ragione: un numero di telefono in un campo anagrafico non dimostra nulla su chi lo possiede oggi. La mia posizione è che sia una buona notizia travestita da seccatura. Obbliga a guardare il report di registrazione dei metodi, spinge verso fattori più robusti e mette sotto i riflettori l’anello debole che nessuna policy tecnica copre, cioè la telefonata all’help desk. Non c’è una legge che scade il 7 novembre. C’è un comportamento del sistema che cambia, e per chi deve dimostrare di gestire gli accessi, NIS2 o non NIS2, è la stessa cosa. Il consiglio è semplice: elenco entro fine ottobre, persone contattate entro il 6 novembre, procedura dell’help desk scritta prima che serva.

Riferimenti

Fonti verificate al 21 ottobre 2026.

• Microsoft. (2026a, 28 maggio; aggiornato 4 agosto). MC1325414 – Microsoft Entra ID SSPR will require registered authentication methods starting November 9, 2026. Microsoft 365 Message Center, consultato tramite il Microsoft 365 Message Center Archive (mc.merill.net), che ne conserva anche la cronologia delle versioni. Livello B (testo Microsoft) / C (archivio di terzi). mc.merill.net/message/MC1325414
• Microsoft Learn. (2026a). Prepopulate user authentication contact information for Microsoft Entra self-service password reset (SSPR). Livello B. learn.microsoft.com/en-us/entra/identity/authentication/howto-sspr-authenticationdata
• Microsoft Learn. (2026b). How to migrate MFA and SSPR policy settings to the Authentication methods policy for Microsoft Entra ID. Livello B. learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage
• Microsoft Learn. (2026c). Plan for mandatory Microsoft Entra multifactor authentication (MFA). Livello B. learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication
• Microsoft Entra Blog. (2026, 8 giugno; aggiornato 4 agosto). Microsoft Entra ID security updates: What organizations need to do now. Livello B. Citato da fonte secondaria, non consultato direttamente. [verificare URL]
• Agenzia per la Cybersicurezza Nazionale. (2025). Determinazione n. 379907/2025 – Specifiche di base NIS (Allegati 1 e 2). Livello B. [verificare URL]
• Mirage Informatique. (2026, 5 agosto). Entra ID Security Updates 2026: Three Deadlines to Check Now. Livello C. mirageinfo.ca/blog/entra-id-deadlines-2026-checklist
• Reed, L. (2026, 23 settembre; aggiornato 10 ottobre). Entra ID SSPR Change: Register Methods Before Nov 7. The NetSys Group. Livello C. netsysgroup.com/blog/entra-id-sspr-registered-methods-2026

Link correlati su Argos New Dreams

• NIS2, misure di sicurezza di base entro ottobre 2026: cosa deve essere pronto (e dimostrabile)
• 13 ottobre 2026: il Patch Tuesday che chiude Windows 11 24H2, il mainstream di Server 2022 e l’ESU di Server 2012 R2
• NIS2: le nuove FAQ ACN, cosa deve approvare il CdA

Trasparenza sull’uso dell’intelligenza artificiale
Questo articolo è stato redatto con l’assistenza di un sistema di intelligenza artificiale generativa (Claude Sonnet 5, tramite l’agente Argos Newsroom su Microsoft Copilot Studio) per la ricerca delle fonti, la strutturazione e la prima stesura. Il testo è stato successivamente verificato, corretto e approvato da un autore umano, Luca Borio, che ne detiene la responsabilità editoriale ai sensi dell’art. 50 del Regolamento (UE) 2024/1689. Dati, citazioni e link sono stati controllati sulle fonti originali indicate. Eventuali errori residui sono miei.

⚠️ Nessuna consulenza professionale
Questo contenuto ha finalità divulgativa e informativa. Non costituisce consulenza legale, fiscale, sanitaria, finanziaria o giuslavoristica, né sostituisce il parere di un professionista abilitato. Le norme citate sono riportate nella versione vigente alla data di pubblicazione e possono essere modificate: verifica sempre il testo aggiornato sulle fonti ufficiali (per il diritto italiano, Normattiva — https://www.normattiva.it ; per l’AI Act, il portale ufficiale UE — https://artificialintelligence-act.ec.europa.eu/ ). Per la valutazione di un caso concreto rivolgiti a un professionista.