Windows Hello para empresas: Introducción a la autenticación multifactor

Puntos Clave

• Windows Hello para empresas sustituye una clave secreta compartida (contraseña) por un par de claves asimétricas vinculadas al Módulo de plataforma segura (TPM) del dispositivo, que se desbloquea mediante un PIN o datos biométricos, por lo que se considera una verdadera autenticación multifactor (MFA): algo que usted posee (la clave vinculada al dispositivo) más algo que usted sabe o es (PIN o datos biométricos).
• La confianza en Cloud Kerberos es el modelo de implementación recomendado actualmente por Microsoft para entornos híbridos. Sustituye a los modelos anteriores de confianza híbrida de claves y certificados para la mayoría de las organizaciones, ya que no requiere infraestructura de clave pública (PKI) ni controlador de dominio de Windows Server 2016.
• La confianza híbrida en certificados sigue teniendo cabida cuando una organización necesita autenticación basada en certificados para la sustitución de tarjetas inteligentes, el acceso remoto al escritorio o escenarios de VPN que el inicio de sesión respaldado por Kerberos no puede satisfacer por sí solo.
• TPM 2.0 es el requisito de hardware básico para las nuevas implementaciones; la compatibilidad con TPM 1.2 solo existe para dispositivos empresariales heredados y no debe planificarse para nuevos despliegues.
• Para que la implementación sea exitosa, debe incluir comprobaciones de validación, una ruta de reversión documentada, un registro centralizado y un manual de solución de problemas, no solo un interruptor de directiva en Intune o Directiva de grupo.

Publicado: agosto de 2023. Actualizado: agosto de 2026. Revisado por el equipo de Gestión de Identidad y Acceso de Encryption Consulting.

¿Qué es Windows Hello para empresas y cómo proporciona la autenticación multifactor (MFA)?

Windows Hello para Empresas (WHfB) es la tecnología de inicio de sesión sin contraseña de Microsoft para empresas. Durante el registro, el dispositivo genera un par de claves asimétricas: la clave privada permanece sellada dentro del Módulo de Plataforma Segura (TPM) del dispositivo, un chip de hardware diseñado para almacenar claves criptográficas e impedir su extracción, mientras que la clave pública se registra con la identidad del usuario en Microsoft Entra ID (anteriormente Azure Active Directory, renombrado en 2023) o Active Directory. Para iniciar sesión, el usuario desbloquea la clave privada localmente con un PIN, huella digital o reconocimiento facial; este gesto local nunca sale del dispositivo y el proveedor de identidad nunca lo ve. Lo que el proveedor de identidad verifica es una firma criptográfica producida por la clave privada. Por eso, WHfB cumple con la autenticación multifactor (MFA) por sí solo: la posesión de la clave vinculada al dispositivo es un factor, y el PIN o el dato biométrico que la desbloquea es el segundo. Para obtener una explicación completa de cómo funciona el protocolo de principio a fin, consulte el artículo del Centro de Educación de Encryption Consulting, ¿Qué es Windows Hello para empresas ?, y para ver casos de uso reales, Casos de uso y mejores prácticas de Windows Hello.

En el despliegue de WHfB, surgen constantemente dos acrónimos que conviene definir antes que nada: TPM (Trusted Platform Module) es el chip de seguridad de hardware que genera y sella la clave privada, y FIDO2 es un estándar de autenticación sin contraseña abierto para claves de seguridad y autenticadores de plataforma que Windows también admite como método de inicio de sesión junto con WHfB, no en lugar de él. Microsoft Entra ID también ha comenzado a admitir las claves de acceso Entra, que permiten que una credencial de Windows Hello funcione como una clave de acceso basada en FIDO2 para un inicio de sesión resistente al phishing en diferentes navegadores y plataformas, no solo en el inicio de sesión nativo de Windows.

¿Qué modelo de implementación debería utilizar: confianza Kerberos en la nube, confianza de clave híbrida, confianza de certificado híbrido o solo en la nube?

