A Microsoft definirá, em outubro de 2026, o bloqueio de NTLMv1 como valor padrão da chave de registro BlockNtlmv1SSO nos dispositivos que ainda não receberam essa configuração de forma explícita. Com a virada, o logon único que depende de credenciais derivadas de NTLMv1 passa a falhar: Wi-Fi corporativo, rede cabada com 802.1X e clientes VPN que usam MS-CHAPv2 deixam de conectar sozinhos e passam a pedir senha a cada acesso. A ação prioritária é rodar a auditoria dos eventos do Windows ainda esta semana, mapear os processos que dependem do protocolo legado e migrar os perfis de rede para autenticação com certificados antes que a mudança chegue por atualização automática.
O que muda em outubro
A mudança está documentada no artigo de suporte KB5066470, publicado em agosto de 2025. A chave mora no caminho de registro HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, com o valor BlockNtlmv1SSO, do tipo REG_DWORD. Enquanto o dado é 0, o sistema opera em modo auditoria: a solicitação para gerar credenciais NTLMv1 do usuário conectado é permitida e gera apenas um evento de aviso. Quando o dado é 1, entra o modo bloqueio: a solicitação é negada e um evento de erro é gravado. Ou seja, o padrão muda de auditoria para bloqueio em outubro de 2026, mas somente nas máquinas nas quais nenhum administrador implantou a chave; quem define o valor explicitamente assume o controle do próprio cronograma.
A própria Microsoft classifica as datas como tentativas e sujeitas a alteração, o que não é razão para esperar: o modo auditoria roda nos clientes Windows 11 24H2 desde o fim de agosto de 2025 e alcançou o Windows Server 2025 a partir de novembro de 2025. O escopo é amplo — a listagem oficial cobre Windows 11 24H2 nas edições SE, Enterprise, Education, Multi-Session, Home, Pro e IoT Enterprise, além do Windows Server 2025. Há uma exceção relevante: a alteração não se aplica a dispositivos com Credential Guard habilitado, porque o recurso já protege a criptografia legada de NTLMv1. A recomendação oficial é habilitar o Credential Guard em todo parque que atenda aos requisitos — e, desde o Windows 11 22H2 e no Windows Server 2025, ele vem ativo por padrão, salvo desativação manual.
Quem é afetado pelo bloqueio
O alvo da mudança são protocolos de nível superior que usam credenciais derivadas de NTLMv1 para logon único. Os exemplos citados pela Microsoft são implantações de Wi-Fi, Ethernet e VPN com autenticação MS-CHAPv2. Em modo bloqueio, o logon único desses fluxos deixa de funcionar; digitar a senha manualmente continua possível. Para o usuário final, o sintoma não parece incidente de segurança: é o notebook que deixou de entrar sozinho no Wi-Fi da empresa ou o cliente VPN que parou de reaproveitar a sessão do Windows. Para o help desk, é uma onda de chamados logo depois que a atualização chegar.
Manter MS-CHAPv2 não é saída. A documentação de Credential Guard registra que endpoints Wi-Fi e VPN baseados no protocolo ficam expostos a ataques semelhantes aos de NTLMv1, e há registro público de incompatibilidade entre Credential Guard e MS-CHAPv2 em implementações corporativas como o Cisco ISE. Segurar o protocolo legado apenas adia a migração e acumula risco de roubo de credenciais — a mesma documentação recomenda avançar para métodos sem senha, como Windows Hello for Business, chaves FIDO 2 e cartões inteligentes, sempre que o cenário permitir.
Como auditar antes da virada
A auditoria é barata e não exige agente novo. Nos equipamentos com Windows 11 24H2 ou Windows Server 2025, abra o PowerShell e consulte o log operacional do NTLM; o aviso 4024 aparece no log NTLM antes de qualquer bloqueio, e o erro 4025 indica tentativa já negada por política durante um piloto. Ambos os eventos listam servidor de destino, usuário, identificador e nome do processo cliente — informação suficiente para localizar o perfil de rede ou a aplicação responsável pela dependência legada.
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-NTLM/Operational'; Id=4024,4025} -MaxEvents 50 | Select-Object TimeCreated, Id, Message| Evento | Tipo | Significado | Ação |
|---|---|---|---|
| 4024 | Aviso | Uso de credencial NTLMv1 permitido em modo auditoria | Mapear processo e perfil de rede; planejar migração |
| 4025 | Erro | Tentativa bloqueada por política em modo Enforce | Registrar no piloto e remediar o método de autenticação |
Consulte uma amostra representativa de notebooks e servidores, não uma única máquina: notebooks em roaming no Wi-Fi do escritório são o ponto mais provável de ocorrência. Em escala, encaminhe o log por Windows Event Forwarding ou agente de coleta; antes de escrever regras de detecção sobre esses registros, normalize os logs no SIEM para não multiplicar ruído em ferramentas que já operam no limite.
Correção com certificados
A correção definitiva é estrutural: a saída recomendada é trocar MSCHAPv2 por certificados, migrando perfis como PEAP-MSCHAPv2 e EAP-MSCHAPv2 para PEAP-TLS ou EAP-TLS, como recomenda a documentação oficial de Credential Guard. A migração exige uma PKI saudável — autoridade certificadora, emissão, distribuição e renovação de certificados de dispositivo ou de usuário — e a reconfiguração dos perfis de rede via política de grupo ou MDM. Teste em grupo piloto com dispositivos representativos, incluindo quiosques e estações compartilhadas, antes de expandir ao parque inteiro.
Quem não conseguir migrar antes da virada pode fixar explicitamente o valor 0 da chave para manter o modo auditoria como ponte temporária, porque a mudança de padrão só se aplica quando a chave não foi implantada no dispositivo. A medida compra tempo, mas mantém a exposição ativa. A alternativa melhor é habilitar o Credential Guard nos dispositivos compatíveis: o recurso neutraliza essa superfície específica e a Microsoft recomenda estendê-lo a todo parque suportado, testando antes os cenários de atualização, já que versões novas do Windows podem restringir cenários antes funcionais.
Prioridades P1 e P2
- P1 — inventariar exposição: listar dispositivos com Windows 11 24H2 e Windows Server 2025, consultar os eventos 4024 em amostra representativa e identificar perfis Wi-Fi, 802.1X e VPN que usam MS-CHAPv2.
- P1 — piloto de bloqueio: implantar BlockNtlmv1SSO com valor 1 em grupo controlado, registrar os eventos 4025 resultantes e medir o impacto real antes da virada obrigatória.
- P2 — migrar perfis: planejar a troca para PEAP-TLS ou EAP-TLS com PKI, política de grupo ou MDM, priorizando os perfis com maior volume de avisos registrados.
- P2 — blindar com Credential Guard: habilitar o recurso nos dispositivos compatíveis e validar cenários de atualização antes da distribuição ampla.
Para decidir a ordem interna dessas frentes, aplique um modelo de priorização por risco em quatro perguntas: o critério deve combinar volume de dependência legada, criticidade do serviço afetado e janela até a virada, não a fila de projetos de infraestrutura.