Wi-Fi aziendale 802.1X non si connette dopo KB5127648 su Windows 11: la soluzione

Articolo aggiornato al 15 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se Microsoft rilascia nuove correzioni.

I portatili aziendali la mattina dopo il Patch Tuesday non si collegano più al Wi-Fi dell’ufficio? L’icona resta su “Connessione in corso”, poi compare “Impossibile connettersi a questa rete”, mentre lo stesso PC si collega senza problemi all’hotspot del telefono o alla rete ospiti. In alcune aziende si fermano anche le postazioni fisse sulle porte di rete con autenticazione 802.1X.

In questi giorni stanno arrivando molte segnalazioni che puntano tutte all’aggiornamento cumulativo di ottobre per Windows 11, KB5127648. Disinstallandolo il problema sparisce, reinstallandolo ritorna. La causa più probabile non è un bug in senso stretto, ma una modifica di sicurezza annunciata da Microsoft più di un anno fa e che, per chi non ha impostato nulla, è diventata attiva adesso.

Chi è coinvolto

PC con Windows 11 24H2, 25H2 o 26H2 con installato KB5127648 (build 26100.9711, 26200.9711 e 26300.9711).
Reti WPA2/WPA3-Enterprise o porte cablate 802.1X che usano PEAP con MS-CHAPv2, cioè utente e password di dominio, tipicamente con NPS come server RADIUS.
Profili configurati per l’accesso automatico con le credenziali di Windows (opzione “Usa automaticamente il nome utente e la password di accesso a Windows”), spesso distribuiti via GPO o Intune.

Le reti con password condivisa (WPA2/WPA3-Personal) non sono toccate, così come chi usa già EAP-TLS con certificati.

Perché succede

Nell’agosto 2025 Microsoft ha pubblicato un avviso sulle modifiche a NTLMv1 in Windows 11 24H2 e Windows Server 2025. NTLMv1 è già stato rimosso, ma MS-CHAPv2 usa ancora credenziali derivate da NTLMv1 per fare il single sign-on su Wi-Fi, Ethernet e VPN. Per bloccarle è stato introdotto il valore di registro BlockNtlmv1SSO sotto HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0: con 0 la richiesta viene solo registrata nei log (audit), con 1 viene bloccata.

Il calendario di Microsoft prevedeva il passaggio predefinito da audit a blocco a ottobre 2026, ma solo sui PC dove il valore non è stato impostato esplicitamente. È esattamente quello che si vede: il client blocca l’accesso automatico prima ancora di parlare con il RADIUS, e infatti nei log di NPS non compare nulla. Microsoft, al momento in cui scrivo, non ha inserito il problema tra i problemi noti di KB5127648, quindi il collegamento resta una deduzione, confermata però dal fatto che la correzione sul registro funziona.

Prima di iniziare

Verificate che sia davvero questo il caso, prima di disinstallare aggiornamenti o reimpostare schede di rete (che non serve a niente). Su un PC che non si collega aprite il Visualizzatore eventi:

Registri applicazioni e servizi → Microsoft → Windows → NTLM → Operational: l’evento 4025 indica che una richiesta di credenziali derivate da NTLMv1 è stata bloccata dalla policy. È la prova regina.
WLAN-AutoConfig → Operational: autenticazione avviata (12011) seguita da timeout (12014) o da un errore 12013 con codice 0x80070285.

Dal prompt dei comandi potete controllare anche il valore attuale; se la chiave non esiste, il PC sta usando il nuovo comportamento predefinito:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO

Attenzione: se sui PC è attivo Credential Guard questa modifica non cambia nulla, perché con Credential Guard l’accesso automatico tramite MS-CHAPv2 non è comunque supportato. In quel caso il problema ha un’altra origine.

Come ripristinare la connessione

Io preferisco intervenire sul registro piuttosto che disinstallare l’aggiornamento: KB5127648 corregge anche una vulnerabilità di Windows Shell già sfruttata attivamente, e rinunciarvi per il Wi-Fi è un cattivo scambio. La modifica riporta il comportamento in modalità audit, cioè com’era fino al mese scorso, ed è reversibile.

Esportate la chiave per avere una copia da cui tornare indietro.
Da un prompt dei comandi aperto come amministratore impostate il valore a 0:

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" %USERPROFILE%\MSV1_0-backup.reg
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

Riavviate il PC e verificate la connessione. Nel registro NTLM dovreste ora vedere l’evento 4024 (richiesta registrata ma consentita) al posto del 4025.

Il problema è che un PC senza rete aziendale non riceve le GPO. Per i portatili già bloccati serve un passaggio intermedio: collegateli via cavo su una porta senza 802.1X, alla rete ospiti con VPN o all’hotspot, oppure fate l’intervento a mano. In alternativa l’utente può connettersi inserendo manualmente DOMINIO\mario.rossi e password nella finestra del Wi-Fi: l’avviso di Microsoft indica che l’inserimento manuale continua a funzionare, anche se alcuni amministratori riferiscono che nel loro caso non è bastato.

Per distribuire la modifica su tutti i client di dominio usate le preferenze di Criteri di gruppo: Configurazione computer → Preferenze → Impostazioni di Windows → Registro di sistema, nuovo elemento di tipo REG_DWORD con hive HKEY_LOCAL_MACHINE, percorso SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, nome BlockNtlmv1SSO e valore 0. Collegate la GPO a un’unità organizzativa di prova prima di estenderla a tutti. Con Intune la strada più semplice è uno script di correzione in PowerShell eseguito come sistema.

Solo se non potete toccare il registro, l’alternativa è disinstallare l’aggiornamento e sospendere la sua distribuzione in WSUS o negli anelli di Windows Update:

wusa /uninstall /kb:5127648

Lo sconsiglio come soluzione stabile: oltre a lasciare scoperta la vulnerabilità, il mese prossimo il problema si ripresenterà con il nuovo cumulativo.

La soluzione vera: passare a EAP-TLS

Attenzione: BlockNtlmv1SSO=0 compra tempo, non risolve. Microsoft ha già chiarito che l’obiettivo è eliminare le credenziali derivate da NTLMv1, e non è detto che la modalità audit resti disponibile a lungo. PEAP con MS-CHAPv2 è un metodo nato vent’anni fa, basato sulla password dell’utente: va sostituito con EAP-TLS, dove PC e utenti si autenticano con certificati e NTLM non entra in gioco.

In una PMI con Active Directory il percorso tipico è: una CA aziendale con Servizi certificati di Active Directory, un modello di certificato computer distribuito con l’autoregistrazione via GPO, una nuova policy di rete su NPS con metodo “Smart card o altro certificato” e un nuovo profilo Wi-Fi. Io consiglio di tenere attivo il vecchio SSID PEAP finché tutti i dispositivi non hanno il certificato, e solo dopo spegnerlo.

Se il problema persiste

Controllate di aver riavviato: il valore viene letto all’avvio.
Verificate con gpresult /r che la GPO sia effettivamente applicata e che nessun’altra policy imposti il valore a 1.
Se nel registro NTLM non c’è nessun evento 4025, guardate i log di NPS (eventi 6272 e 6273): se la richiesta arriva e viene rifiutata, il problema è altrove, ad esempio nel certificato del server RADIUS.

Vi è capitato di trovarvi con i portatili scollegati dopo questo aggiornamento? Raccontate nei commenti come lo avete risolto e se avete già pianificato il passaggio a EAP-TLS: possono essere utili ad altri.