Windows Hello: Explicación de la autenticación sin contraseña

Windows Hello es el marco de autenticación sin contraseña integrado de Microsoft para Windows 10 y 11, que permite a los usuarios iniciar sesión mediante datos biométricos (rostro, huella dactilar o iris) o un PIN respaldado por claves criptográficas almacenadas en el Módulo de plataforma segura (TPM) del dispositivo. A diferencia de las contraseñas, las credenciales de Windows Hello nunca salen del dispositivo y están vinculadas criptográficamente al hardware local, lo que las hace resistentes al phishing, al robo de credenciales y a los ataques de repetición. Windows Hello para empresas extiende esta capacidad a entornos empresariales, admitiendo la autenticación con Microsoft Entra ID, Active Directory y clave de acceso FIDO2 mediante tres modelos de confianza de implementación.

Puntos Clave

• No existe una ruta de migración directa desde una implementación de Confianza de Certificados a Confianza Kerberos en la Nube. El contenedor de Windows Hello existente debe eliminarse antes de que un dispositivo pueda migrar a Confianza Kerberos en la Nube.
• Windows Hello reemplaza las contraseñas con un par de claves asimétricas respaldadas por TPM. La clave privada nunca sale del dispositivo, por lo que no hay ningún secreto compartido que pueda ser objeto de phishing, robo o manipulación.
• Windows Hello para empresas (WHfB) admite tres modelos de confianza empresarial: Confianza Kerberos en la nube, Confianza de clave y Confianza de certificado. La Confianza Kerberos en la nube es la opción predeterminada recomendada por Microsoft para implementaciones híbridas.
• Las cuentas en grupos privilegiados de Active Directory, incluidos los administradores de dominio, no pueden autenticarse a través de Cloud Kerberos Trust por diseño, ya que la política de replicación de contraseñas en el objeto AzureADKerberos las bloquea.
• Las claves de acceso Microsoft Entra en Windows estarán disponibles de forma general en 2026, lo que permitirá que Windows Hello actúe como un autenticador de clave de acceso FIDO2 en dispositivos que no estén unidos a Entra.

Por qué las contraseñas ya no son suficientes

Según el Informe de Defensa Digital 2024 de Microsoft, la autenticación multifactor bloquea más del 99 % de los ataques basados ​​en la identidad; sin embargo, el ataque de fuerza bruta, el relleno de credenciales y las campañas de phishing siguen representando la mayoría de los accesos iniciales en la telemetría global de Microsoft, que registró más de 7,000 ataques de contraseñas por segundo durante el último año. El problema principal es estructural: las contraseñas son secretos compartidos. Se transmiten a través de las redes, se almacenan en bases de datos y se reutilizan habitualmente en distintos servicios. Cualquier vulneración de seguridad puede desencadenar el robo de múltiples cuentas.

Los cinco modos de fallo de la autenticación basada en contraseñas están bien documentados y son persistentes:

• Ataques de fuerza bruta y de diccionario que explotan credenciales débiles o reutilizadas.
• Campañas de phishing que engañan a los usuarios para que introduzcan sus credenciales en sitios web falsificados.
• Relleno de credenciales que explota contraseñas filtradas de brechas de seguridad no relacionadas.
• El robo de bases de datos de contraseñas expone las credenciales cifradas a ataques de descifrado sin conexión.
• Barreras de accesibilidad que perjudican a los usuarios con discapacidad visual o limitaciones motoras.

Windows Hello aborda los cinco modos de fallo al reemplazar el modelo de secreto compartido con una credencial criptográfica asimétrica vinculada al dispositivo que no puede ser objeto de phishing, replicada o transmitida.

¿Qué es Windows Hello?

Windows Hello es el sistema biométrico y basado en PIN de Microsoft. autenticación Este marco, introducido en Windows 10 y ampliado significativamente en Windows 11, reemplaza la introducción de contraseñas con uno de tres gestos biométricos: reconocimiento facial, escaneo de huellas dactilares o escaneo de iris, según las capacidades de hardware del dispositivo. También admite un PIN como método alternativo o principal; cabe destacar que este PIN se diferencia de una contraseña en que es específico del dispositivo y está respaldado por el TPM en lugar de transmitirse a un servidor.

Windows Hello existe en dos niveles:

