Windows Hello para empresas, claves de hardware y SSO

Si gestionas identidades en entornos Microsoft, seguramente has oído hablar de Windows Hello, Windows Hello para empresas, claves de hardware y SSO, pero es fácil perderse entre tanta sigla, tipo de confianza y requisitos. Además, en despliegues híbridos con Active Directory heredado, entender qué aporta realmente WHfB frente a un simple inicio de sesión con PIN o biometría puede marcar la diferencia entre un proyecto fluido… o un dolor de cabeza continuo.

En este artículo vamos a desgranar de forma muy detallada cómo funciona Windows Hello para empresas (WHfB), qué papel juegan las claves de hardware, cómo se consigue el inicio de sesión único (SSO) y en qué se diferencia del Windows Hello “normal” de usuario doméstico. Veremos las fases internas (registro de dispositivo, aprovisionamiento, sincronización de claves, certificados y autenticación), los modelos de implementación (solo nube, híbrido y local), los tipos de confianza, requisitos de PKI, licencias, retos reales de despliegue y cómo encaja todo esto con enfoques modernos como FIDO2 y la seguridad sin contraseña.

Windows Hello vs Windows Hello para empresas: qué cambia realmente

Windows Hello (a secas) es la experiencia de usuario para iniciar sesión con PIN o biometría en un dispositivo Windows, pensada tanto para entornos domésticos como profesionales. Windows Hello para empresas (WHfB), en cambio, es la extensión corporativa que añade capacidades de identidad fuerte integradas con Active Directory y Microsoft Entra ID.

Con ambos métodos puedes usar PIN, huella o reconocimiento facial apoyados en el TPM para iniciar sesión en el equipo. Incluso puedes autenticarte contra un dominio local clásico. La gran diferencia es que WHfB crea y administra credenciales criptográficas de nivel empresarial: pares de claves o certificados vinculados al usuario y al dispositivo, gestionados por políticas y aprovechables para SSO en recursos locales y en la nube.

Mientras Windows Hello “normal” se limita, en esencia, a reemplazar la contraseña por un gesto cómodo en ese equipo, WHfB genera una credencial fuerte que el proveedor de identidad (AD, Microsoft Entra ID o AD FS) reconoce, almacena y utiliza para emitir tokens de acceso y aplicar acceso condicional, validación estricta de KDC, PRT, Kerberos en la nube y otros controles avanzados.

La pregunta lógica es: si ya tengo dispositivos unidos a dominio, gestionados con Intune, con TPM y biometría, y SSO a la nube mediante sincronización de hash de contraseñas, ¿qué gano exactamente añadiendo WHfB? La respuesta está en cómo se construyen y validan las claves, cómo se vincula el dispositivo, y en la capacidad de extender esa seguridad a todo el ecosistema, no solo al inicio de sesión local.

Arquitectura básica: fases de Windows Hello para empresas

WHfB es un sistema distribuido que se apoya en varios componentes: dispositivo, TPM, proveedor de identidades, PKI, sincronización de directorios y mecanismos de SSO. Para entenderlo sin perdernos, conviene dividir su funcionamiento en cinco fases cronológicas de implementación.

1. Registro del dispositivo

La primera pieza del puzle es el registro del dispositivo frente al proveedor de identidades (IdP). Este paso permite asociar el equipo con una identidad en el directorio y habilitar que se autentique automáticamente cuando un usuario inicia sesión.

En entornos de solo nube o híbridos, el IdP es Microsoft Entra ID y el dispositivo se registra en su servicio de registro de dispositivos (unido a Microsoft Entra, unido híbrido o registrado). En escenarios puramente locales, el IdP suele ser AD FS con su Servicio de Registro de Dispositivos Empresariales.

Al completar este registro, el IdP asigna al equipo una identidad propia que se usará para establecer confianza dispositivo-directorio en sucesivas autenticaciones. Este registro se clasifica por “tipo de combinación” (device join type), que determina si el dispositivo está unido a dominio local, a Entra ID, híbrido, o simplemente registrado como personal.

2. Aprovisionamiento: creación del contenedor de Windows Hello

