Windows Hello for Business: claves hardware y SSO explicado

Windows Hello para Empresas (Windows Hello for Business, WHfB) se ha convertido en una de las piezas clave de la estrategia de identidad de Microsoft para empresas: adiós a las contraseñas de toda la vida y hola a un modelo de autenticación basado en claves criptográficas, biometría, PIN y dispositivos de confianza. En combinación con Microsoft Entra ID y el inicio de sesión único (SSO), permite que los usuarios accedan a recursos en la nube y en local con un solo gesto, pero manteniendo controles de seguridad de nivel empresarial.

En este artículo vamos a desgranar, con calma pero sin rodeos, cómo funciona la autenticación de Windows Hello for Business cuando intervienen claves de hardware, dispositivos con TPM y escenarios de SSO frente a Microsoft Entra ID y Active Directory. Veremos las fases internas (registro de dispositivos, aprovisionamiento, sincronización de claves, certificados y autenticación), qué papel juega el PRT en el SSO, cómo se integra con Kerberos en entornos híbridos y qué requisitos de infraestructura necesitas para que todo funcione como un reloj.

Arquitectura general de Windows Hello para Empresas y su modelo sin contraseñas

Windows Hello para Empresas no es solo “poner un PIN o la cara” para iniciar sesión; es un sistema distribuido que combina identidad de usuario, identidad de dispositivo y claves criptográficas protegidas por hardware. La autenticación se basa en un par de claves pública/privada o en certificados, enlazados al dispositivo (TPM) y desbloqueados por algo que el usuario sabe (PIN) o algo que es (biometría).

La gran diferencia frente a las contraseñas clásicas es que ya no existe un “secreto compartido” que viaje por la red o se almacene centralmente: el servidor (Microsoft Entra ID o Active Directory) guarda únicamente la parte pública de la clave, mientras que la privada nunca sale del dispositivo. Cuando el usuario quiere autenticarse, Windows firma un desafío (nonce) con la clave privada, y el proveedor de identidades valida esa firma con la clave pública registrada.

Este enfoque hace que WHfB sea resistente al phishing: aunque un atacante engañase al usuario para que introduzca su nombre de usuario en un sitio malicioso, no podría reproducir la autenticación sin la clave privada vinculada al TPM del equipo. El resultado es un sistema de autenticación en dos fases (clave + PIN/biometría) que cumple los criterios de MFA fuerte, pero con una experiencia de usuario mucho más fluida y con la seguridad de Windows 11.

WHfB se integra de forma nativa con Microsoft Entra ID y con Active Directory, permitiendo diferentes modelos de despliegue: solo nube, híbrido o totalmente local. Además, puede convivir con tarjetas inteligentes y claves FIDO2, e incluso reutilizar la PKI existente de la organización cuando se opta por modelos basados en certificados.

Fases del funcionamiento de Windows Hello for Business

Para entender bien qué ocurre “por debajo del capó”, lo más práctico es dividir el ciclo de vida de Windows Hello para Empresas en varias fases encadenadas: registro de dispositivos, aprovisionamiento, sincronización de claves (en híbrido), inscripción de certificados (si se usan) y, finalmente, autenticación y SSO.

1. Registro de dispositivos

Antes de emitir credenciales de WHfB a un usuario, el dispositivo debe tener identidad propia. Este proceso se llama registro de dispositivo y asocia el equipo con el proveedor de identidades (IdP) de la organización.

Dependiendo del tipo de despliegue, cambia el IdP y el servicio de registro:

• Implementaciones en la nube o híbridas: el IdP es Microsoft Entra ID. El dispositivo se registra en el Device Registration Service de Entra ID y se convierte en “dispositivo unido a Microsoft Entra” o “híbrido unido a Microsoft Entra”.
• Implementaciones puramente locales: el IdP es AD FS, y el dispositivo se registra en el servicio de registro de dispositivos empresariales que expone AD FS.

Como resultado del registro, el IdP concede al equipo una identidad propia, que se usará en posteriores intercambios de autenticación de usuario y en la obtención de tokens. Existen distintos “tipos de combinación” o estados de unión (solo Entra, híbrido, unido a dominio clásico + registrado, etc.), que determinan cómo se comporta el dispositivo en entornos mixtos.

2. Aprovisionamiento de Windows Hello for Business

La fase de aprovisionamiento es cuando realmente se crean las credenciales de Hello para un usuario concreto en un dispositivo. Aquí aparece un concepto clave: el contenedor de Windows Hello, que es una estructura lógica donde se almacena todo el “material de clave” asociado a las identidades del usuario en ese equipo.