Elemento	Windows Hello (para consumidores)	Windows Hello para empresas (WHfB)
Usuario objetivo	Cuenta personal / Cuenta de Microsoft	ID empresarial/Entra o AD
Tipo de credencial	Clave vinculada al dispositivo (software si no hay TPM)	Par de claves asimétricas respaldado por TPM (requerido por la política)
Proveedor de identidad	Cuenta de Microsoft (MSA)	Microsoft Entra ID, Active Directory, AD FS
Compatibilidad con FIDO2	Sí, certificado por FIDO Alliance desde Windows 10 versión 1903.	Sí, se extiende a la clave de acceso Entra (FIDO2) a partir de 2026.
Directiva empresarial (Intune / GPO)	Limitada	Soporte completo para MDM/Directivas de grupo.
Acceso a recursos locales	No se admite	Sí, a través de Cloud Kerberos Trust o Certificado Confianza

Cómo funciona Windows Hello: La Fundación Criptográfica

Para comprender Windows Hello, es necesario entender cómo reemplaza el modelo de contraseña con criptografía de clave pública. Durante el registro, el dispositivo genera un par de claves asimétricas.

Generación y almacenamiento de claves

• El TPM genera un par de claves, una privada y otra pública, para el usuario en ese dispositivo.
• La clave privada está sellada dentro del TPM y nunca se exporta. No se puede extraer, ni siquiera por el sistema operativo.
• La clave pública se registra con el proveedor de identidades (Microsoft Entra ID, Active Directory o AD FS) y se asocia con la cuenta de usuario.
• Los datos biométricos (plantilla facial, plantilla de huella dactilar) se almacenan localmente en una base de datos cifrada en C:\Windows\System32\WinBioDatabase. Nunca salen del dispositivo ni se transmiten a los servidores de Microsoft.

Flujo de autenticación

Cuando un usuario inicia sesión, la secuencia es:

1. El usuario presenta un gesto biométrico o un PIN al contenedor de Windows Hello.
2. Este gesto desbloquea el acceso a la clave privada almacenada en el TPM. El PIN o la información biométrica actúan como factor de desbloqueo local y nunca salen del dispositivo.
3. El dispositivo utiliza la clave privada para firmar un desafío criptográfico del proveedor de identidad.
4. El proveedor de identidad verifica la firma utilizando la clave pública registrada y emite un token de autenticación.
5. El usuario obtiene acceso a Windows, Microsoft 365, aplicaciones protegidas por Entra y, bajo WHfB, a recursos locales.

Dado que la clave privada está vinculada al TPM y el PIN o la información biométrica nunca salen del dispositivo, este modelo de autenticación elimina los vectores de ataque dirigidos a las contraseñas. No hay credenciales que se puedan obtener mediante phishing, ni bases de datos que se puedan vulnerar, ni secretos transmitidos por la red que se puedan interceptar.

Seguridad de inicio de sesión mejorada (ESS)

Windows 11 introduce la Seguridad de inicio de sesión mejorada (ESS), que aísla la comparación de plantillas faciales dentro de un enclave de seguridad basado en virtualización (VBS) que establece un canal seguro con TPM 2.0 durante el arranque. Para la huella dactilar, ESS se basa en hardware de comparación en el sensor que realiza la comparación y el almacenamiento de plantillas en el propio módulo del sensor.

Bajo ESS, incluso un núcleo de sistema operativo comprometido no puede acceder a los datos de la plantilla biométrica ni inyectar señales biométricas falsificadas. ESS requiere sensores biométricos diseñados específicamente y se aplica mediante políticas para entornos de alta seguridad.

Windows Hello para empresas: Modelos de implementación empresarial

Para las organizaciones que implementan Windows Hello para empresas, Microsoft admite tres modelos de confianza. Elegir el modelo adecuado depende de la topología del directorio y de la configuración existente. Infraestructura PKIy los requisitos de acceso en las instalaciones.

Modelo de confianza	Cómo Funciona	Uso recomendado
Confianza Kerberos en la nube	Utiliza Microsoft Entra Kerberos para emitir TGT parciales. No requiere PKI ni sincronización de claves.	Entornos híbridos y puramente unidos a Entra. La configuración predeterminada recomendada por Microsoft para nuevas implementaciones.
Fideicomiso clave	La clave pública se almacena en Active Directory. Los controladores de dominio requieren certificados de autenticación Kerberos; Entra Connect sincroniza las claves.	Entornos híbridos con una infraestructura de clave pública (PKI) empresarial existente que pueda emitir certificados de centro de datos.
Certificado Confianza	AD FS emite certificados de inicio de sesión en el contenedor WHfB. Se requiere una infraestructura PKI completa en las instalaciones.	Organizaciones que requieren equivalencia de tarjeta inteligente basada en certificados o escenarios RDP/VDI que necesitan certificados de usuario.