Una vez que el dispositivo está registrado, comienza la fase de aprovisionamiento de la credencial de Windows Hello para empresas. Aquí es donde se crea el llamado contenedor de Windows Hello, que agrupa de forma lógica todo el material criptográfico del usuario en ese equipo.

El flujo típico de aprovisionamiento sigue estos pasos principales, siempre tras una autenticación inicial con credenciales débiles (usuario y contraseña):

• El usuario se autentica con MFA en el IdP (Microsoft Entra MFA u otro método compatible, o un adaptador de MFA en AD FS en entornos locales).
• Tras superar ese segundo factor, se le pide que configure un PIN y, si hay hardware compatible, un gesto biométrico (huella, rostro, iris).
• Al confirmar el PIN, Windows genera el contenedor de Windows Hello para esa cuenta en ese equipo.
• Dentro de ese contenedor se crea un par de claves criptográficas (pública y privada), enlazadas al TPM cuando existe o, en su defecto, protegidas por software.
• La clave privada permanece en el dispositivo y no se puede exportar, quedando protegida por el TPM y por los protectores de PIN/biometría.
• La clave pública se registra en el IdP y se vincula al objeto de usuario: en Microsoft Entra ID se escribe en el usuario, y en escenarios locales federados, AD FS la transfiere a Active Directory.

El contenedor incluye además una clave administrativa, útil para escenarios como restablecimiento de PIN; en equipos con TPM se almacena también un bloque de datos con certificados del propio TPM. Todo el material se desbloquea solo cuando el usuario realiza el gesto (PIN o biometría), y esa combinación MFA inicial establece la confianza entre usuario, dispositivo e IdP.

3. Claves dentro del contenedor: autenticación e identificador de usuario

Dentro del contenedor de Windows Hello encontramos varios tipos de claves, con roles distintos, todas cifradas con protectores basados en PIN o biometría:

• Clave de autenticación: un par de claves asimétricas que se genera durante el registro y que debe desbloquearse siempre con PIN o gesto biométrico. Es la base sobre la que se recifran otros materiales cuando se cambia el PIN.
• Claves de identificador de usuario: pueden ser simétricas o asimétricas según el IdP y el modelo (clave o certificado). Se usan para firmar o cifrar solicitudes y tokens dirigidos al proveedor de identidad. En entornos empresariales, normalmente se generan como pares de claves asimétricas, registrando la parte pública en el IdP.

Estas claves de identificador de usuario se pueden obtener de dos formas principales: asociadas a la PKI corporativa para emitir certificados (por ejemplo, para VPN, RDP o autenticación Kerberos basada en certificados) o generadas directamente por el IdP en escenarios sin PKI (modelo de clave pura).

La misma infraestructura permite usar Windows Hello como autenticador FIDO2/WebAuthn en aplicaciones y páginas web compatibles. Los sitios pueden crear una credencial FIDO dentro del contenedor de Windows Hello; en visitas posteriores, el usuario se autentica con su PIN o biometría sin exponer contraseñas.

4. Sincronización de claves en entornos híbridos

En arquitecturas híbridas donde coexisten Microsoft Entra ID y Active Directory, no basta con registrar la clave en la nube. Tras el aprovisionamiento, es necesario que la clave pública de WHfB se sincronice hacia el directorio local para permitir autenticación y SSO contra recursos on-premises.

En estos escenarios, Microsoft Entra Connect Sync se encarga de copiar la clave pública al atributo msDS-KeyCredentialLink del objeto de usuario en Active Directory. Esta sincronización es clave para que el controlador de dominio pueda validar las firmas que genera el dispositivo con la clave privada almacenada en el TPM.

5. Inscripción de certificados (solo cuando hace falta)

En algunos modelos (como la confianza de certificado), además de las claves, la organización necesita emitir certificados de autenticación a los usuarios. En ese caso se activa una fase adicional de inscripción de certificados.

Después de registrar la clave pública, el cliente genera una solicitud de certificado que envía a la entidad de registro de certificados, normalmente integrada en AD FS en despliegues federados. Esa CRA valida la petición utilizando la PKI corporativa y emite un certificado que se almacena dentro del contenedor de Hello, reutilizable para autenticación en recursos locales que aún dependen de certificados.

Autenticación, clave privada y SSO: cómo se encaja todo