El flujo típico de aprovisionamiento incluye varios pasos encadenados:

1. El usuario inicia sesión con sus credenciales tradicionales (normalmente, usuario y contraseña) y el sistema lanza la experiencia de configuración de WHfB, solicitando autenticación multifactor ante el IdP (Microsoft Entra ID o AD FS).
2. Tras superar correctamente el MFA, se pide al usuario que defina un PIN y, si el hardware lo permite, que registre biometría (huella, rostro, iris).
3. Confirmado el PIN, Windows crea el contenedor de Windows Hello en el dispositivo.
4. Se genera un par de claves pública y privada de autenticación, enlazado al TPM (si existe) o, en su defecto, protegido por software.
5. La clave privada se guarda localmente y queda sellada al TPM, no exportable.
6. La clave pública se registra en el IdP y se ata a la cuenta del usuario:
   1. En escenarios en la nube o híbridos, el servicio de registro de dispositivos la escribe en el objeto de usuario de Microsoft Entra ID.
   2. En escenarios locales con AD FS, se almacena en Active Directory.

Dentro del contenedor, cada “protector” (PIN, gesto biométrico, etc.) mantiene su propia copia cifrada de la clave de autenticación. Si hay TPM, el PIN se usa como entropía en una operación de sellado; si no, se deriva una clave simétrica para cifrar el material. Esto permite que el usuario desbloquee el mismo par de claves con diferentes gestos, sin debilitar la protección.

Además de la clave principal de autenticación, el contenedor puede incluir otros elementos, como una clave administrativa para escenarios de restablecimiento de PIN, blobs con certificados de TPM, y, sobre todo, diferentes tipos de claves de identificador de usuario que se usan para protocolos concretos (WebAuthn/FIDO2, Entra ID, certificados de usuario para VPN o RDP, etc.).

Detalles de las claves de autenticación e identificador de usuario

La clave de autenticación de Windows Hello es siempre un par asimétrico (pública/privada) generado durante el registro. Cada vez que hay que usarla, debe desbloquearse con el PIN o la biometría. Si el usuario restablece su PIN, se genera un nuevo par de claves de autenticación y se re-cifra todo el material que estaba protegido por el par anterior.

Las claves de identificador de usuario pueden ser simétricas o asimétricas, según el IdP y el escenario. En entornos empresariales modernos (Microsoft Entra ID, Active Directory, cuentas Microsoft personales), lo habitual es que sean también pares de claves asimétricos, generados y almacenados en el dispositivo, con la parte pública registrada en el proveedor de identidad.

Existen dos caminos principales para generar las claves de identificador de usuario en organizaciones:

• Asociarlas a la PKI corporativa, de forma que la clave se vincule a un certificado emitido por la CA de la empresa. Esto facilita la transición desde infraestructuras basadas en certificados (VPN, RDP con certificados de usuario, etc.) a WHfB.
• Permitir que sea directamente el IdP (Entra ID o AD FS) el que gestione el par de claves asociado a la identidad, reduciendo la complejidad de PKI cuando no es imprescindible.

Estas claves se usan para demostrar posesión mediante firma de nonces o tokens de autenticación, tanto frente a controladores de dominio (Kerberos) como frente a servicios web que utilicen WebAuthn (FIDO2). Un mismo dispositivo puede albergar varias credenciales FIDO asociadas a sitios web o aplicaciones diferentes, todas gestionadas dentro del contenedor de Windows Hello.

Almacenamiento local de datos biométricos

Un punto que suele preocupar a muchos usuarios y auditores es qué pasa con sus rasgos biométricos. En Windows Hello para Empresas, las plantillas biométricas solo se almacenan en el dispositivo, en una base de datos local a la que no accede Microsoft ni se sincroniza con la nube.

Cada sensor biométrico mantiene su propia base de datos de plantillas (por ejemplo, en C:\WINDOWS\System32\WinBioDatabase), cifrada con una clave aleatoria única por base de datos, protegida con AES en modo CBC y con hash SHA-256. Aunque un atacante consiguiera esa base de datos, no podría reconstruir imágenes “en crudo” de la cara o la huella; se trata de datos de plantilla irreversibles.

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

En despliegues híbridos, la clave pública registrada en Microsoft Entra ID debe llegar también a Active Directory para que el usuario pueda autenticarse sin contraseña tanto frente a servicios en la nube como en recursos on-premises.