Confianza Kerberos en la nube: la ruta recomendada

Cloud Kerberos Trust, presentado en 2022, elimina las dos principales barreras para la adopción de WHfB: la necesidad de una infraestructura de clave pública (PKI) local completa y la necesidad de sincronizar las claves públicas con Active Directory. En su lugar, aprovecha la misma infraestructura de Entra Kerberos que ya permite el inicio de sesión sin contraseña FIDO2 para entornos híbridos. Los administradores lo configuran con un único comando de PowerShell para crear el objeto AzureADKerberos, seguido de dos directivas de Intune o GPO.

El flujo de autenticación bajo Cloud Kerberos Trust: cuando un usuario desbloquea su dispositivo con un PIN o datos biométricos, el TPM libera la clave privada WHfB, que firma una solicitud de autenticación a Entra ID. Entra ID devuelve un TGT parcial, un ticket Kerberos emitido en la nube, que el controlador de dominio intercambia por un TGT Kerberos completo local, otorgando SSO a recursos locales como carpetas compartidas y aplicaciones de intranet sin necesidad de un segundo inicio de sesión. No se requiere contraseña en ninguna etapa.

Se aplican dos limitaciones operativas. En primer lugar, las cuentas que son miembros directos o indirectos de grupos de seguridad integrados con privilegios, incluidos los administradores de dominio, no pueden autenticarse mediante Cloud Kerberos Trust. El objeto AzureADKerberos se comporta como un controlador de dominio de solo lectura, y su política de replicación de contraseñas predeterminada impide que las cuentas con privilegios lo utilicen, la misma restricción que se aplica a los RODC estándar.

Microsoft desaconseja flexibilizar esta política debido a la vulnerabilidad que abriría entre Entra ID y Active Directory. En segundo lugar, Cloud Kerberos Trust no admite el inicio de sesión RDP ni VDI con credenciales proporcionadas; las organizaciones que necesiten una equivalencia de tarjeta inteligente basada en certificados para estos escenarios deberían usar Certificate Trust o Remote Credential Guard.

Las implementaciones de Certificate Trust requieren una infraestructura de clave pública (PKI) empresarial en funcionamiento para emitir certificados de controlador de dominio y certificados de inicio de sesión de usuario opcionales. Los servicios de PKI de Encryption Consulting ofrecen diseño, implementación y gestión integral de PKI para entornos de TI, incluyendo la jerarquía de CA, las plantillas de certificados y la integración con Intune necesarias para una implementación de Certificate Trust WHfB.

Windows Hello, FIDO2 y claves de acceso Entra

Windows Hello cuenta con la certificación FIDO2 de la Alianza FIDO desde la versión 1903 de Windows 10. Esto significa que Windows Hello actúa como un autenticador de plataforma compatible con las especificaciones WebAuthn y CTAP2, los mismos estándares abiertos que sustentan las claves de acceso en diferentes navegadores, sistemas operativos y proveedores de identidad.

Windows Hello como autenticador de plataforma FIDO2

Cuando un sitio web o una aplicación solicita FIDO2 autenticaciónWindows Hello actúa como autenticador local. Genera un par de claves FIDO2 en el contenedor de claves de Windows Hello, protege la clave privada con el TPM y la libera solo después de que el usuario supera la verificación biométrica local o mediante PIN. El resultado es una clave de acceso vinculada al dispositivo que no puede ser robada mediante phishing, ya que está criptográficamente vinculada a un origen específico, el dominio del sitio web, lo que impide que funcione en cualquier página de inicio de sesión falsificada.

Windows Hello cuenta con la certificación FIDO2 de la Alianza FIDO desde la versión 1903 de Windows 10. Esto significa que Windows Hello actúa como un autenticador de plataforma compatible con las especificaciones WebAuthn y CTAP2, los mismos estándares abiertos que sustentan las claves de acceso en diferentes navegadores, sistemas operativos y proveedores de identidad.

Acceso a claves de acceso mediante Windows Hello (2026)

Microsoft comenzó un despliegue gradual de las claves de acceso de Microsoft Entra en Windows en vista previa pública en marzo de 2026, extendiendo autenticación sin contraseña a dispositivos Windows que no están unidos a Entra ni administrados. Esta funcionalidad ya está disponible de forma general y se está implementando en todo el mundo durante la primera mitad de 2026, y en los entornos de nube del gobierno de EE. UU. (GCC, GCC High y DoD) en los meses siguientes. Con la disponibilidad general, Microsoft eliminó el requisito de la versión preliminar pública que obligaba a los administradores a incluir explícitamente en la lista de permitidos los AAGUID de Windows Hello en un perfil de clave de acceso; las organizaciones cuyos perfiles de clave de acceso ya permiten claves de acceso vinculadas a dispositivos y no certificadas ahora tienen las claves de acceso de Entra habilitadas en Windows de forma predeterminada.