Una vez completadas las fases de registro y aprovisionamiento, el día a día del usuario se reduce a algo muy sencillo: un gesto (PIN o biometría) que “libera” la clave privada en el dispositivo. Lo interesante es lo que pasa por detrás.

Cuando el usuario desbloquea el equipo, Windows usa la parte privada de la credencial de WHfB para firmar criptográficamente datos que se envían al IdP. Este verifica la firma utilizando la clave pública almacenada en el objeto de usuario. Como el PIN nunca sale del dispositivo y la clave privada tampoco, el proceso es resistente a phishing y robo de credenciales tradicionales.

En escenarios de Microsoft Entra ID, al completar esa autenticación se obtiene un Primary Refresh Token (PRT), un token web JSON con información del usuario y del dispositivo. Es la base del SSO hacia aplicaciones en la nube y, en combinación con Microsoft Entra Kerberos o la sincronización de claves, también hacia recursos locales.

Sin PRT, aunque el usuario tenga una credencial WHfB válida, perdería el inicio de sesión único y se vería forzado a autenticarse continuamente en cada app. De ahí que las directivas de acceso condicional, basadas en dispositivo o riesgo, suelan tener en cuenta la presencia y validez de ese PRT.

Para Active Directory, cuando se usa confianza de clave o de certificado, WHfB actúa como una tarjeta inteligente virtual: el usuario firma un nonce o desafío del KDC, el controlador de dominio valida el certificado o la clave, y emite un ticket TGT de Kerberos, habilitando así el SSO hacia servicios locales integrados con Kerberos.

Seguridad interna: biometría, TPM y protección frente a ataques

Uno de los pilares de WHfB es que los datos biométricos nunca abandonan el dispositivo. Las plantillas que generan los sensores se almacenan localmente en bases de datos cifradas (por ejemplo, en la ruta C:\WINDOWS\System32\WinBioDatabase) usando claves únicas por base de datos, protegidas con AES en modo CBC y SHA-256 como función hash.

Eso significa que, incluso si un atacante consiguiera acceder a esos archivos, no podría reconstruir la imagen de la cara o la huella del usuario, ni utilizarlas en otro dispositivo. Además, cada sensor mantiene su propio almacén, reduciendo la posibilidad de un único punto central de robo de plantillas biométricas.

El PIN de Windows Hello para empresas también está mejor protegido que una contraseña clásica. No viaja por la red, se valida localmente, y el TPM impone bloqueos ante demasiados intentos incorrectos, inutilizando ataques de fuerza bruta o diccionario. Y si alguien roba el PIN, solo le serviría en ese dispositivo concreto, ya que la credencial está ligada al hardware.

Frente a amenazas modernas (cómo saber si un email es phishing, reutilización de contraseñas, robo masivo de credenciales), WHfB se apoya en criptografía de clave pública vinculada al dispositivo, evitando por diseño la exposición de secretos compartidos. Esto encaja de lleno con los estándares y recomendaciones de normativas como NIST 800-63B y con modelos de seguridad de confianza cero.

Modelos de implementación: nube, híbrido y local

WHfB es flexible en cuanto a topología, pero esa flexibilidad trae consigo cierta complejidad. A grandes rasgos, podemos hablar de tres modelos de despliegue que combinan de distintas formas Microsoft Entra ID, Active Directory, PKI y federación.

Modelo solo en la nube

En organizaciones que viven prácticamente al 100 % en Microsoft 365 y otros servicios SaaS, sin infraestructura local relevante, el modelo más simple es el de solo nube con dispositivos unidos a Microsoft Entra. En este escenario:

• Todos los usuarios y dispositivos residen en Microsoft Entra ID.
• El registro de dispositivos y de claves se realiza directamente en la nube.
• No se necesita PKI corporativa ni certificados de controlador de dominio.
• El SSO se basa en el PRT y en tokens de Microsoft Entra para las aplicaciones.

Es la opción más directa para compañías cloud-first, con coste de infraestructura bajo y despliegue relativamente sencillo, ideal cuando no se accede a recursos on-premises o estos son mínimos.

Modelo híbrido: el caso más habitual

