Windows Hello for Business Factor MFA Independiente Entra Octubre 2026: El Segundo Requisito de Clave de Acceso Desaparece

Windows Hello for Business Factor MFA Independiente Entra Octubre 2026: qué anunció Microsoft

Windows Hello for Business factor MFA independiente Entra octubre 2026 es el cambio que los equipos de identidad ya deberían estar planificando. En la publicación de Message Center MC1450134, «Microsoft Entra: Windows Hello for Business y macOS Platform SSO como factores MFA independientes» (publicada el 7 de agosto de 2026, actualizada el 18 de agosto de 2026), Microsoft indica que Entra va a «reconocer Windows Hello for Business (WHfB) y macOS Platform Single Sign-On (PSSO) como factores de autenticación multifactor (MFA) independientes en los escenarios de autenticación admitidos».

La ventana de implementación es específica. La disponibilidad general (General Availability) para los tenants Worldwide y GCC comienza «a principios de octubre de 2026 y se espera que finalice a finales de noviembre de 2026». Microsoft etiqueta la publicación como planForChange con severidad normal y afirma claramente que «no se requieren cambios de configuración».

Esa última frase merece que nos detengamos. Ninguna acción del administrador es requerida, pero la postura de autenticación de cada tenant donde las personas inician sesión con Windows Hello o un Mac cambia por sí sola — incluido cuántas de sus cuentas Entra reporta como MFA-capable, y desde qué dispositivos un usuario aún puede autenticarse cuando algo sale mal.

Qué cambia realmente, y qué ya funcionaba

Windows Hello for Business no se está añadiendo a los niveles de solidez de autenticación (authentication strengths) — ya estaba ahí. La referencia de Microsoft sobre niveles de solidez de autenticación lista «Windows Hello for Business o credencial de plataforma» como algo que satisface los tres niveles integrados: MFA strength, Passwordless MFA strength y Phishing-resistant MFA strength.

Lo que no funcionaba de forma fiable es la ruta de reautenticación. La misma página documenta la limitación actual con las palabras de Microsoft:

Esa es la brecha que cierra MC1450134. Según la publicación de Message Center, estos son los comportamientos tras el despliegue:

Dos de esas filas merecen énfasis. La fila MFA-capable significa que su cifra de cumplimiento se mueve sin que un solo usuario registre nada nuevo — si reporta el «porcentaje de usuarios MFA-capable» a un auditor o a una junta, vuelva a establecer la línea base antes y después del despliegue para poder explicar el salto. La fila de aviso de registro significa que la red de seguridad que antes detectaba a los usuarios de método único desaparece silenciosamente.

Microsoft también documenta un problema conocido en esa misma página de niveles de solidez de autenticación que vale la pena releer bajo esta luz: cuando un recurso requiere tanto un nivel de solidez de autenticación como una frecuencia de inicio de sesión, los usuarios «pueden satisfacer ambos requisitos en dos momentos distintos», y el propio ejemplo de Microsoft es un usuario desbloqueando su dispositivo Windows con Windows Hello for Business para satisfacer una frecuencia de inicio de sesión de una hora, mientras un inicio de sesión con clave de acceso de 24 horas de antigüedad satisface el nivel de solidez.

La trampa: las credenciales vinculadas al dispositivo no viajan

Microsoft señala el riesgo por sí mismo, en la sección «Acción requerida y recomendaciones» de MC1450134: «Como las credenciales WHfB y macOS PSSO están vinculadas al dispositivo (device-bound), es posible que los usuarios no puedan completar los desafíos de MFA desde dispositivos donde esas credenciales no estén disponibles.»

Eso no es una salvedad. Es la propiedad que define ambas credenciales:

• Windows Hello for Business es descrito por Microsoft como «principalmente un método de inicio de sesión vinculado al dispositivo, ligado a la confianza del dispositivo (device trust)», con la credencial «vinculada únicamente a la cuenta laboral o educativa usada para registrar el dispositivo». Su tipo de clave de acceso figura como vinculada al dispositivo (device-bound), no sincronizada (clave de acceso de Microsoft Entra en Windows).
• Platform Credential para macOS «aprovisiona una clave criptográfica vinculada al hardware, respaldada por el enclave seguro», construida sobre la tecnología de Windows Hello for Business (Platform Credential para macOS).

