Se os computadores Windows 11 deixaram de se ligar ao Wi‑Fi corporativo após as atualizações de meados de outubro, ou se os utilizadores começaram subitamente a ver pedidos de credenciais que nunca tinham visto antes, não está só. Após a atualização de segurança do Windows de 13 de outubro de 2026, muitos dispositivos associados a um domínio que usam PEAP-MSCHAPv2 com o início de sessão do Windows já não conseguem iniciar sessão automaticamente em Wi‑Fi, 802.1X com fios ou VPN.
Este é um reforço de segurança planeado pela Microsoft. A Microsoft anunciou a alteração em agosto de 2025 como parte do seu esforço para descontinuar o NTLM, e a atualização de outubro ativou-a por predefinição em dispositivos que não tinham sido configurados de uma forma ou de outra.
Este guia explica o que mudou, que dispositivos são afetados, como confirmar que a atualização é a causa e como voltar a ligar os utilizadores hoje. Também aborda a correção que se mantém a longo prazo: mover a autenticação de rede de palavras-passe para certificados com EAP-TLS.
O que mudou com a atualização do Windows de outubro de 2026
A Microsoft removeu o protocolo NTLMv1 do Windows 11 versão 24H2 e do Windows Server 2025. Alguma criptografia NTLMv1 ainda permanece em determinados cenários, mais notavelmente: MS-CHAPv2, o método interno por trás de PEAP-MSCHAPv2 e EAP-MSCHAPv2, quando é executado num ambiente associado a um domínio.
Um valor de registo chamado BlockNtlmv1SSO controla se o Windows permite que essas credenciais derivadas de NTLMv1 sejam usadas para single sign-on. Um valor de 0 (modo de auditoria) permite o pedido e regista um aviso. Um valor de 1 (modo de imposição) bloqueia-o e regista um erro.
A partir da atualização de segurança de 13 de outubro de 2026, o Windows trata a ausência do valor BlockNtlmv1SSO como modo Enforce. A atualização não cria nem altera o valor do registo. Altera o que o Windows faz quando o valor não existe, razão pela qual tantas frotas foram apanhadas de surpresa, apesar de nada ter mudado na Política de Grupo ou no Intune.
Apenas o percurso de início de sessão único está bloqueado. Os utilizadores que introduzem o respetivo nome de utilizador e palavra-passe no pedido podem continuar a ligar-se.
A implementação aconteceu por fases. Os eventos de auditoria começaram a aparecer no Windows 11 24H2 e em versões mais recentes no final de agosto de 2025, a implementação chegou ao Windows Server 2025 em novembro de 2025 e o Enforce passou a ser a predefinição em outubro de 2026. A Microsoft adicionou uma nota sobre a alteração às notas de versão do KB5127648 a 15 de outubro, dois dias após a atualização ter sido lançada, pelo que os administradores que consultaram as notas no dia do lançamento não a encontraram lá.
Versão Windows | Atualização de 13 de outubro de 2026 | Compilação do SO |
Windows 11, versão 26H2 | KB5127648 | 26300.9711 |
Windows 11, versão 25H2 | KB5127648 | 26200.9711 |
Windows 11, versão 24H2 | KB5127648 | 26100.9711 |
Windows 11, versão 26H1 | KB5127646 | 28000.3231 |
O Windows Server 2025 recebeu a mesma alteração no KB5126646, lançado no mesmo dia.
Quem é afetado (e quem não é)
Um dispositivo é afetado quando estas quatro condições se aplicam:
Executa o Windows 11 versão 24H2 ou posterior, ou o Windows Server 2025, com a atualização de outubro de 2026 instalada.
O Credential Guard não está em execução.
O valor de registo BlockNtlmv1SSO não foi definido.
O respetivo perfil de Wi‑Fi, com fios ou VPN usa MS-CHAPv2 com início de sessão único no logon do Windows, como os perfis PEAP-MSCHAPv2 e EAP-MSCHAPv2 normalmente usam.
Os dispositivos com Credential Guard em execução já se encontravam nesta situação antes de outubro. O Credential Guard bloqueia por si só o início de sessão único MS-CHAPv2 e está ativado por predefinição desde o Windows 11 versão 22H2 para dispositivos elegíveis com licenças Enterprise e Education e algumas licenças Pro. O valor de registo não faz nada nesses dispositivos. De qualquer forma, o início de sessão único PEAP em dispositivos Windows geridos está a chegar ao fim.
Tipo de ligação | Foi afetado pela atualização de outubro? |
PEAP-MSCHAPv2 ou EAP-MSCHAPv2 com início de sessão único no logon do Windows | Sim, bloqueado |
PEAP-MSCHAPv2 com credenciais introduzidas no pedido | Não, continua a ligar |
EAP-TLS (baseado em certificado) | Não |
WPA2-Personal ou WPA3-Personal (frase-passe partilhada) | Não |
dispositivos macOS, iOS, Android, Linux e ChromeOS | Não, a alteração é apenas no Windows |
O bloqueio acontece no dispositivo Windows, antes de uma resposta de autenticação chegar sequer ao servidor RADIUS. É por isso que os registos do RADIUS muitas vezes não mostram nada de útil durante estas falhas, e porque nenhuma definição do lado do servidor faz o single sign-on voltar a funcionar.
Como confirmar que a atualização é a causa
Antes de alterar quaisquer definições, confirme que é a atualização de outubro que está a bloquear a ligação. Estas verificações demoram alguns minutos num dispositivo afetado:
Verifique se a atualização está instalada. Aceda a Settings > Windows Update > Update history e procure KB5127648, ou execute winver e compare o número da compilação com a tabela acima.
Abra o Event Viewer e vá a Applications and Services Logs > Microsoft > Windows > NTLM > Operational.
Procure o ID de evento 4025 (Erro) no momento da falha de ligação. O respetivo texto diz: "Foi bloqueada uma tentativa de utilizar credenciais derivadas de NTLMv1 para início de sessão único devido à política."
Verifique o perfil de rede. Se usar PEAP-MSCHAPv2 com "Automatically use my Windows logon name and password" selecionado, encontrou a causa.
Também vale a pena verificar o ID de Evento 4024. É o aviso do modo de Auditoria no mesmo registo e, em dispositivos que ainda não instalaram a atualização de outubro, assinala as máquinas que vão falhar quando a instalarem. Recolher os eventos 4024 e 4025 em todo o seu parque de dispositivos dá-lhe um inventário de todos os dispositivos e perfis que ainda dependem do início de sessão único PEAP, de que vai precisar para a migração mais à frente neste guia.
A solução alternativa de curto prazo e por que motivo é apenas temporária
Há algumas formas de voltar a ligar os utilizadores enquanto planeia uma solução duradoura. Cada uma ganha tempo e mantém a dependência subjacente em vigor.
Defina BlockNtlmv1SSO como 0
Definir BlockNtlmv1SSO explicitamente como 0 coloca o dispositivo novamente no modo de Auditoria, o que restaura o início de sessão único PEAP-MSCHAPv2, mantendo instalada a atualização de segurança de outubro. Não é necessário reiniciar.
Definição | Valor |
Caminho do registo | HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 |
Nome do valor | BlockNtlmv1SSO |
Tipo | REG_DWORD |
Dados | 0 = Auditoria (permitido e registado), 1 = Aplicar (bloqueado) |
Em grande escala, implemente o valor através de um item de registo de Group Policy Preferences ou de um script de remediação do Intune. Planeie uma forma de chegar a dispositivos que já estão fora da rede, como uma porta com fios, uma rede de convidados ou um início de sessão com credenciais introduzidas manualmente, uma vez que não podem receber a política até voltarem a ligar-se. A definição não tem efeito em dispositivos onde o Credential Guard está em execução.
A Microsoft descreve o Audit mode como algo que "só deve ser considerado como uma exceção de segurança temporária e de âmbito limitado," porque reduz a proteção que o Enforce mode proporciona. Aplique-o apenas aos dispositivos que precisam dele, defina uma data de fim e acompanhe-o como qualquer outro risco em aberto.
Peça aos utilizadores para introduzirem as suas credenciais
Os utilizadores podem esquecer a rede guardada e voltar a ligar-se introduzindo o respetivo nome de utilizador e palavra-passe quando solicitado. Funciona sem qualquer alteração de configuração, mas cria fricção para todos os utilizadores, não ajuda os dispositivos que precisam de acesso à rede no ecrã de início de sessão e mantém as palavras-passe no percurso de autenticação de rede.
Porque desinstalar a atualização é uma má opção
Desinstalar a KB5127648 repõe a predefinição antiga, mas também remove as correções de segurança do mês. As atualizações cumulativas posteriores incluem a mesma alteração, por isso o problema volta a surgir da próxima vez que o dispositivo for atualizado. A Microsoft documenta o valor de registo como o caminho de exceção suportado.
Porque é que o MS-CHAPv2 está a ser descontinuado, no Windows e além dele
A solução alternativa no registo mantém o PEAP-MSCHAPv2 em funcionamento, mas o protocolo que preserva tem vulnerabilidades bem documentadas, e a pressão para o descontinuar vem de mais do que uma direção.
As fragilidades por trás da mudança
As orientações da própria Microsoft indicam que os terminais de Wi-Fi e VPN baseados em MS-CHAPv2 estão sujeitos a ataques semelhantes aos dirigidos ao NTLMv1. Os principais problemas estão bem estabelecidos:
Baseia-se em hashing de palavras-passe legado. A resposta MS-CHAPv2 é gerada a partir de um hash MD4 da palavra-passe do utilizador, usando o mesmo design de desafio-resposta baseado em DES que o NTLMv1, razão pela qual o Windows a trata como uma credencial derivada de NTLMv1.
Foi publicamente comprometido em 2012. Na DEF CON 20, os investigadores Moxie Marlinspike e David Hulton mostraram que uma troca MS-CHAPv2 capturada pode ser reduzida à quebra de uma única chave DES de 56 bits, com uma taxa de sucesso de 100%, independentemente da força da palavra-passe.
A sua proteção depende de cada cliente estar configurado corretamente. O PEAP encapsula o MS-CHAPv2 num túnel TLS, mas apenas os clientes que validam o certificado do servidor RADIUS obtêm essa proteção. Um cliente que ignore a validação pode ser induzido a autenticar-se num ponto de acesso evil twin que captura a troca.
Continua a ser uma palavra-passe. As palavras-passe podem ser obtidas por phishing, partilhadas e reutilizadas, e cada reposição ou expiração pode desligar um dispositivo da rede até que o utilizador volte a iniciar sessão.
Segue-se o próprio protocolo
A Microsoft está a restringir o MS-CHAPv2 no lado do cliente. O organismo de normalização que mantém o RADIUS está a trabalhar no lado do protocolo.
O rascunho atual do grupo de trabalho IETF RADEXT, "Deprecating Insecure Practices in RADIUS," inclui uma secção que descontinua formalmente o MS-CHAP. O mesmo rascunho descontinua o RADIUS sobre UDP e TCP fora de redes seguras e defende transportes seguros, como RadSec (RADIUS sobre TLS). Ainda está em desenvolvimento, mas mostra a direção em que as normas de segurança do RADIUS estão a evoluir. Para contexto sobre o lado do transporte, veja a nossa comparação entre RADIUS e RadSec.
Definir BlockNtlmv1SSO como 0 não resolve nenhuma destas tendências. Abandonar o MS-CHAPv2 resolve ambos os problemas.
A correção permanente: migrar dispositivos Windows para EAP-TLS
A Microsoft recomenda migrar as ligações Wi‑Fi e VPN de MS-CHAPv2 para autenticação baseada em certificados, como EAP-TLS ou PEAP-TLS. Para a maioria das organizações, EAP-TLS é o caminho mais direto.
Porque é que o EAP-TLS não é afetado
O EAP-TLS autentica o dispositivo ou utilizador com um certificado e uma chave privada. Não é utilizada nenhuma palavra-passe, e o Windows não precisa de uma credencial de início de sessão guardada, por isso a alteração BlockNtlmv1SSO nunca se aplica. O Credential Guard também não bloqueia a autenticação baseada em certificados.
Esta mudança também resolve problemas que o PEAP-MSCHAPv2 sempre teve:
Não há nenhuma palavra-passe para obter por phishing, decifrar offline ou capturar com um ponto de acesso evil twin.
Um certificado de dispositivo permite que um portátil se ligue no ecrã de início de sessão, antes de alguém iniciar sessão.
As reposições e expirações de palavras-passe deixaram de desligar os dispositivos do Wi‑Fi.
A mesma abordagem baseada em certificados funciona para Wi‑Fi, 802.1X com fios e VPN.
Como migrar sem tempo de inatividade
PEAP e EAP-TLS podem ser executados em paralelo durante a transição, para que os dispositivos possam migrar em grupos em vez de todos de uma só vez. Estes passos funcionam com qualquer fornecedor de identidade e qualquer plataforma MDM:
Crie um inventário. Use os eventos 4024 e 4025 para listar os dispositivos afetados e os perfis de rede que utilizam. Separe os dispositivos geridos pela empresa dos pessoais e não geridos, uma vez que receberão os certificados de forma diferente.
Decida como os certificados serão emitidos. Uma autoridade de certificação no local, como o Active Directory Certificate Services, é uma das opções. Uma autoridade de certificação alojada na cloud elimina a necessidade de executar essa infraestrutura internamente.
Entregue certificados a dispositivos geridos. Utilize o perfil de certificado SCEP do seu MDM, quer seja Microsoft Intune, Jamf, Workspace ONE, Kandji ou Google Admin para Chromebooks.
Dê aos dispositivos não geridos e BYOD um caminho de autosserviço. Um fluxo de inscrição que instala o certificado e o perfil de rede permite aos utilizadores integrar os seus próprios dispositivos sem um pedido de suporte à equipa de TI.
Configure o seu servidor RADIUS para aceitar EAP-TLS juntamente com PEAP durante a transição.
Implemente um perfil de rede EAP-TLS. Configure-o para validar o certificado do servidor RADIUS através da raiz fidedigna e do nome do servidor.
Faça um piloto com uma equipa ou localização. Confirme que os dispositivos se ligam no ecrã de início de sessão e permanecem ligados após uma alteração de palavra-passe.
Implemente por fases por departamento, localização ou grupo de dispositivos.
Descontinue o PEAP. Remova o perfil antigo dos dispositivos, elimine quaisquer exceções BlockNtlmv1SSO e desative o MS-CHAPv2 no servidor RADIUS.
Os Macs, telemóveis e Chromebooks não são afetados pela atualização de outubro, mas, se o objetivo for eliminar totalmente o PEAP da rede, também vão precisar de certificados. O nosso guia sobre Wi-Fi baseado em certificados para Chromebooks geridos abrange o lado do ChromeOS.
Como a Foxpass ajuda a abandonar o PEAP-MSCHAPv2
Foxpass, da Splashtop, fornece autenticação RADIUS alojada na cloud para redes Wi-Fi, VPN e com fios, juntamente com uma PKI na cloud para emitir certificados de dispositivos e utilizadores. Em conjunto, o Foxpass Cloud RADIUS e o Foxpass Cloud PKI cobrem cada fase da migração acima sem servidores on-premises para implementar ou manter.
Emissão de certificados sem infraestrutura no local: o Foxpass Cloud PKI atua como a sua autoridade de certificação, e o Foxpass Cloud RADIUS valida o certificado em cada tentativa de ligação.
Entrega de certificados através do MDM que já utiliza: Os dispositivos geridos recebem certificados através do endpoint SCEP do Foxpass a partir de Microsoft Intune, Jamf, Kandji, Addigy, Workspace ONE, Mosyle, NinjaOne e Google Admin para Chromebooks. As equipas que gerem endpoints Windows com Splashtop AEM também podem entregar certificados através do Splashtop AEM.
Acesso associado ao fornecedor de identidade que já utiliza: o Foxpass sincroniza utilizadores e grupos do Microsoft Entra ID, Google Workspace, Okta e OneLogin, pelo que o acesso à rede segue o mesmo diretório que tudo o resto. Abordamos com mais detalhe a vertente do Okta e do Google Workspace em autenticação baseada em certificados para Okta e Google Workspace.
Um percurso de self-service para BYOD e dispositivos não geridos: O Foxpass BYOD Certificate Installer permite que os utilizadores inscrevam eles próprios dispositivos Mac, Windows, iOS, Android e Chromebook.
Acesso que termina quando alguém sai: Como um certificado pode incluir o endereço de email do utilizador ou o ID do dispositivo, o Foxpass pode confirmar no momento da ligação que o utilizador ou dispositivo continua ativo no seu diretório.
Uma transição faseada: o Foxpass Cloud RADIUS suporta EAP-TLS e EAP-TTLS em simultâneo, pelo que é possível migrar os dispositivos para certificados por fases.
Tráfego RADIUS encriptado: O Foxpass suporta RadSec, que protege o tráfego de autenticação entre os seus pontos de acesso e o servidor RADIUS com TLS.
Saiba mais sobre acesso sem palavra-passe a Wi-Fi e VPN com Foxpass.
Abandone o PEAP de vez com Wi‑Fi baseado em certificados
A definição BlockNtlmv1SSO pode voltar a colocar os utilizadores do Windows 11 online hoje, mas mantém o início de sessão na rede dependente de um protocolo do qual a Microsoft recomenda afastar-se, e que a IETF está a avançar para descontinuar ao nível do protocolo. A autenticação baseada em certificados elimina essa dependência, para que o futuro reforço de segurança do Windows não se transforme noutra vaga de pedidos de suporte de Wi-Fi.
Foxpass Cloud RADIUS e Foxpass Cloud PKI permitem fazer essa transição com o fornecedor de identidade e o MDM que já utiliza. Inicie uma avaliação gratuita ou agende uma demonstração para ver como o Foxpass se adapta ao seu ambiente.