La gran mayoría de empresas se encuentran en un punto intermedio: Active Directory histórico combinado con Microsoft Entra ID sincronizado. Aquí WHfB brilla, pero también es donde más se sufren los problemas de configuración si no se planifica bien.

En un entorno híbrido, las identidades se sincronizan con Microsoft Entra Connect Sync, y hay varias combinaciones posibles de modelo de implementación (híbrido) y tipo de confianza (Kerberos en la nube, clave o certificado). El objetivo suele ser ofrecer:

• SSO a servicios en la nube (SharePoint Online, Teams, aplicaciones OIDC/SAML).
• Acceso transparente a recursos locales (shares, apps Kerberos, VPN, RDP).
• Una ruta de salida gradual de las contraseñas, manteniendo aplicaciones heredadas.

Los principales tipos de confianza en escenarios híbridos son:

• Kerberos en la nube: Microsoft Entra Kerberos emite TGT para AD sin necesidad de PKI adicional. Es el modelo híbrido más moderno y sencillo, ya que aprovecha infraestructura existente de FIDO2 y no requiere sincronizar claves públicas a AD.
• Confianza de clave (Key Trust): los usuarios se autentican en AD usando una clave enlazada al dispositivo; los controladores de dominio necesitan certificados específicos. Requiere PKI para los DC, pero no para certificados de usuario.
• Confianza de certificado: se emiten certificados de autenticación de usuario y se usan para obtener TGT Kerberos. Necesita PKI completa, AD FS como CRA y configuración más intensa.

Escoger bien el tipo de confianza es crucial: ninguno es inherentemente “más seguro”, pero sí varían costo, complejidad y requisitos de infraestructura. La confianza de Kerberos en la nube suele ser la mejor opción para despliegues nuevos, siempre que las versiones de Windows cliente y servidor cumplan los mínimos.

Modelo local puro

Organizaciones con restricciones regulatorias fuertes, o con poca o ninguna adopción de la nube, pueden optar por un despliegue de WHfB 100 % local, apoyado en Active Directory y AD FS. En este modelo:

• El registro de dispositivos lo gestiona AD FS.
• La autenticación puede basarse en clave o certificado, pero siempre respaldada por una PKI empresarial.
• Las opciones de MFA pasan por adaptadores para AD FS o soluciones como Azure MFA Server (ya heredada) integradas on-premises.

Este enfoque da un control total sobre los datos de autenticación, pero exige un esfuerzo considerable de mantenimiento (PKI, AD FS, publicación de CRL accesibles por equipos no unidos a dominio, etc.), algo que no todas las organizaciones están dispuestas a asumir a largo plazo.

PKI, certificados de controlador de dominio y CRL accesibles

En los modelos que dependen de certificados (ya sea para los usuarios, para los controladores de dominio, o ambos), la PKI se convierte en el corazón de la confianza. WHfB exige validación estricta de los KDC cuando un dispositivo unido a Microsoft Entra se autentica frente a un dominio local.

En la práctica, esto significa que el certificado del controlador de dominio debe cumplir una serie de condiciones técnicas: emitido por una CA raíz de confianza para el dispositivo, basado en la plantilla de autenticación Kerberos, con EKU de “autenticación de KDC”, nombre DNS correcto, RSA 2048 y SHA-256 como algoritmo de firma, entre otros requisitos.

Además, es imprescindible que el dispositivo pueda comprobar la revocación de los certificados. Aquí aparece el clásico problema de las CRL: un dispositivo unido solo a Microsoft Entra no puede leer rutas LDAP en Active Directory si todavía no se ha autenticado, por lo que es necesario publicar el punto de distribución de la CRL en una URL HTTP accesible sin autenticación.

Esto implica preparar un servidor web (IIS, por ejemplo), crear un directorio virtual (cdp), ajustar permisos NTFS y de recurso compartido, desactivar el almacenamiento en caché offline, configurar la CA para publicar la CRL en ese recurso compartido y exponerla vía HTTP. Una vez hecho, hay que renovar los certificados de los controladores de dominio para que incluyan el nuevo CDP y asegurarse de desplegar el certificado raíz de empresa a los dispositivos unidos a Microsoft Entra (p. ej., con Intune y un perfil de “certificado de confianza”).