Con esta configuración, los usuarios registran una clave de acceso vinculada al dispositivo, almacenada en el contenedor de Windows Hello, y se autentican mediante reconocimiento facial, huella digital o PIN. La clave de acceso está vinculada criptográficamente al dispositivo y nunca se transmite por la red, lo que la hace inmune a los ataques de phishing y de robo de credenciales.

Detalles clave de la integración de la clave de acceso de Entra:

• Cada cuenta de Entra registra su propia clave de acceso por dispositivo. Varias cuentas pueden coexistir en una misma máquina.
• Las claves de acceso están vinculadas a un dispositivo y no se pueden sincronizar entre dispositivos. Cada dispositivo requiere un registro independiente.
• Windows Hello para empresas sigue siendo el método recomendado para dispositivos administrados unidos a Entra. Las claves de acceso de Entra en Windows complementan los escenarios de dispositivos no administrados y no admiten el inicio de sesión en el dispositivo.
• Una credencial WHfB y una clave de acceso Entra no pueden coexistir en el mismo contenedor para la misma cuenta. Si existe una credencial WHfB, el registro de la clave de acceso se bloquea hasta que se elimine, por lo que WHfB tiene prioridad en los dispositivos administrados. Microsoft indica que este bloqueo podría eliminarse una vez que el total combinado de claves de acceso, credenciales WHfB y credenciales de la plataforma Mac de un usuario en el dispositivo supere las 50, un caso excepcional de alto volumen que probablemente no afecte a los dispositivos típicos de una sola cuenta o de pocas cuentas.

Windows Hello frente a claves de seguridad FIDO2

Dimensión	Windows Hello (Autenticador de plataforma)	Clave de seguridad FIDO2 (autenticador itinerante)
Portabilidad	Vinculado al dispositivo. El usuario debe volver a registrarse en cada dispositivo.	Portátil entre dispositivos mediante USB, NFC o Bluetooth.
Usuario ideal	Trabajadores con dispositivos asignados, trabajadores del conocimiento	Trabajadores de primera línea, entornos de dispositivos compartidos
Costo de infraestructura	No se requiere la compra de hardware (utiliza el TPM existente).	Se requiere la compra de una llave física por usuario.
Requisito de PKI	Opcional (solo para el modelo de fideicomiso de certificados)	Ninguna
Inicio de sesión RDP/VDI	Compatible con Remote Credential Guard o Certificate Trust.	Compatible con inicio de sesión web en Windows 11 24H2 y Windows Server 2025.

Beneficios en materia de seguridad y operaciones

Resistencia al phishing

Las credenciales de Windows Hello están vinculadas criptográficamente al origen de la parte que confía en ellas, es decir, al dominio del sitio web o del proveedor de identidad. Una credencial registrada para login.microsoftonline.com no responderá a un desafío de un dominio similar falsificado. Esta propiedad de vinculación al origen, definida en la especificación WebAuthn, es la razón principal por la que los ataques de phishing son ineficaces contra la autenticación FIDO2 y Windows Hello.

Sin riesgo para la base de datos de credenciales

Dado que no se almacena ninguna clave secreta compartida en el servidor, no hay ningún hash de contraseña ni credencial que robar del proveedor de identidad. El servidor solo almacena la clave pública del usuario, que resulta inútil para un atacante que no tenga acceso a la clave privada correspondiente, la cual está protegida por el TPM del dispositivo.

Máster en Bellas Artes por Diseño

Windows Hello es inherentemente multifactor. Combina algo que usted posee, el dispositivo registrado con la clave vinculada al TPM, con algo que usted es, un dato biométrico, o algo que usted sabe, un PIN local del dispositivo. Esto cumple con los requisitos de MFA según NIST SP 800-63B Autenticador Nivel 2 (AAL2) para la mayoría de los casos de uso empresarial. Los entornos de alta seguridad que requieren AAL3 pueden exigir la certificación TPM mediante una política, verificando que la clave reside en hardware certificado.

Resistencia al phishing

Accesibilidad y experiencia de usuario.