Este proceso lo gestiona Microsoft Entra Connect Sync, que sincroniza la clave pública de usuario desde Entra ID al atributo msDS-KeyCredentialLink del objeto de usuario en Active Directory. De esta manera, los controladores de dominio pueden validar autenticaciones basadas en clave (escenario key trust) o usar la información asociada para modelos de cloud Kerberos trust.

4. Inscripción de certificados (cuando se usa el modelo basado en certificados)

Si tu organización ya tiene una PKI desplegada y quiere aprovecharla con WHfB, puedes optar por el modelo de confianza basado en certificados. En este caso, tras registrar la clave en el IdP, el cliente genera una petición de certificado y la envía a una entidad de registro (CRA) alojada típicamente en un servidor AD FS.

La CRA valida la solicitud y la canaliza hacia la CA corporativa, que emite un certificado de usuario. Ese certificado se almacena dentro del contenedor de Windows Hello y se usará para autenticarse frente a recursos locales que requieran certificados de cliente (por ejemplo, auténtica Kerberos con certificados o VPN IPsec).

5. Fase de autenticación: cómo se “libera” la clave

Una vez superadas las fases previas, la experiencia diaria del usuario es muy sencilla: para iniciar sesión o desbloquear el dispositivo, usa su PIN o biometría. Técnicamente, lo que hace ese gesto es “desbloquear” el acceso a la parte privada de las credenciales de WHfB almacenadas en el TPM.

Ni el PIN ni la clave privada salen del dispositivo o se envían al IdP. El PIN actúa como entropía para las operaciones de firma con la clave privada; en otras palabras, es un disparador local que autoriza el uso de la clave. Cuando una aplicación o el propio sistema necesita autenticarse frente a un IdP, Windows firma un bloque de datos con la clave privada y manda la firma al servidor, que comprueba la validez con la clave pública registrada.

Este patrón se repite tanto para autenticación directa frente a Entra ID (mediante protocolos web y el proveedor Cloud AP) como para autenticaciones Kerberos contra Active Directory (ya sea mediante clave, certificado o confianza de Kerberos en la nube).

Token de actualización principal (PRT) y Single Sign-On (SSO)

El SSO moderno en entornos Microsoft gira en torno al Token de Actualización Principal o PRT. Mientras que en Kerberos clásico el “token maestro” es el TGT, en escenarios Entra ID el PRT es un token JWT que contiene información del usuario y del dispositivo, y permite ir obteniendo tokens de acceso para distintas aplicaciones sin que el usuario tenga que volver a autenticarse explícitamente.

El PRT se emite normalmente durante el inicio de sesión o desbloqueo del dispositivo cuando el usuario se autentica con WHfB en un equipo unido a Microsoft Entra o híbrido unido a Entra. En dispositivos personales solo registrados, el PRT se obtiene al agregar una cuenta profesional o educativa a Windows.

Sin PRT no hay SSO real hacia aplicaciones protegidas por Entra ID o AD FS. Si por alguna razón el dispositivo no dispone de un PRT válido, los usuarios verán solicitudes de credenciales reiteradas y, además, fracasarán las políticas de acceso condicional que requieran información del dispositivo (por ejemplo, “solo dispositivos marcados como conformes”).

En escenarios de acceso remoto con VPN y SAML SSO, cuando el usuario ya se ha autenticado con WHfB en el sistema operativo, el PRT permite a Entra ID “recordar” que ya se ha satisfecho la MFA resistente al phishing. Por eso, durante el inicio de sesión en la VPN vía SAML, Entra ID puede marcar la sesión como MFA-compliant sin pedir un segundo factor adicional, algo que suele generar debates con aseguradoras y auditores.

Flujo de autenticación de dispositivos unidos a Microsoft Entra hacia Entra ID

En un dispositivo unido a Entra, la cadena de eventos durante un inicio de sesión con WHfB es, simplificada, la siguiente:

• El usuario descarta la pantalla de bloqueo e introduce su PIN o biometría en el proveedor de credenciales de WHfB.
• Winlogon pasa esas credenciales a LSASS, que a su vez las entrega al proveedor de seguridad de autenticación en la nube (Cloud AP).
• Cloud AP solicita un nonce a Microsoft Entra ID; Entra ID responde con ese valor.
• El cliente firma el nonce con la clave privada del usuario y envía el resultado a Entra ID.
• Entra ID verifica la firma con la clave pública previamente registrada, y si todo es correcto genera un PRT, cifrado con la clave de transporte del dispositivo.
• Cloud AP descifra la clave de sesión del PRT usando la clave de transporte privada (protegida por TPM) y guarda el PRT en caché protegida.
• LSASS informa a Winlogon de que la autenticación ha sido satisfactoria y se crea la sesión de usuario.