La documentación de Microsoft sobre la campaña de registro ya muestra lo estrecho que es ese vínculo en la práctica. El aviso de clave de acceso se evalúa por combinación de dispositivo y navegador, y la tabla de plataformas publicada muestra que una credencial Windows Hello for Business suprime el aviso solo en Windows, mientras que una credencial Mac Platform SSO lo suprime solo en macOS. El propio ejemplo de Microsoft: «si un usuario tiene una credencial Windows Hello for Business e inicia sesión en Windows con Chrome, el aviso se suprime. Pero si el mismo usuario inicia sesión en un Mac con Chrome, recibe el aviso porque esa credencial no aplica a esa plataforma.» La misma página señala que a los usuarios de Linux nunca se les muestra el aviso, porque las claves de acceso FIDO2 no están disponibles en Linux.

Al juntar las piezas, la exposición se vuelve concreta. Después de octubre, un usuario cuya única credencial MFA registrada sea una credencial Windows Hello for Business cuenta como MFA-capable, deja de recibir avisos para añadir algo portable, y sigue sin poder completar un desafío MFA desde un teléfono personal, un portátil prestado, un Mac o una estación Linux. Portátil roto, dispositivo reimagenado, día de viaje, respuesta a incidentes desde la máquina de otra persona — todo eso se convierte en llamadas al soporte técnico en lugar de un aviso de segundo factor. Ese riesgo golpea con más fuerza a las cuentas que menos se puede permitir bloquear, por eso las cuentas de acceso de emergencia nunca deberían depender de una credencial vinculada a una sola máquina.

Esto se suma a la retirada del MFA por SMS y voz y al cambio de registro de MFA sin contraseña: los respaldos portables en los que muchos tenants todavía se apoyan se están eliminando al mismo tiempo que el sistema deja de pedir a los usuarios que registren un reemplazo.

Detección: encuentre a sus usuarios solo con credenciales vinculadas al dispositivo antes de octubre

Todos los usuarios registrados para un método sin contraseña — FIDO2, Windows Hello for Business, o inicio de sesión sin contraseña por teléfono. Este es el anillo exterior, no la respuesta:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=isPasswordlessCapable eq true

Todos los que tienen una clave de acceso FIDO2 vinculada al dispositivo. Note lo que esto no devuelve: passKeyDeviceBound es el método de clave de acceso vinculada al dispositivo, no Windows Hello for Business ni macOS PSSO, así que por sí solo no encontrará a los usuarios solo-WHfB de los que trata esta sección:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=methodsRegistered/any(x:x eq 'passKeyDeviceBound')

Microsoft documenta methodsRegistered como filtrable con any/eq pero no publica el conjunto completo de valores que puede contener, así que no adivine una cadena de método dentro de $filter. Extraiga methodsRegistered para cada usuario y filtre localmente — que es lo que hace la exportación de abajo — o lea la columna Methods registered en el portal, donde Windows Hello for Business aparece listado por nombre.

Import-Module Microsoft.Graph.Reports

# Establecer la línea base de los métodos registrados de cada usuario antes del despliegue.
# Requiere AuditLog.Read.All (Reports Reader, Security Reader, Security Administrator o Global Reader).
Get-MgReportAuthenticationMethodUserRegistrationDetail |
  Select-Object UserPrincipalName, IsAdmin, IsMfaCapable, IsPasswordlessCapable,
    @{Name = "Methods"; Expression = { $_.MethodsRegistered -join ";" }} |
  Export-Csv .\entra-mfa-baseline-pre-october-2026.csv -NoTypeInformation

Remediación (Remediation): qué hacer antes de que comience el despliegue