Para la mayoría de las organizaciones híbridas, utilice la confianza Kerberos en la nube. Es la opción predeterminada recomendada por Microsoft, ya que no requiere infraestructura de clave pública (PKI), ni ajustes en la autoridad de certificación, ni un controlador de dominio de Windows Server 2016 (o posterior) como requisito indispensable. Esto hace que su implementación sea más rápida y su operación más económica que la de los dos modelos de confianza híbrida anteriores. Elija la confianza de certificado híbrida solo cuando tenga un requisito específico, como escritorio remoto con respaldo de certificado, VPN o reemplazo de tarjeta inteligente, que el inicio de sesión con respaldo Kerberos no pueda satisfacer. El artículo del Centro de Educación de Encryption Consulting, « Windows Hello para modelos de implementación empresarial» , describe la arquitectura completa de cada modelo; la tabla a continuación sirve como referencia para tomar decisiones rápidas sobre cuál elegir.

Modelo de liberación	Proveedor de identidad	Se requiere infraestructura de clave pública (PKI).	Mejor ajuste
Solo nube	Solo con ID de Microsoft Entra	No	Dispositivos conectados a Entra sin dependencia de Active Directory local
Confianza híbrida y en la nube Kerberos	Microsoft Entra ID más Active Directory local (unión híbrida)	No	La mayoría de las organizaciones híbridas; la configuración predeterminada recomendada actualmente por Microsoft
Híbrido, confianza clave	Microsoft Entra ID más Active Directory local	No	Implementaciones heredadas que ya utilizan la confianza de claves; no se recomienda para nuevas implementaciones.
Híbrido, fideicomiso de certificados	Microsoft Entra ID más AD local, AD FS o CA en la nube	Sí:	Organizaciones que necesitan autenticación respaldada por certificados para VPN, RDP o reemplazo de tarjetas inteligentes
Confianza en las instalaciones, llave o certificado	Servicios de federación de Active Directory (AD FS)	Confianza en el certificado únicamente	Entornos totalmente locales sin unión híbrida de Entra ID

Dado que tanto la confianza en certificados híbridos como la confianza en certificados locales dependen de la emisión y renovación de certificados de dispositivos y usuarios a gran escala, la fiabilidad de la implementación depende exclusivamente de la autoridad de certificación que la respalda. CertSecure Manager de Encryption Consulting automatiza la emisión, renovación y revocación de certificados para este tipo de carga de trabajo de autenticación basada en PKI, y PKI como servicio ofrece a los equipos que no desean gestionar su propia CA una alternativa administrada.

¿Cuáles son los requisitos previos para implementar Windows Hello para empresas?

Confirme estos cinco requisitos previos antes de abrir una sola política de implementación:

1. TPM 2.0 en los dispositivos de destino. TPM 2.0 es la versión base para nuevas implementaciones y un requisito de hardware para Windows 11. TPM 1.2 solo es compatible como solución heredada para dispositivos empresariales existentes; no se recomienda planificar nuevas implementaciones en torno a él.
2. Infraestructura de identidad implementada. Para la confianza Kerberos en la nube o la confianza híbrida de clave o certificado, los dispositivos deben estar unidos a Microsoft Entra de forma híbrida con Microsoft Entra Connect (o sincronización en la nube de Entra Connect) sincronizando usuarios. Para implementaciones exclusivamente en la nube, los dispositivos deben estar unidos a Microsoft Entra sin dependencia local.
3. Licencia. WHfB viene incluido con Windows; la confianza Kerberos en la nube y la aplicación del acceso condicional requieren un plan Microsoft Entra ID que incluya estas funciones (generalmente incluido en Microsoft 365 E3/E5 o Entra ID P1/P2). Confirme la licencia actual con su contrato de Microsoft, ya que Microsoft ajusta periódicamente qué nivel incluye cada funcionalidad.
4. Preparación para PKI, solo para confianza de certificados. Si opta por la confianza de certificados híbrida o local, su autoridad de certificación necesita una plantilla de certificado de autenticación WHfB, NDES o una CA en la nube para la inscripción, y un proceso de renovación probado antes de que comience el programa piloto.
5. Mecanismo de implementación de políticas. Se debe configurar y probar primero la Directiva de grupo para los dispositivos unidos al dominio, o Intune (u otra solución MDM) para los dispositivos unidos a Entra y los dispositivos unidos de forma híbrida, en una unidad organizativa o grupo de dispositivos que no sea de producción.