El inicio de sesión biométrico elimina las barreras para los usuarios que tienen dificultades para introducir contraseñas. El reconocimiento facial permite la autenticación manos libres, y la naturaleza local de Windows Hello significa que no hay servidores que puedan quedar inaccesibles durante una interrupción del servicio. Microsoft informa que las organizaciones que han migrado a Windows Hello observan reducciones significativas en las llamadas al servicio de asistencia técnica relacionadas con el restablecimiento de contraseñas, una de las categorías de soporte de TI con mayor volumen.

Inicio de sesión único (SSO) FIDO2 en todas las aplicaciones

Las credenciales de Windows Hello funcionan en cualquier aplicación o sitio web compatible con FIDO2/WebAuthn, incluyendo Microsoft 365, aplicaciones protegidas por Azure, GitHub, Dropbox, plataformas de servicios financieros y un ecosistema cada vez mayor de aplicaciones SaaS empresariales. En implementaciones empresariales, WHfB proporciona inicio de sesión único tanto para recursos en la nube como locales, mediante Kerberos, sin que los usuarios tengan que autenticarse de nuevo para cada servicio.

Accesibilidad y experiencia de usuario

El inicio de sesión biométrico elimina las barreras para los usuarios que tienen dificultades para introducir contraseñas. El reconocimiento facial, en particular, permite la autenticación manos libres, y la naturaleza local de Windows Hello significa que no hay servidores que puedan quedar inaccesibles durante una interrupción del servicio. Microsoft informa que las organizaciones que han migrado a Windows Hello observan reducciones significativas en las llamadas al servicio de asistencia técnica relacionadas con el restablecimiento de contraseñas, una de las categorías de soporte de TI con mayor volumen.

Inicio de sesión único (SSO) FIDO2 en todas las aplicaciones

Las credenciales de Windows Hello funcionan en cualquier aplicación o sitio web compatible con FIDO2/WebAuthn, incluyendo Microsoft 365, aplicaciones protegidas por Azure, GitHub, Dropbox, plataformas de servicios financieros y un ecosistema cada vez mayor de aplicaciones SaaS empresariales. En implementaciones empresariales, WHfB proporciona inicio de sesión único tanto para recursos en la nube como locales (mediante Kerberos) sin que los usuarios tengan que autenticarse de nuevo para cada servicio.

Implementación de Windows Hello para empresas: lo que el departamento de TI necesita saber.

La implementación de Windows Hello para empresas requiere planificación en cuatro áreas: hardware, directorio, políticas e incorporación de usuarios.

Requisitos de hardware

• Se requiere TPM 2.0 para la protección de claves de nivel empresarial. TPM 1.2 es compatible, pero no se recomienda debido a la variabilidad de las políticas.
• Para el reconocimiento facial, se requiere una cámara infrarroja con capacidad anti-suplantación de identidad. Las cámaras web estándar no son suficientes para Windows Hello Face.
• Para la seguridad de inicio de sesión mejorada (ESS, por sus siglas en inglés), se requieren sensores biométricos especializados compatibles con ESS y un dispositivo con capacidad VBS y TPM 2.0.

Requisitos previos de directorio e identidad

• Confianza Kerberos en la nube: un inquilino de Microsoft Entra ID, sincronización de Entra Connect, controladores de dominio de Windows Server 2016 o posterior e Intune para la entrega de directivas.
• Confianza clave: una infraestructura de clave pública (PKI) empresarial para emitir certificados de autenticación Kerberos de centro de datos (RSA 2048 / SHA-256 como mínimo, proveedor de almacenamiento de claves obligatorio).
• Confianza en certificados: AD FS local, una infraestructura de clave pública (PKI) empresarial con plantillas de certificados de usuario e Intune o GPO para la gestión de políticas.

Configuración de directivas mediante Intune

Para Cloud Kerberos Trust, el catálogo de configuración de Intune requiere tres configuraciones de directiva clave: Usar Windows Hello para empresas (habilitado), Usar Cloud Trust para la autenticación local (habilitado) y Requerir dispositivo de seguridad (habilitado, lo que exige el almacenamiento de claves TPM). Las directivas de confianza de certificados no deben configurarse simultáneamente, ya que la confianza de certificados anula la confianza de la nube cuando ambas están presentes.

Inscripción de usuario

Una vez implementada la política y que el dispositivo cumpla con los requisitos previos, el aprovisionamiento de Windows Hello para empresas se inicia automáticamente tras el primer inicio de sesión del usuario. El usuario establece un PIN, cuya complejidad y longitud están reguladas por la política, y, opcionalmente, registra sus datos biométricos. El PIN es específico del dispositivo, nunca se transmite por la red y está protegido por la política de bloqueo del TPM, lo que hace que los intentos de descifrarlo por fuerza bruta sean prácticamente imposibles sin acceso físico al dispositivo.