Desde ese momento, el PRT se usará para conseguir tokens de acceso y de actualización para distintas aplicaciones (Microsoft 365, SaaS de terceros, aplicaciones SAML, etc.) sin que el usuario tenga que volver a escribir nada, siempre sujeto a las políticas de acceso condicional configuradas.

Autenticación de Windows Hello for Business frente a Active Directory

Cuando el dispositivo es solo “unido a Entra” pero necesita acceder a recursos locales, entra en juego la integración con Active Directory a través de distintos modelos: confianza Kerberos en la nube, key trust y certificate trust. Todos ellos permiten que una credencial de WHfB genere vales Kerberos sin necesidad de contraseñas.

Confianza de Kerberos en la nube con Microsoft Entra

En el modelo de Cloud Kerberos Trust, Microsoft Entra ID emite un TGT parcial asociado a la identidad del usuario y firmado por el servicio de Kerberos en la nube. Cuando el dispositivo necesita un TGT completo de un controlador de dominio on-premises, envía ese TGT parcial al KDC local, que lo valida y emite un TGT “real” para el usuario.

Este enfoque simplifica bastante la infraestructura, porque delega en Entra ID parte de la lógica de autenticación, pero exige que los controladores de dominio estén actualizados y correctamente configurados para reconocer y validar esos TGT parciales procedentes de la nube.

Modelo de confianza mediante clave (Key Trust)

En el modelo key trust, el controlador de dominio valida directamente una firma realizada con la clave privada del usuario registrada en Active Directory. El flujo de alto nivel es:

• El proveedor Kerberos en el cliente firma los datos de preautenticación con la clave privada y envía la firma junto con la clave pública (en un certificado autofirmado) al KDC.
• El KDC comprueba que el certificado es autofirmado, localiza esa clave pública en el atributo msDS-KeyCredentialLink del usuario y valida la firma.
• Si todo cuadra (UPN, claves, firma), el KDC devuelve un TGT al cliente.

Después, el cliente valida el certificado del KDC (cadena hasta una raíz de confianza, EKU de autenticación KDC, nombre alternativo que coincida con el dominio, algoritmos seguros como SHA-256 y RSA 2048, etc.) antes de aceptar ese TGT y almacenarlo en caché para futuras peticiones de vales de servicio.

Modelo de confianza mediante certificado (Certificate Trust)

En el modelo basado en certificados, el usuario presenta al KDC un certificado de cliente emitido por la CA de la organización. Kerberos usa la información del certificado (DN del sujeto o UPN en el SAN) como pista para localizar la cuenta en Active Directory.

El controlador de dominio valida la cadena de certificados hasta una raíz de confianza, comprueba que el certificado está dentro de su periodo de validez y no se ha revocado, y usa la clave pública del certificado para verificar los datos de preautenticación firmados. Si todo es correcto, emite el TGT, que el cliente acepta tras verificar a su vez el certificado del KDC.

Requisitos de infraestructura para entornos híbridos seguros

Conseguir que un dispositivo unido a Microsoft Entra se autentique correctamente en Active Directory implica prestar mucha atención a la configuración de la PKI corporativa, los puntos de distribución de CRL y la confianza en certificados de controlador de dominio.

Puntos de distribución de listas de revocación (CDP/CRL)

Un error muy habitual es dejar el CDP solo en LDAP dentro del dominio. Los dispositivos unidos a Entra ID que no forman parte del dominio no pueden leer esa ruta LDAP antes de autenticarse, lo que genera un bucle: necesitan validar el certificado del DC para autenticarse, pero no pueden leer la CRL sin haberse autenticado.

La solución recomendada es publicar la CRL en un punto accesible por HTTP sin autenticación, normalmente un sitio web interno, y añadir esa URL como CDP en los certificados de la CA y de los controladores de dominio. El proceso implica:

• Configurar un servidor web (IIS) con un directorio virtual (por ejemplo, cdp) y habilitar la exploración de directorios.
• Ajustar permisos NTFS y de recurso compartido para que la CA pueda publicar automáticamente los archivos de CRL en ese directorio.
• Actualizar la configuración de la CA para incluir la nueva URL HTTP como CDP y como ubicación de publicación de CRL y delta CRL.
• Volver a emitir los certificados de los controladores de dominio para que incluyan el nuevo CDP HTTP.