Sincronización de directorios, MFA y configuración de dispositivos

La experiencia que tendrá el usuario final con Windows Hello para empresas depende en gran medida de cómo se integren sincronización de directorios, MFA y configuración de políticas.

En despliegues híbridos, Microsoft Entra Connect Sync no solo sincroniza cuentas; también puede sincronizar atributos críticos como msDS-KeyCredentialLink, que contiene la clave pública de WHfB necesaria para la autenticación en AD. En entornos locales con Azure MFA Server, la sincronización se usa para importar usuarios al servidor MFA que luego consulta al servicio en la nube para las comprobaciones.

En cuanto a autenticación multifactor, las organizaciones disponen de varias opciones: Microsoft Entra MFA para escenarios de nube o híbridos, métodos externos integrados mediante autenticación externa en Entra ID o via federación, y adaptadores MFA de terceros para AD FS en entornos on-premises. La marca FederatedIdpMfaBehavior en dominios federados determina si Entra ID acepta, exige o ignora el MFA realizado por el IdP federado, lo que puede ser crítico para que el aprovisionamiento de WHfB funcione correctamente.

La configuración del propio WHfB en los equipos puede realizarse con directiva de grupo (GPO) o CSP vía MDM (por ejemplo, Intune). En organizaciones modernas es habitual habilitar el registro automático de WHfB, forzar MFA en el primer inicio de sesión, definir políticas de complejidad del PIN y controlar qué formas biométricas se aceptan (solo sensores certificados, cámaras IR, etc.).

En paralelo, es fundamental contemplar la experiencia de recuperación: restablecimiento de PIN de autoservicio, métodos alternativos como llaves FIDO2, y cifrado BitLocker para proteger datos en reposo si el dispositivo se pierde o es robado.

Licencias, requisitos de sistema y limitaciones prácticas

Uno de los mitos habituales es que para usar WHfB se necesita siempre Microsoft Entra ID P1 o P2. En realidad, la funcionalidad base de WHfB está disponible con el nivel gratuito de Entra ID, y la autenticación multifactor necesaria para el aprovisionamiento sin contraseña también se puede habilitar sin licencias premium, aunque características como inscripción MDM automática, acceso condicional avanzado o escritura diferida de dispositivos sí requieren niveles superiores.

En términos de sistema operativo, prácticamente todas las versiones cliente modernas de Windows soportan WHfB, pero la confianza de Kerberos en la nube requiere mínimos concretos (por ejemplo, Windows 10 21H2 con ciertos parches o versiones específicas de Windows 11). En el lado servidor, cualquier versión de Windows Server soportada puede actuar como DC en general, aunque la parte de Kerberos en la nube necesita versiones y actualizaciones específicas en los controladores de dominio.

Más allá de lo técnico, hay retos muy prácticos: equipos compartidos donde WHfB, al ser específico de dispositivo y usuario, encaja regular; hardware sin TPM 2.0 o sin sensores biométricos; o entornos en los que el coste de renovar parques antiguos, desplegar PKI y actualizar DC de 2012 hace que la adopción completa de WHfB resulte poco atractiva a corto plazo.

En muchos casos, el camino razonable pasa por combinar WHfB con otros factores sin contraseña (llaves FIDO2, tarjetas inteligentes, autenticación telefónica) para cubrir estaciones compartidas, plataformas no Windows o usuarios muy móviles, dejando WHfB como autenticador principal en portátiles corporativos unidos a Entra o híbridos.

Mirando todo el escenario, Windows Hello para empresas aporta bastante más que “un PIN bonito”: introduce credenciales asimétricas ligadas al hardware, verificación estricta del KDC, integración profunda con Microsoft Entra ID y Active Directory, y un marco sólido para SSO seguro tanto en la nube como on-premises. No obstante, su valor real frente al Windows Hello básico depende de tu punto de partida: en entornos cloud-first o híbridos modernos con PKI y DC actualizados, el salto en seguridad y gestión compensa claramente el esfuerzo; en dominios muy antiguos, con poca infraestructura preparada y sin planes de modernización, puede que tenga más sentido avanzar primero en hardware, PKI y control de accesos antes de abrazar todo el potencial de WHfB.