¿Cómo se implementa Windows Hello para empresas paso a paso?

Siga esta secuencia en lugar de habilitar WHfB para todos los inquilinos el primer día:

1. Evaluar la flota. Inventaria los dispositivos según la versión de TPM, la edición de Windows y el estado de unión híbrida o Entra. Marca cualquier dispositivo sin TPM 2.0 para su reemplazo de hardware en lugar de gestionar excepciones.
2. Seleccione el modelo de implementación. Utilice la tabla de decisiones anterior; por defecto, utilice la confianza Kerberos en la nube a menos que un requisito de respaldo de certificado obligue a utilizar una confianza de certificado híbrida o local.
3. Configure los requisitos previos de identidad. Confirme que la unión híbrida o la unión Entra funcionan correctamente en todo el grupo piloto y, para la confianza en el certificado, confirme primero en un entorno de laboratorio que la plantilla de CA y la ruta de inscripción se emiten correctamente.
4. Cree la política de despliegue. Cree la configuración de WHfB en Intune (Dispositivos > Inscripción > Windows Hello para empresas o un perfil del Catálogo de configuración) o en la Directiva de grupo, estableciendo explícitamente la complejidad del PIN, la disponibilidad biométrica y el modelo de confianza. No deje el modelo de confianza en un valor predeterminado no administrado.
5. Definir un grupo piloto. Asigne la política a un pequeño grupo piloto multifuncional, de entre 25 y 100 dispositivos según el tamaño de la organización, que incluya tanto usuarios presenciales como remotos.
6. Provisión y validación del piloto. Solicite a los usuarios piloto que completen la inscripción y confirmen que el inicio de sesión funciona tanto para el desbloqueo local como para cualquier recurso protegido por Acceso Condicional. Utilice las comprobaciones de validación de la siguiente sección antes de expandir la función.
7. Expándese por oleadas. Implementar la actualización en grupos de dispositivos adicionales por etapas, supervisando las fuentes de registro que se indican a continuación en cada fase, en lugar de hacerlo después de la implementación completa.
8. Desactivar deliberadamente la autenticación de reserva. Desactive la contraseña heredada o la autenticación multifactor para un grupo únicamente una vez que su oleada haya superado la validación, no antes.

¿Cómo se valida una implementación de Windows Hello para empresas?

Valide una implementación con estas comprobaciones, en orden, antes de considerar que una oleada está completa:

• Confirmación de aprovisionamiento. Consulte el Visor de eventos para ID de evento 300 En Registros de aplicaciones y servicios > Microsoft > Windows > HelloForBusiness, se confirma que el dispositivo creó correctamente un contenedor de Windows Hello.
• Estado de unión del dispositivo. Ejecutar dsregcmd /status en el punto final y confirmar AzureAdJoined, DomainJoined (para híbridos), y NgcSet Todos devuelven los valores esperados para el modelo elegido.
• Confirmación de inicio de sesión. Revise los registros de inicio de sesión de Microsoft Entra ID para los usuarios piloto y confirme que el método de autenticación aparece como Windows Hello para empresas en lugar de contraseña, y que no aparecen fallos inesperados de acceso condicional.
• Emisión de certificados, únicamente para fideicomiso de certificados. Confirme que el certificado de autenticación de WHfB se emitió para el dispositivo o usuario con la plantilla correcta y que se renueva automáticamente antes de su vencimiento.
• El sistema de reserva sigue funcionando. Confirme que un usuario piloto que aún no se haya inscrito puede autenticarse mediante el método existente, lo que demuestra que la opción de reserva no se ha desactivado prematuramente.

¿Cuál es el procedimiento de reversión si la implementación provoca bloqueos?

Si una oleada produce bloqueos o fallos generalizados de aprovisionamiento, revierta en este orden en lugar de solucionar problemas en tiempo real con usuarios de producción:

