KB5127648 y NTLMv1: por qué Wi-Fi, LAN y VPN con PEAP-MSCHAPv2 dejaron de conectar y cómo solucionarlo de forma definitiva

La respuesta corta

Desde KB5127648, la actualización acumulativa de octubre de 2026 para Windows 11 24H2, 25H2 y 26H2, Windows bloquea por defecto las credenciales derivadas de NTLMv1 para el inicio de sesión único. Windows Server 2025 recibe el mismo cambio con su actualización de octubre de 2026. En dispositivos sin Credential Guard, las conexiones Wi-Fi, Ethernet (802.1X cableado) y VPN que usan PEAP-MSCHAPv2 o EAP-MSCHAPv2 con credenciales de Windows dejan de conectarse automáticamente.

Establecer el valor de registro BlockNtlmv1SSO en 0 restaura el comportamiento anterior de forma temporal. La corrección permanente que Microsoft recomienda es la autenticación basada en certificados con EAP-TLS.

TL;DR

• Qué cambió: Windows aplica ahora BlockNtlmv1SSO en todos los dispositivos donde un administrador no lo haya configurado explícitamente. Microsoft lo anunció en el artículo MC1508562 del Centro de mensajes y lo documenta en KB5066470.
• Quién se ve afectado: Dispositivos sin Credential Guard que usan inicio de sesión único basado en MS-CHAPv2, habitualmente clientes Windows unidos al dominio.
• Solución provisional rápida: Establecer BlockNtlmv1SSO en 0. El propio Microsoft advierte que este ajuste no debe usarse a largo plazo.
• Corrección permanente: Migrar a EAP-TLS. Con SCEPman puedes hacerlo sin necesidad de construir una PKI local.

Qué cambió con KB5127648

Microsoft lleva tiempo eliminando NTLM de forma progresiva. El último paso afecta a un protocolo del que todavía dependen muchas redes a diario: MS-CHAPv2. Este protocolo se basa en credenciales derivadas de NTLMv1, y Windows ha dejado de proporcionarlas para el inicio de sesión único.

Microsoft anunció la aplicación forzosa en el artículo MC1508562 del Centro de mensajes: «Take action: NTLMv1 hardening changes might affect network connections on devices without Credential Guard». Los detalles técnicos están en KB5066470.

Microsoft lo define como un cambio de refuerzo de seguridad planificado, no como un problema conocido de la actualización. Es decir, ha llegado para quedarse.

¿Estás afectado?

Probablemente estés afectado si se cumplen todas las condiciones siguientes:

• Tus dispositivos ejecutan Windows 11 24H2 o posterior, o Windows Server 2025, con la actualización de octubre de 2026 (KB5127648 en Windows 11) instalada.
• Credential Guard está deshabilitado en esos dispositivos.
• Tu red Wi-Fi, Ethernet (802.1X cableado) o VPN usa PEAP-MSCHAPv2 o EAP-MSCHAPv2 con inicio de sesión único. Esto suele corresponderse con un dispositivo unido al dominio que tiene activada la opción «Usar automáticamente mi nombre de usuario y contraseña de Windows».
• El valor de registro BlockNtlmv1SSO nunca se ha configurado.

Este cambio no te afecta si tus dispositivos ya usan autenticación basada en certificados (EAP-TLS). Los dispositivos con Credential Guard habilitado ya bloqueaban este comportamiento, por lo que el SSO basado en contraseña ya no funcionaba en ellos. El cambio está en Windows, de modo que los clientes macOS, iOS, Android y Linux no se ven afectados.

Cómo se manifiesta el problema

• Los dispositivos dejan de conectarse automáticamente y los usuarios reciben una solicitud de credenciales.
• Introducir la contraseña manualmente sigue funcionando, pero Windows no puede guardarla para la próxima vez.
• Los flujos de trabajo que antes se conectaban sin intervención del usuario dejan de funcionar, por ejemplo en dispositivos compartidos o de quiosco y en perfiles VPN con conexión automática.
• El cliente registra el Event ID 4025 («bloqueado») en Microsoft-Windows-NTLM/Operational. En modo de auditoría registra en su lugar el Event ID 4024.

El fallo se produce en el cliente, por lo que los registros de RADIUS o NPS pueden mostrar poco o nada. Comienza a diagnosticar el problema en el endpoint.

Cómo verificar un dispositivo

# ¿Está configurado BlockNtlmv1SSO? (sin valor = Windows usa el nuevo comportamiento de aplicación forzosa)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO

# ¿Ha auditado Windows (4024) o bloqueado (4025) credenciales derivadas de NTLMv1?
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -FilterXPath '*[System[(EventID=4024 or EventID=4025)]]' -MaxEvents 50

La solución provisional: establecer BlockNtlmv1SSO en 0

Puedes devolver los dispositivos afectados al modo de auditoría. Windows vuelve entonces a permitir las credenciales derivadas de NTLMv1 y registra cada uso con el Event ID 4024.

Línea de comandos

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

Corrección mediante Intune (ejecutar en contexto de sistema)

