Entra ID SSPR solo metodi registrati novembre 2026: cosa si rompe e come risolverlo

Entra ID SSPR solo metodi registrati novembre 2026: cosa sta cambiando

A partire dal 9 novembre 2026, Microsoft Entra ID SSPR accetterà solo metodi registrati per la verifica di reimpostazione della password — esattamente il cambiamento che l'interesse di ricerca etichetta già come Entra ID SSPR solo metodi registrati novembre 2026. Le informazioni di contatto provenienti dalla directory — gli attributi mobilePhone, businessPhone e otherMails, popolati tramite la sincronizzazione di Microsoft Entra Connect o impostati direttamente da un amministratore — non conteranno più come verifica SSPR valida, a meno che l'utente non abbia registrato esplicitamente quello stesso numero di telefono o indirizzo email come metodo di autenticazione.

Si tratta di un inasprimento silenzioso ma con conseguenze rilevanti. Molti tenant si sono affidati ad attributi di contatto sincronizzati o impostati da un amministratore come fallback SSPR implicito, poiché questi valori consentono a un utente di reimpostare una password dimenticata anche se non ha mai completato il flusso di registrazione dei metodi di autenticazione di Microsoft — un comportamento che oggi stesso conferma la documentazione ufficiale di Microsoft sulla precompilazione dei dati di contatto SSPR. Secondo l'avviso di rollout di Microsoft (messaggio del Message Center MC1325414), circa l'86% delle verifiche SSPR utilizza già oggi metodi registrati — il che significa anche che una minoranza significativa dei reset riesce attualmente solo grazie a questo fallback in via di rimozione.

Microsoft sta implementando il cambiamento in due fasi con date precise, confermate nell'articolo di Microsoft Learn citato sopra e nel messaggio MC1325414:

• 5 ottobre 2026 — parte una campagna di registrazione integrata che sollecita gli utenti con sessione attiva e gli amministratori che non hanno ancora abbastanza metodi registrati a completare l'SSPR secondo la propria policy. Non è richiesta alcuna azione amministrativa per attivarla.
• 9 novembre 2026 — applicazione: la verifica SSPR accetta solo metodi esplicitamente registrati. I numeri di telefono e gli indirizzi email di directory non registrati smettono di funzionare, punto.

Il blog di Microsoft Entra presenta questo come la chiusura di una lacuna di lunga data: l'SSPR non avrebbe mai dovuto fidarsi di attributi di cui nessuno ha verificato la proprietà. Un numero di telefono sincronizzato da un campo telephoneNumber/mobile on-prem, o digitato nel profilo di un utente da un amministratore durante l'onboarding, può essere obsoleto, riassegnato o semplicemente errato — e finora poteva comunque reimpostare la password di quell'utente.

Questo si inserisce in un'ondata più ampia di cambiamenti nell'autenticazione Entra di quest'anno, insieme alla dismissione della MFA SMS/voce a favore delle passkey e al ritiro dei controlli personalizzati in Conditional Access — nessuno dei quali è opzionale da ignorare se il vostro tenant si affida ancora a fallback di autenticazione legacy.

Rilevamento

Poiché oggi i metodi registrati e non registrati funzionano in modo identico per l'SSPR, non esiste alcun evento nel log di accesso che segnali «questo reset ha usato un metodo non registrato» — la lacuna diventa visibile solo se si inventaria direttamente la copertura di registrazione, prima del cutover del 9 novembre.

Interrogatelo direttamente con Microsoft Graph PowerShell:

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

Get-MgReportAuthenticationMethodUserRegistrationDetail -All `
  -Filter "isSsprEnabled eq true and isSsprCapable eq false" |
  Select-Object UserPrincipalName, IsSsprRegistered, IsSsprCapable, MethodsRegistered

Oppure la chiamata Graph REST equivalente:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=isSsprCapable eq false and isSsprEnabled eq true

Ogni utente restituito da questa query è qualcuno che oggi può reimpostare la password tramite un attributo di directory, e non potrà più farlo il 9 novembre — un picco di richieste all'help desk pronto a scattare se non viene risolto per tempo.

Correzione

1. Fate subito l'inventario. Estraete il report completo userRegistrationDetails e isolate ogni account abilitato per l'SSPR in cui isSsprCapable è false. Date priorità agli account con ruoli privilegiati — un amministratore escluso dall'SSPR ha un percorso di recupero molto più costoso. La nostra guida per l'audit della sicurezza di Microsoft Entra ID copre questo report insieme al resto della vostra postura MFA e Conditional Access.
2. Registrate metodi reali, non copie di directory. Fate completare agli utenti interessati il flusso di registrazione combinato MFA/SSPR in modo che un numero di telefono o un'email risulti esplicitamente registrato, non semplicemente presente come attributo di profilo. Registrare mobilePhone come metodo di autenticazione è un'azione una tantum per utente, non automatica. Dove possibile, indirizzate gli utenti verso una passkey come primo metodo registrato invece di telefono/email, poiché soddisfa contemporaneamente i requisiti MFA e SSPR.
3. Confermate il numero di metodi richiesto dalla vostra policy SSPR. In Centro di amministrazione Entra → Metodi di autenticazione → Proprietà di reimpostazione password, verificate quanti metodi richiede la vostra policy. Se è impostato su uno, le lacune di registrazione riguardano meno persone; se è due, le lacune si sommano.
4. Non affidatevi solo alla campagna. La campagna di registrazione del 5 ottobre sollecita solo gli utenti che già mancano di metodi — non compila nulla retroattivamente, e può essere esclusa per gruppi specifici. Comunicate direttamente la scadenza del 9 novembre alla vostra organizzazione, invece di presumere che i solleciti integrati raggiungano tutti in tempo.
5. Rieseguite il report prima del 9 novembre. Confermate che isSsprCapable sia true per ogni utente abilitato per l'SSPR, quindi verificate di nuovo dopo la scadenza per intercettare eventuali ritardatari prima che chiamino l'help desk.

Come EtcSec rileva questo problema

L'audit Entra ID di EtcSec verifica esattamente questo tipo di lacuna di registrazione. AUTH_METHODS_NO_REGISTRATION segnala i tenant che non hanno abilitato la campagna di registrazione dei metodi di autenticazione di Microsoft, SSPR_NOT_ENABLED segnala l'SSPR completamente disattivato, e SSPR_NOT_REQUIRED_ADMINS individua il caso a rischio più elevato — amministratori esentati dai requisiti di registrazione SSPR che stanno per perdere il proprio fallback non registrato insieme a tutti gli altri.