1. Desactive la política WHfB para el grupo afectado. en Intune o Directiva de grupo para que ningún otro dispositivo intente aprovisionarse.
2. Restaurar la autenticación de reserva (contraseña más MFA existente) para los usuarios afectados si ya estaba desactivado, para que puedan iniciar sesión inmediatamente.
3. Elimine el contenedor WHfB dañado en los puntos finales afectados. Esto se puede hacer desde Configuración > Cuentas > Opciones de inicio de sesión eliminando Windows Hello, o a gran escala dirigiendo el contenedor NGC a través del script de dispositivo o la capacidad de remediación de su MDM.
4. Confirme que el servicio de asistencia técnica tenga una ruta de desbloqueo documentada. Para cualquier usuario que quede bloqueado durante una reversión, consulte su proceso de recuperación de identidad existente en lugar de improvisar uno.
5. Identificar la causa raíz antes de volver a intentarlo. Compare las fuentes de registro que se indican a continuación con la ola que falló antes de volver a habilitar la política para ese grupo.

¿Cómo se registran y auditan los eventos de autenticación de Windows Hello para empresas?

Los eventos de autenticación de Windows Hello para empresas se almacenan en tres lugares, y un registro de auditoría completo necesita los tres:

• Visor de eventos locales, En Registros de aplicaciones y servicios > Microsoft > Windows > HelloForBusiness, que registra los eventos de aprovisionamiento, desbloqueo y contenedores en el propio punto final.
• Registros de inicio de sesión de Microsoft Entra ID, que registran cada intento de autenticación en la nube, el método utilizado, las políticas de acceso condicional evaluadas y el resultado, y que pueden exportarse a un SIEM para su almacenamiento y para generar alertas.
• Registros de la autoridad de certificación, para implementaciones de confianza de certificados, que registran la emisión, renovación y revocación de los certificados de autenticación de WHfB y deben revisarse junto con los registros de inicio de sesión al investigar un fallo de autenticación.

Envíe las tres fuentes a su SIEM en lugar de depender únicamente del Visor de eventos local; una investigación de bloqueo que solo tenga el registro del punto final no puede confirmar si el proveedor de identidad o el dispositivo rechazaron el inicio de sesión.

¿Cuáles son los errores de aprovisionamiento más comunes de Windows Hello para empresas y cómo se solucionan?

Síntoma	Causa probable	Primer paso para resolver
El aprovisionamiento no se iniciará después de iniciar sesión.	El dispositivo aún no está conectado en modo híbrido o Entra, o la conexión no se ha sincronizado.	Ejecutar dsregcmd /status y confirme el estado de unión antes de volver a intentarlo; espere a que se sincronice si la unión se acaba de completar.
La configuración del PIN falla o aparece atenuada.	El TPM está deshabilitado, no está presente o aún no se ha adquirido.	Verifique que TPM 2.0 esté habilitado en el firmware y aparezca como listo en Seguridad de Windows > Seguridad del dispositivo.
La creación del contenedor falla silenciosamente.	La directiva de grupo o la directiva de Intune WHfB entra en conflicto con otra directiva de inicio de sesión en el dispositivo.	Compruebe si existen perfiles de configuración de WHfB duplicados o conflictivos dirigidos al mismo dispositivo.
Falló la inscripción del certificado, solo se puede confiar en el certificado.	Error de configuración de NDES, plantilla CA o punto de inscripción	Confirme los permisos de la plantilla de certificado WHfB y la ruta de inscripción en un dispositivo de laboratorio antes de volver a intentarlo en producción.
El inicio de sesión se realiza correctamente a nivel local, pero el acceso condicional bloquea el acceso a los recursos.	La política de acceso condicional aún no reconoce a WHfB como un método de autenticación multifactor satisfactorio.	Confirme que la política de autenticación de acceso condicional o de autenticación multifactor (MFA) incluya explícitamente Windows Hello para empresas.

¿Qué resultados operativos debería medir después del despliegue?

Realice un seguimiento de estos resultados a partir de su propia base de referencia, en lugar de asumir que una cifra genérica del sector se aplica a su entorno:

• Volumen de tickets de soporte para restablecimiento de contraseña, Se compararon los resultados antes y después de cada fase de implementación para la población inscrita.
• Tasa de cobertura de MFA resistente al phishing, el porcentaje de usuarios activos que inician sesión con WHfB (u otro método resistente al phishing) en lugar de contraseña más un factor MFA heredado.
• Tasa de éxito de aprovisionamiento por oleada, el porcentaje de dispositivos objetivo que completaron la inscripción sin necesidad de un ticket de soporte.
• Incidentes de seguridad relacionados con credenciales, Se realizó un seguimiento a lo largo del tiempo en comparación con la línea de base previa a WHfB para la misma población de usuarios.

¿Cuáles son las limitaciones de Windows Hello para empresas?

WHfB no es un reemplazo universal para todos los escenarios de autenticación. Está limitado al dispositivo por diseño, por lo que un usuario sin su dispositivo registrado (un portátil nuevo, un quiosco compartido, un dispositivo personal fuera del registro MDM) aún necesita un método alternativo, lo que significa que la mayoría de las organizaciones ejecutan WHfB junto con, no en lugar de, un método MFA secundario durante y después del despliegue. Los modelos de confianza de certificados añaden una sobrecarga operativa de PKI, gestión de plantillas y supervisión de renovación que la confianza Kerberos en la nube evita. Los dispositivos antiguos sin TPM 2.0 no pueden participar en un despliegue moderno sin un reemplazo de hardware. Y WHfB en sí no se extiende a plataformas que no sean Windows ni a aplicaciones de línea de negocio que se autentiquen fuera de Microsoft Entra ID o Active Directory, que es donde una estrategia más amplia sin contraseña o FIDO2 debe cubrir la brecha.

¿Qué recomendaría Encryption Consulting?

Para la mayoría de las organizaciones híbridas, recomendamos comenzar el despliegue de WHfB en la confianza Kerberos en la nube, ya que elimina la dependencia de PKI y permite que un grupo piloto entre en producción más rápidamente. Si su entorno ya necesita autenticación respaldada por certificados para VPN, RDP o reemplazo de tarjetas inteligentes, o si está consolidando múltiples mecanismos de autenticación en una autoridad de certificación, la confianza híbrida en certificados justifica la inversión adicional en PKI, y lograr que PKI funcione correctamente desde el principio es más importante que la política de WHfB en sí. CertSecure Manager de Encryption Consulting gestiona la automatización del ciclo de vida de los certificados (emisión, renovación, revocación) para que un despliegue de confianza en certificados WHfB no se degrade silenciosamente a medida que los certificados caducan sin ser detectados. Las organizaciones que no desean operar una CA pueden usar PKI como servicio para una alternativa totalmente administrada. Para la protección de claves respaldada por TPM que sustenta cada modelo de confianza WHfB, nuestro HSM como servicio extiende el mismo principio de protección de claves respaldada por hardware a las cargas de trabajo, claves y certificados del lado del servidor más allá del punto final. Nuestro equipo también gestiona proyectos completos de implementación de WHfB de principio a fin, desde la evaluación de la infraestructura hasta el despliegue por fases; consulte nuestro servicio de implementación de Windows Hello para Empresas y el informe de un proyecto completado para el despliegue de PKI y Windows Hello para Empresas de este fabricante de bebidas . Encryption Consulting cuenta con la certificación ISO/IEC 27001:2022 y la acreditación SOC 2, por lo que aplicamos el mismo rigor tanto si asesoramos en su despliegue como si gestionamos la PKI subyacente.

Conclusión

Windows Hello para Empresas transforma la autenticación multifactor (MFA) de una contraseña escrita y un código en una clave criptográfica vinculada al dispositivo, desbloqueada mediante información que el usuario conoce o posee. Por ello, ofrece mayor resistencia al phishing que la mayoría de los métodos MFA tradicionales que aún se utilizan. La decisión sobre el modelo de implementación es crucial: se recomienda usar la confianza Kerberos en la nube por defecto, a menos que un requisito de certificado obligue a optar por una confianza híbrida o local. Además, es fundamental considerar los requisitos previos, la validación, la reversión y el registro como parte del plan de implementación, no como una solución a posteriori en caso de fallo. Las organizaciones que planifican estas realidades operativas desde el principio evitan los bloqueos que paralizan las implementaciones de WHfB.