Tras estos pasos, los dispositivos unidos a Entra pueden validar el certificado del DC sin necesidad de estar autenticados, eliminando el problema circular y permitiendo que la autenticación basada en certificados o en clave funcione correctamente.

Requisitos de los certificados de controlador de dominio

Para que Windows Hello para Empresas aplique la “validación estricta de KDC” al autenticarse desde un dispositivo unido a Entra, los certificados de los controladores de dominio deben cumplir varios criterios:

• La CA raíz emisora debe estar en el almacén de entidades de certificación raíz de confianza del dispositivo.
• El certificado debe basarse en la plantilla de autenticación Kerberos adecuada.
• Debe incluir el EKU de autenticación de KDC.
• El nombre alternativo del sujeto (SAN) debe contener un nombre DNS que coincida con el dominio.
• El algoritmo de firma debe ser SHA-256 y la clave pública debe ser RSA de al menos 2048 bits.

Si algo de esto falla, los dispositivos unidos a Entra pueden rechazar el certificado del DC y la autenticación con WHfB hacia Active Directory no funcionará, incluso aunque con contraseñas clásicas sí parezca ir todo bien.

Distribución del certificado raíz de la CA en dispositivos unidos a Entra

Para que confíen en los certificados de los controladores de dominio, los dispositivos unidos a Microsoft Entra deben tener instalado el certificado raíz de la CA de empresa. Normalmente se exporta ese certificado desde un controlador de dominio y se despliega en los equipos mediante Microsoft Intune con una directiva de “certificado de confianza”.

La directiva debe apuntar al almacén de certificados de equipo (raíz de confianza) y asignarse a los grupos de usuarios o dispositivos adecuados. Una vez aplicada, los equipos verán como “de confianza” los certificados emitidos por esa CA, incluido el de los KDC, y la validación estricta podrá completarse correctamente.

Modelos de despliegue, retos y buenas prácticas

Windows Hello para Empresas admite despliegues solo en la nube, híbridos o totalmente locales, y cada modelo tiene implicaciones prácticas diferentes en términos de complejidad, compatibilidad y costes.

En organizaciones cloud-first sin Active Directory on-premises, lo más sencillo es un modelo solo nube donde todo el gobierno de claves y autenticación se realiza desde Microsoft Entra ID, sin necesidad de PKI local ni AD FS. Los usuarios acceden vía SSO a Microsoft 365 y a aplicaciones SaaS con WHfB como autenticador sin contraseña.

En la mayoría de empresas medianas y grandes, el escenario más realista sigue siendo el híbrido: recursos críticos siguen en local, existen aplicaciones Kerberos puras y, al mismo tiempo, se consumen servicios en la nube. Aquí es donde hay que decidir entre confianza Kerberos en la nube, key trust y certificate trust, evaluar compatibilidad de aplicaciones heredadas y, en muchos casos, seguir conviviendo con métodos basados en contraseña o tarjetas inteligentes durante un tiempo.

En sectores muy regulados o con requisitos extremos de soberanía de datos (gobierno, ciertas entidades financieras o sanitarias), puede tener sentido un modelo totalmente local con AD FS y PKI propia, donde WHfB se usa como sustituto de contraseñas pero sin depender de la nube. A cambio, la complejidad operativa y de mantenimiento es mayor.

En todos los casos, hay retos comunes: hardware compatible, estaciones de trabajo compartidas, resistencia de los usuarios al cambio, y justificar ante aseguradoras y auditores que WHfB realmente cuenta como MFA. La clave está en combinar WHfB con políticas de acceso condicional que requieran autenticadores resistentes al phishing, habilitar re-autenticación o step-up MFA donde sea razonable (por ejemplo, en operaciones muy sensibles o conexiones VPN críticas) y documentar bien el modelo de amenazas.

Si se acompaña de una buena capacitación, políticas claras de PIN, supervisión de inicios de sesión y un despliegue escalonado apoyado en Intune o GPO, Windows Hello para Empresas permite a las organizaciones dar un salto cualitativo hacia un modelo de identidad sin contraseñas, reduciendo la superficie de ataque, mejorando el cumplimiento normativo y ofreciendo a los usuarios una experiencia de inicio de sesión mucho más natural y rápida.