Windows Hello y PKI: La conexión

Si bien Cloud Kerberos Trust reduce la dependencia de PKI para la mayoría de las implementaciones, PKI sigue siendo relevante para Windows Hello en varios escenarios:

• Las implementaciones de Certificate Trust emiten certificados de inicio de sesión de usuario en el contenedor de Windows Hello a través de una CA empresarial, lo que proporciona una equivalencia de tarjeta inteligente para escenarios que requieren autenticación basada en certificados.
• Los certificados de controlador de dominio son obligatorios tanto en el modelo de confianza de clave como en el de confianza de certificado. Estas plantillas deben utilizar criptografía moderna (RSA 2048+, SHA-256, categoría de proveedor de almacenamiento de claves), no plantillas v1 antiguas.
• La certificación de la clave TPM, cuando se aplica mediante una política, requiere que la CA verifique que la clave WHfB se generó dentro de un TPM certificado, lo que proporciona una cadena de garantía de hardware.
• Certificate Trust admite escenarios RDP/VDI y la firma de correo electrónico S/MIME, casos de uso no cubiertos por los modelos de confianza Kerberos basados ​​en claves o en la nube.
• Una vez implementados, los modelos de confianza no son intercambiables libremente. La migración de Confianza de clave a Confianza de Cloud Kerberos se admite directamente mediante Directiva de grupo o Intune. No existe una ruta directa equivalente de Confianza de certificado a Confianza de Cloud Kerberos: el contenedor de Windows Hello existente debe eliminarse antes de que el dispositivo pueda volver a implementarse con Confianza de Cloud Kerberos. Las organizaciones que planean abandonar la Confianza de certificado deben tener en cuenta este paso de reinscripción en lugar de tratarlo como un cambio exclusivo de directiva.

Para las organizaciones con una infraestructura de clave pública (PKI) heredada anterior a Windows Hello, la modernización de las plantillas es un requisito previo. Las plantillas de controlador de dominio heredadas (v1) carecen de la extensión de uso de claves (EKU) de autenticación Kerberos y no utilizan proveedores de almacenamiento de claves CNG, ambos necesarios para el funcionamiento de la confianza de certificados de WHfB.

Consideraciones sobre la alineación normativa y el cumplimiento

Windows Hello para empresas se ajusta a múltiples marcos normativos y de estándares vigentes:

Marco normativo / Reglamento	Relevancia de Windows Hello
Norma NIST SP 800-63B	WHfB con claves respaldadas por TPM y biometría cumple con AAL2. La certificación TPM y ESS pueden cumplir con los requisitos de AAL3.
Guía de CISA sobre autenticación multifactor resistente al phishing	La autenticación basada en FIDO2, que implementa WHfB, figura explícitamente como un método de autenticación multifactor (MFA) resistente al phishing en las directrices de CISA para las agencias federales.
Iniciativa de Microsoft para un futuro seguro	La función SFI de Microsoft, lanzada en noviembre de 2023, exige la autenticación multifactor (MFA) para todas las cuentas en la nube de Microsoft. Windows Hello es el principal mecanismo de entrega para consumidores y empresas.
Arquitectura de confianza cero	WHfB cumple con el pilar de identidad verificada de la norma NIST SP 800-207 Zero Trust al vincular la autenticación a un dispositivo y una biometría de usuario específicos, y no a una credencial compartida.
Directiva NIS2 (UE)	El artículo 21 de la NIS2 exige la autenticación multifactor para las entidades incluidas en su ámbito de aplicación. WHfB cumple este requisito para entornos basados ​​en Windows.

Mirando hacia el futuro: Consideraciones post-cuánticas y un futuro sin contraseñas

La estrategia de Microsoft es inequívoca: en mayo de 2025, la compañía anunció que todas las nuevas cuentas de Microsoft serían sin contraseña por defecto, eliminando así la opción de contraseña al crear una cuenta. Esto acelera una transición que Windows Hello ha estado impulsando desde 2015. Para los equipos de TI empresariales, la pregunta ya no es si implementar Windows Hello para empresas, sino qué modelo de confianza, a qué escala y en qué plazo.

Criptografía postcuántica y Windows Hello