1. Haga obligatorio un método portable en el onboarding. Esta es la propia primera recomendación de Microsoft en MC1450134: «Actualizar la guía de onboarding para garantizar que los usuarios registren al menos un método MFA portable.» Una credencial vinculada al dispositivo y nada más es un punto único de fallo por usuario.
2. Elija el método portable de forma deliberada. Microsoft sugiere «una clave de acceso sincronizada o una clave de acceso de Microsoft Authenticator además de WHfB o macOS PSSO». Note el compromiso que documenta Microsoft: «Las claves de acceso sincronizadas no admiten atestación», así que un perfil con Enforce attestation en Yes las excluye en el registro — el propio ejemplo de Microsoft para cuentas de alto privilegio combina la atestación obligatoria con el modo solo vinculado al dispositivo (habilitar claves de acceso (FIDO2)). Decida cuál de esas dos propiedades necesita realmente antes de publicar la guía.
3. Audite los niveles de solidez de autenticación personalizados. MC1450134 pide «revisar las políticas de Authentication Strength personalizadas para confirmar que WHfB y macOS PSSO estén permitidos donde corresponda». Los tres niveles integrados ya incluyen «Windows Hello for Business o credencial de plataforma»; son los personalizados que usted mismo escribió los que pueden comportarse ahora de forma distinta a lo que asumía.
4. Revise las listas de permitidos AAGUID de su perfil de clave de acceso antes de decirle a los usuarios que se registren. Si usa restricciones de clave, Microsoft documenta que el AAGUID del Platform Credential de macOS 7FD635B3-2EF9-4542-8D9D-164F2C771EFC debe estar en la lista permitida para los desafíos WebAuthn. Para las claves de acceso de Windows Hello, los AAGUID documentados son 08987058-cadc-4b81-b6e1-30de50dcbe96 (TPM de hardware), 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 (VBS de hardware) y 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 (TPM de software) — y Microsoft señala que un perfil dirigido a ellos no puede exigir atestación.
5. Corrija primero las cuentas break-glass. Las cuentas de acceso de emergencia deben ser accesibles desde un dispositivo que no sea el que falló. Confirme que tienen una credencial portable y que permanecen excluidas de las políticas que de otro modo las dejarían aisladas.
6. Vuelva a establecer la línea base de la métrica MFA-capable e informe a quien la consuma. La cifra se moverá porque la definición se movió, no porque la cobertura haya mejorado. Compare su CSV previo al despliegue con el posterior en lugar de reportar la nueva cifra como un progreso.
7. Pruebe en modo solo informe (report-only). Los cambios de política de Conditional Access que haga en respuesta a esto deben validarse contra tráfico real antes de aplicarlos, la misma disciplina que detecta las brechas de cobertura de política base que arrastran la mayoría de los tenants.
8. Actualice la documentación de soporte técnico. La última recomendación de MC1450134 es explícita: los usuarios que solo tienen WHfB o macOS PSSO «ya no serán guiados automáticamente para registrar un método MFA adicional», así que la guía tiene que venir de usted. Una revisión más amplia de dónde encaja esto en la higiene del tenant se cubre en nuestra guía de auditoría de Microsoft Entra ID.

Cómo lo detecta EtcSec

Los controles de Conditional Access y acceso privilegiado de EtcSec apuntan a las condiciones que convierten este despliegue de un no-evento en un bloqueo de acceso. CA_NO_MFA_REQUIREMENT señala a los tenants sin ninguna política que realmente exija MFA, donde una cifra MFA-capable cambiante crea una falsa confianza. CA_NO_BREAK_GLASS_EXCLUSION detecta cuentas de acceso de emergencia sin un patrón de exclusión documentado — las cuentas con más probabilidad de quedar aisladas por una credencial solo vinculada al dispositivo. PA_GLOBAL_ADMIN_NOT_MFA identifica cuentas privilegiadas cuya aplicación de MFA no se sostiene. CA_NO_SESSION_CONTROLS encuentra tenants que dependen de una frecuencia de inicio de sesión que WHfB y macOS PSSO ahora satisfarán durante el 2FA, y CA_POLICY_REPORT_ONLY detecta las políticas que probó para este cambio pero nunca llegó a aplicar realmente.