Encryption Consulting ofrece servicios relacionados con la protección de datos en toda la empresa. Nuestros servicios incluyen CodeSign Secure , nuestra solución de firma de código; CertSecure Manager , nuestra solución de gestión de certificados; PKI como servicio ; y HSM como servicio . Para cualquier consulta sobre las soluciones de seguridad que ofrecemos, póngase en contacto con nosotros en [email protected]

Preguntas frecuentes

¿Windows Hello para empresas es lo mismo que Windows Hello?

No. Windows Hello es la función para consumidores que permite desbloquear un dispositivo personal con un PIN o datos biométricos. Windows Hello para empresas es la versión empresarial, administrada mediante Directiva de grupo o Intune, integrada con Microsoft Entra ID o Active Directory, y diseñada para cumplir con los requisitos de autenticación multifactor (MFA) y acceso condicional de la organización, en lugar de simplemente desbloquear un único dispositivo.

¿Necesitamos una autoridad de certificación para implementar Windows Hello para empresas?

Solo si elige un modelo de confianza de certificados. La confianza Kerberos en la nube, la confianza de clave híbrida y las implementaciones exclusivamente en la nube no requieren una infraestructura de clave pública (PKI). Si su organización necesita autenticación respaldada por certificados para VPN, RDP o reemplazo de tarjetas inteligentes, la confianza de certificados híbrida o local requiere que una autoridad de certificación emita una plantilla de certificado de autenticación WHfB.

¿Puede Windows Hello para empresas reemplazar todos nuestros métodos de autenticación multifactor?

Puede reemplazar la contraseña más un segundo factor para dispositivos Windows registrados, pero no cubre a los usuarios de dispositivos personales no registrados, quioscos compartidos o plataformas fuera de Windows. La mayoría de las organizaciones mantienen un método secundario resistente al phishing, como una clave de seguridad FIDO2, disponible para esos escenarios en lugar de usar WHfB como único método de autenticación en todas partes.

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

La clave privada nunca sale del TPM y no se puede extraer para usarla en otro dispositivo, por lo que un dispositivo perdido o robado no expone por sí solo una credencial reutilizable; un atacante aún necesitaría el PIN o la información biométrica para desbloquearlo, y la mayoría de los TPM se bloquean tras varios intentos fallidos de PIN. La práctica habitual sigue siendo revocar inmediatamente el registro del dispositivo en Microsoft Entra ID para que ya no pueda autenticarse.

¿Cuánto tiempo suele tardar el despliegue de Windows Hello para empresas?

Los plazos varían según el tamaño de la flota, el estado de la integración híbrida existente y si se implementa la confianza de certificados, pero un despliegue por fases, que incluye una evaluación de la infraestructura y un programa piloto hasta el despliegue completo en producción, suele durar entre 8 y 12 semanas para una organización mediana. Los despliegues de confianza de certificados generalmente tardan más porque la preparación de la infraestructura de clave pública (PKI) debe validarse antes de que comience el programa piloto.

Referencias

• Microsoft Learn. Descripción general de Windows Hello para empresas.
• Microsoft Learn. Planifique una implementación de Windows Hello para empresas..
• Microsoft Learn. Guía de implementación de confianza Kerberos en la nube.
• Microsoft Learn. Guía de implementación de confianza de certificados híbridos.
• Microsoft Learn. Guía de implementación de confianza de clave híbrida.
• Microsoft Learn. Cómo funciona Windows Hello para empresas.
• Microsoft Learn. Preguntas frecuentes sobre Windows Hello para empresas.
• Microsoft Learn. ID de evento 300: Windows Hello creado correctamente.
• Microsoft Learn. Iniciar sesión en Windows con la clave de seguridad FIDO2 y el ID de Microsoft Entra.
• Microsoft Learn. Habilitar la clave de acceso de Microsoft Entra en Windows.