Los pares de claves asimétricas generados por Windows Hello actualmente se basan en curvas elípticas o RSA algoritmos, ambos teóricamente vulnerables a computadoras cuánticas relevantes para la criptografía. El NIST finalizó sus estándares de criptografía post-cuántica el 13 de agosto de 2024 (FIPS 203, FIPS 204 y FIPS 205), y Microsoft ha declarado su compromiso con PQC migración a través de su infraestructura de autenticación. Las organizaciones que implementan Windows Hello for Business hoy deben estar atentas a las directrices de migración de NIST PQC y a la hoja de ruta de Microsoft para la agilidad de los algoritmos en el contenedor de claves de WHfB, ya que esto se convertirá en una consideración importante en la planificación dentro de un horizonte de cinco a diez años.

Los programas de inventario criptográfico y agilidad de Encryption Consulting, construidos en torno a CBOM seguroAyudamos a las organizaciones a mapear las dependencias criptográficas existentes, incluida la infraestructura de autenticación, antes de que sea necesaria una migración, en lugar de después.

Las claves de acceso como punto de convergencia

El ecosistema FIDO2/passkey está convergiendo hacia un modelo unificado donde los autenticadores de plataforma como Windows Hello, Passkeys de Apple y la implementación FIDO2 de Android ofrecen una experiencia de inicio de sesión consistente y resistente al phishing en todos los sistemas operativos. La integración de Entra passkey de Windows Hello, ahora disponible para todos, representa un paso hacia esta convergencia, permitiendo a las organizaciones estandarizar FIDO2 en sus flotas de dispositivos heterogéneas sin tener que gestionar mecanismos de autenticación separados para cada plataforma.

Cómo ayuda la consultoría de cifrado

La implementación de Windows Hello para empresas, ya sea en Cloud Kerberos Trust, Key Trust o Certificate Trust, depende del estado de la identidad y la infraestructura PKI subyacente. Servicios de PKI Ofrecemos consultoría integral a empresas que planifican o solucionan problemas en una implementación de WHfB: diseñamos la jerarquía de CA y las plantillas de certificados que necesita una implementación de Certificate Trust, modernizamos las plantillas de controladores de dominio heredadas para admitir Key Trust y validamos la configuración de Entra Connect y Entra Kerberos para Cloud Kerberos Trust.

Para las organizaciones que desean eliminar por completo la sobrecarga operativa de PKI, PKI como servicio proporciona una CA administrada y alojada en la nube para que los equipos de TI puedan admitir implementaciones de Key Trust o Certificate Trust sin operar directamente la infraestructura PKI local. Una vez que WHfB se implementa, Administrador de CertSecure Proporciona a los equipos de TI y seguridad visibilidad y automatización del ciclo de vida de los certificados de los que dependen los modelos de Confianza de Claves y Confianza de Certificados, incluidos los certificados de controlador de dominio y los certificados de inicio de sesión de usuario, lo que reduce el riesgo de que un certificado caducado o mal configurado interrumpa la autenticación de todo un sitio.

Preguntas frecuentes

¿Qué es Windows Hello y en qué se diferencia de una contraseña?

Windows Hello es el sistema de autenticación sin contraseña de Microsoft para Windows 10 y 11. En lugar de transmitir una clave secreta compartida (una contraseña) a un servidor, utiliza un par de claves asimétricas con respaldo TPM, donde la clave privada nunca sale del dispositivo. El usuario desbloquea la clave privada localmente mediante datos biométricos o un PIN, y el dispositivo firma un desafío criptográfico del proveedor de identidad. El servidor verifica la firma utilizando la clave pública del usuario. Nunca se transmite ni se almacena ninguna contraseña en el servidor.

¿Es Windows Hello suficientemente seguro para entornos empresariales?

Sí. Windows Hello para empresas con claves respaldadas por TPM cumple con el nivel de garantía de autenticación 2 (AAL2) de NIST SP 800-63B, el estándar requerido para la mayoría de las aplicaciones empresariales. Está explícitamente catalogado como un método de autenticación multifactor (MFA) resistente al phishing en la guía de CISA para agencias federales. Para escenarios de mayor seguridad, la aplicación de la certificación TPM y la seguridad de inicio de sesión mejorada (ESS) pueden elevar aún más el nivel de seguridad. Organizaciones de sectores regulados, como finanzas, sanidad y gobierno, han implementado WHfB como su mecanismo de autenticación principal.

¿Cuál es la diferencia entre Windows Hello para empresas y Windows Hello para consumidores?

