Acceso Condicional Información de Seguridad Windows Hello macOS Platform SSO: Cambio de Alcance (13 de julio de 2026)

Acceso Condicional Información de Seguridad Windows Hello macOS Platform SSO: qué cambió

Acceso condicional información de seguridad windows hello macos platform sso — así es como los administradores de Microsoft Entra deben conocer ahora este cambio. Desde el 13 de julio de 2026, las políticas de Acceso condicional que apuntan a la acción de usuario Register security information también rigen el registro de credenciales de Windows Hello for Business (WHfB) y macOS Platform Single Sign-on (SSO), se haya pretendido o no ese comportamiento al definir el alcance inicial de la política. Si su tenant había limitado esa acción de usuario de forma estrecha —por ejemplo, cubriendo solo la experiencia combinada de registro MFA/SSPR— el registro de WHfB y macOS Platform SSO ahora queda sujeto, sin que lo haya anticipado, a los mismos Grant controls. Si su tenant excluía deliberadamente esos flujos para mantener un aprovisionamiento de dispositivos sin fricción, esa exclusión tampoco se mantiene: esos flujos ahora están dentro del alcance por defecto.

Antes de este cambio, el registro de Windows Hello for Business y macOS Platform SSO no evaluaba en absoluto las políticas de Acceso condicional con alcance en Register security information —incluso cuando existía una política que apuntaba a esa acción de usuario, simplemente no se consultaba durante el registro de WHfB/Platform SSO. Las indicaciones oficiales de Microsoft son explícitas sobre qué cambió y qué no:

Microsoft también confirmó la ventana de implementación y el alcance del impacto en la publicación de Message Center MC1326253, «Conditional Access policies now apply to Windows Hello for Business and macOS Platform SSO registration»: la implementación comenzó el 6 de julio de 2026 y se completó el 13 de julio de 2026, y los tenants sin ninguna política de Acceso condicional dirigida a Register security information no verán ningún cambio —la aplicación por defecto del MFA para el registro de credenciales sin contraseña permanece intacta.

Cómo funciona la aplicación del control

El mecanismo en sí no es nuevo —es la misma acción de usuario Register security information que ha regido durante años la experiencia combinada de registro MFA/SSPR. Lo nuevo es que el aprovisionamiento de Windows Hello for Business y el registro de macOS Platform SSO ahora se enrutan a través de esa misma evaluación de Acceso condicional. En concreto, tras la aplicación, un usuario que registre credenciales de WHfB o macOS Platform SSO debe satisfacer los Grant controls que exija la política correspondiente —authentication strength, una ubicación de confianza, un método MFA específico o el cumplimiento del dispositivo— antes de que se complete el registro.

Dos detalles de las indicaciones de Microsoft importan para planificar su respuesta:

• Los métodos de autenticación externos son actualmente incompatibles con authentication strength como grant control para esta acción de usuario —una brecha de compatibilidad que hace eco del retiro de los Custom Controls para métodos de autenticación externos que ya está en marcha en Entra. Si su política combina Register security information con un requisito de authentication strength y su tenant depende de métodos de autenticación externos, Microsoft recomienda usar en su lugar el grant control Require multifactor authentication.
• El Temporary Access Pass (TAP) satisface el requisito de MFA de Acceso condicional para el registro, que es la forma en que Microsoft espera que los administradores inicien a los nuevos usuarios en WHfB/macOS Platform SSO sin un problema de «el huevo o la gallina» (un usuario no puede satisfacer un grant control de MFA/authentication strength con una credencial que todavía no ha registrado). El TAP no funciona para usuarios invitados (guest).

Quién se ve afectado

Se trata de un cambio de alcance, no de una nueva política que haya que crear —precisamente por eso es fácil pasarlo por alto. Vale la pena revisar específicamente dos escenarios de fallo:

1. Política estrecha, nueva fricción. Una política con alcance en Register security information y Grant: require authentication strength (creada para asegurar el registro de MFA/SSPR) ahora también se aplica a WHfB y macOS Platform SSO. Un nuevo empleado que registra un dispositivo Windows administrado desde una red de confianza puede quedar bloqueado a mitad del proceso porque todavía no puede satisfacer el authentication strength que exige la política —precisamente la brecha que el Temporary Access Pass existe para cerrar.
2. Exclusión deliberada, revertida en silencio. Si su equipo mantenía deliberadamente el aprovisionamiento de WHfB/macOS Platform SSO fuera del alcance de Acceso condicional —por ejemplo, para no ralentizar un despliegue de dispositivos zero-touch— esa exclusión desapareció el 13 de julio de 2026. El flujo de registro ahora se aplica por defecto; volver a excluirlo requiere un cambio explícito.

Lecturas relacionadas: nuestra cobertura del cambio en el registro de MFA sin contraseña y la guía más amplia sobre las brechas de Acceso condicional tratan ambas decisiones de alcance adyacentes que vale la pena revisar junto con este despliegue.

Detección — Audite la exposición de su tenant

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=(createdDateTime ge 2026-07-06T00:00:00Z and createdDateTime le 2026-07-13T23:59:59Z) and conditionalAccessStatus eq 'failure'

Get-MgAuditLogSignIn -Filter "createdDateTime gt 2026-07-06T00:00:00Z" | Select-Object `
  @{Name="User";Expression={$_.UserDisplayName}}, `
  @{Name="ClientApp";Expression={$_.ClientAppUsed}}, `
  @{Name="CA Result";Expression={$_.ConditionalAccessStatus}}, `
  @{Name="FailureReason";Expression={$_.FailureReason}}, `
  @{Name="Device";Expression={$_.DeviceDetail.DeviceDisplayName}}

Remediación — Pasos a seguir ahora

1. Enumere cada política con alcance en Register security information y anote sus Grant controls. Esta es toda la superficie de exposición de este cambio —ningún otro elemento de su conjunto de políticas de Acceso condicional se ve afectado.
2. Vuelva a ejecutar cada política en modo report-only y revise los resultados de policy impact antes de asumir que el comportamiento no cambió el 13 de julio.
3. Excluya las cuentas de acceso de emergencia (break-glass) y las cuentas de servicio/service principals de cualquier política dirigida a esta acción de usuario, según la recomendación permanente de Microsoft —vea nuestra cobertura de cuentas break-glass para entender por qué las cuentas de emergencia no excluidas son un hallazgo recurrente.
4. Emita un Temporary Access Pass para los nuevos empleados y el reaprovisionamiento de dispositivos, de modo que el registro de WHfB/macOS Platform SSO no choque con el problema de authentication strength del huevo y la gallina. El TAP satisface el requisito de MFA de Acceso condicional para el registro —pero recuerde que no funciona para usuarios invitados.
5. No combine métodos de autenticación externos con un grant control Require authentication strength en esta acción de usuario; use en su lugar Require multifactor authentication, según la advertencia explícita de compatibilidad de Microsoft.
6. Actualice la documentación de soporte sobre los nuevos avisos de autenticación que los usuarios pueden ver a mitad del proceso —esta fue la propia acción recomendada por Microsoft en MC1326253, y es la forma más económica de reducir los tickets de soporte de nuevos empleados confundidos. Nuestra guía de auditoría de Entra ID explica dónde encajan las revisiones de alcance de Acceso condicional dentro de una revisión más amplia del tenant.

Cómo lo detecta EtcSec

Las verificaciones de Conditional Access de EtcSec señalan exactamente las malas configuraciones que convierten este despliegue de un no-evento en una interrupción: CA_POLICY_REPORT_ONLY detecta políticas dejadas en modo report-only que los administradores creen que están aplicándose (por lo que el cambio del 13 de julio se probó pero nunca se activó realmente), CA_NO_BREAK_GLASS_EXCLUSION detecta cuentas de acceso de emergencia que no están excluidas de una política de Register-security-information —ahora un riesgo de bloqueo en el registro, no solo en el inicio de sesión— y CA_EXCESSIVE_EXCLUSIONS señala políticas cuyas listas de exclusión han crecido tanto que el ajuste de alcance de este despliegue resulta, en la práctica, irrelevante.