# Script de detección: conforme solo si BlockNtlmv1SSO está explícitamente establecido en 0
$v = (Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -ErrorAction SilentlyContinue).BlockNtlmv1SSO
if ($v -eq 0) { exit 0 } else { exit 1 }

# Script de corrección
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -PropertyType DWord -Value 0 -Force | Out-Null

En dispositivos unidos al dominio, usa un elemento de registro de Preferencias de directiva de grupo con la misma clave, nombre de valor, tipo y datos.

Por qué es solo una solución provisional

• Reabre una vía débil. Microsoft advierte que los endpoints basados en MS-CHAPv2 «están sujetos a riesgos similares a los que afectan a NTLMv1» y recomienda que este ajuste «se evalúe con cuidado y no se use a largo plazo».
• No ayuda a los dispositivos con Credential Guard. Estos bloquean el SSO con MS-CHAPv2 independientemente de este ajuste.
• Los dispositivos sin conexión no pueden recibir la directiva. Los que ya han perdido acceso a la red pueden necesitar una red cableada o de invitados para recibir la configuración.
• Desinstalar la actualización no es una alternativa. Dejaría los dispositivos sin las correcciones de seguridad del mes.

Usa la solución provisional para ganar tiempo, fija una fecha límite documentada y aprovecha ese tiempo para migrar.

La corrección definitiva: EAP-TLS en lugar de contraseñas

Microsoft recomienda eliminar la dependencia de MS-CHAPv2 y migrar las conexiones Wi-Fi y VPN a autenticación basada en certificados con EAP-TLS. El dispositivo o usuario acredita entonces su identidad con un certificado y una clave privada en lugar de una contraseña, y la clave privada puede estar protegida por el TPM.

Además de resolver la interrupción, obtienes una mejor experiencia de usuario y una postura de seguridad más sólida.

Por qué tantas redes siguen dependiendo de contraseñas

El protocolo no es el problema. La PKI lo es. La configuración clásica incluye AD CS, NDES, el Intune Certificate Connector, un proxy de aplicación, publicación de CRL, alta disponibilidad y parcheo. Son muchas piezas en movimiento solo para poner un certificado en un portátil, y eso explica que muchos equipos hayan pospuesto la migración durante años. Puedes encontrar más información en Microsoft ADCS Alternatives in 2026.

Cómo SCEPman elimina la complejidad de la PKI

SCEPman es una autoridad de certificación nativa de Azure que se ejecuta íntegramente en tu propio tenant de Azure, con claves en Azure Key Vault.

• Puesta en marcha rápida: Despliega a través de Azure Marketplace, una plantilla ARM o Terraform. La mayoría de los equipos emiten su primer certificado en menos de una hora.
• Dispositivos gestionados: Microsoft Intune, Jamf Pro y otros MDM emiten y renuevan certificados de dispositivo y usuario automáticamente mediante SCEP.
• Validación en tiempo real: Los certificados están vinculados al objeto de usuario o dispositivo y se comprueban mediante OCSP. Cuando cambia una identidad, el acceso se revoca automáticamente.
• Compatible con tu red: SCEPman es compatible con Cisco y Meraki, HPE Aruba, Fortinet, Juniper y otros, y funciona con tu servidor RADIUS existente.
• Sin servidores RADIUS propios: Combinado con RADIUSaaS, obtienes una solución completamente nativa en la nube para el acceso Wi-Fi, LAN y VPN basado en certificados.

Tu plan de migración en seis pasos

1. Haz un inventario. Identifica qué SSIDs, políticas de 802.1X cableado y perfiles VPN siguen usando MS-CHAPv2. Los Event IDs 4024 y 4025 te muestran qué dispositivos dependen de él.
2. Gana tiempo donde sea necesario. Establece BlockNtlmv1SSO en 0 en los dispositivos críticos, pero documéntalo y fija una fecha de caducidad.
3. Despliega SCEPman y distribuye su certificado de CA raíz, ya sea mediante un perfil de certificado de confianza de Intune o mediante Directiva de grupo.
4. Despliega los certificados. Emite certificados de dispositivo (y de usuario donde sea necesario) mediante perfiles SCEP de Intune, Jamf Pro u otro MDM.
5. Migra de forma gradual. Habilita EAP-TLS en tu servidor RADIUS (NPS, tu RADIUS existente o RADIUSaaS) junto a PEAP. Después, migra tus perfiles Wi-Fi, 802.1X y VPN a EAP-TLS de forma escalonada, grupo a grupo.
6. Limpia. Elimina las políticas de MS-CHAPv2 y, a continuación, restaura BlockNtlmv1SSO a 1 o elimina el valor para que Windows vuelva a usar el comportamiento seguro por defecto:

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

Conclusión

Microsoft ha tomado la decisión: el SSO de red basado en contraseñas mediante MS-CHAPv2 no tiene futuro en Windows. Puedes parchear KB5127648 durante unas semanas o puedes aprovechar este momento para migrar definitivamente al acceso basado en certificados.

PKI sin complicaciones. Certificados fiables.

Prueba SCEPman gratis

FAQ