Windows Hello para consumidores está configurado para cuentas personales de Microsoft y no admite proveedores de identidad empresariales, directivas de grupo, administración de Intune ni acceso a recursos locales. Windows Hello para empresas (WHfB) es la variante empresarial, integrada con Microsoft Entra ID y/o Active Directory, administrada mediante Intune o GPO, y capaz de proporcionar inicio de sesión único (SSO) tanto para recursos en la nube como locales mediante Cloud Kerberos Trust o Certificate Trust.

¿Necesito una infraestructura de clave pública (PKI) para implementar Windows Hello para empresas?

No necesariamente. Cloud Kerberos Trust, el modelo de implementación predeterminado recomendado por Microsoft, no requiere una infraestructura de certificados ni una infraestructura de clave pública (PKI) empresarial para los dispositivos de los usuarios finales. Solo requiere un objeto Microsoft Entra Kerberos, creado con un único comando de PowerShell, y la entrega mediante directivas de Intune o GPO. Certificate Trust, que sí requiere PKI, está reservado para entornos que necesitan autenticación equivalente basada en certificados, escenarios RDP/VDI o firma S/MIME.

¿Pueden todas las cuentas utilizar la confianza Kerberos en la nube?

No. Las cuentas que son miembros directos o indirectos de grupos de seguridad integrados con privilegios, incluidos los administradores de dominio, no pueden autenticarse mediante Cloud Kerberos Trust. El objeto AzureADKerberos está sujeto a las mismas restricciones de la Política de replicación de contraseñas que un controlador de dominio estándar de solo lectura, que bloquea las cuentas con privilegios por diseño. Microsoft no recomienda flexibilizar esta política, ya que hacerlo introduce una vía de ataque entre Entra ID y Active Directory. Las organizaciones que necesiten WHfB para cuentas con privilegios deben usar Key Trust o Certificate Trust para dichas cuentas.

¿Puedo migrar directamente de la confianza en certificados a la confianza en Kerberos en la nube?

No. No existe una ruta de migración directa de Confianza de Certificados a Confianza de Kerberos en la Nube. El contenedor de Windows Hello existente debe eliminarse antes de que un dispositivo pueda volver a implementarse en Confianza de Kerberos en la Nube. La migración de Confianza de Claves a Confianza de Kerberos en la Nube es más sencilla y puede realizarse mediante Directiva de Grupo o Intune sin eliminar el contenedor.

¿Qué ocurre si el dispositivo de un usuario se pierde o es robado?

Dado que las credenciales de Windows Hello están vinculadas a un dispositivo, no se pueden usar en otro. Si se pierde un dispositivo, un administrador puede eliminar inmediatamente la clave pública registrada de la cuenta de Entra ID o Active Directory del usuario, invalidando así todos los intentos de autenticación desde ese dispositivo. Los datos biométricos almacenados en el dispositivo están cifrados y no se pueden reconstruir para obtener una muestra biométrica utilizable. Por lo tanto, no tienen ningún valor para un ladrón sin el sensor biométrico del propio dispositivo.

¿Qué relación tiene Windows Hello con las claves de acceso FIDO2?

Windows Hello es un autenticador de plataforma certificado por FIDO2, lo que significa que implementa las especificaciones WebAuthn y CTAP2. Cualquier credencial creada mediante Windows Hello para un sitio web o aplicación compatible con FIDO2 es, técnicamente, una clave de acceso, una credencial FIDO2 vinculada al dispositivo. Windows Hello también admite el registro de claves de acceso de Entra ID, ahora disponible de forma general, lo que permite a las organizaciones usar Windows Hello como autenticador de claves de acceso FIDO2 para cuentas de Microsoft Entra, incluso en dispositivos que no están unidos a Entra.

¿Se puede utilizar Windows Hello para sesiones RDP o VDI?

Esto depende del modelo de implementación. Cloud Kerberos Trust no admite RDP con credenciales proporcionadas. Certificate Trust admite RDP/VDI mediante la inscripción de un certificado de usuario en el contenedor WHfB. Como alternativa, Remote Credential Guard puede proteger las sesiones RDP sin necesidad de Certificate Trust. A partir de Windows 11 24H2 y Windows Server 2025, la autenticación FIDO2, incluido Windows Hello, se puede usar para RDP mediante inicio de sesión web cuando está habilitada tanto en el cliente como en el host.

Elija el modelo de autenticación adecuado con confianza.

¿Listo para planificar una implementación de Windows Hello para empresas o resolver un problema de modelo de confianza híbrido? Ver Servicios de PKI en acción, o lea sobre Mejores prácticas de Windows Hello.