Retiro Políticas de Riesgo Entra ID Octubre 2026 Migración Acceso Condicional: Sin Ruta Automática

Retiro Políticas de Riesgo Entra ID Octubre 2026 Migración Acceso Condicional: Sin Ruta Automática

El Retiro Políticas de Riesgo Entra ID Octubre 2026 Migración Acceso Condicional es un corte definitivo para los controles originales de respuesta al riesgo en Entra ID Protection. Según Microsoft Learn, las políticas heredadas de riesgo de usuario y riesgo de inicio de sesión — las configuradas directamente en el propio panel de Identity Protection, no a través del Acceso condicional — «se retirarán el 1 de octubre de 2026». El rastreador de obsolescencias de Microsoft 365 de admindroid indica la misma fecha con el mismo planteamiento: «La interfaz de política de riesgo de usuario o de riesgo de inicio de sesión en Entra ID Protection (anteriormente Identity Protection) se retirará el 1 de octubre de 2026».

Ninguna de las dos fuentes describe ninguna conversión automática. Las propias directrices de migración de Microsoft son enteramente manuales: los administradores deben crear ellos mismos políticas equivalentes basadas en el riesgo en Acceso condicional, validarlas, activarlas, y solo entonces volver a deshabilitar las antiguas. Nada en la documentación traslada por sí solo la configuración de políticas de riesgo existente de un tenant hacia Acceso condicional.

Por qué "sin migración automática" es lo que realmente duele

La respuesta basada en riesgo es uno de los pocos controles de Entra ID Protection que actúa sobre señales de compromiso de identidad sin intervención humana: es lo que convierte una detección de "usuario de riesgo" o "inicio de sesión de riesgo" en un desafío multifactor real, un cambio de contraseña forzado o un bloqueo. Un tenant que todavía depende de la interfaz de política heredada y no hace nada antes del retiro no se migra gratis: pierde esa respuesta automatizada en el momento en que la política heredada deja de funcionar, a menos que ya exista un equivalente activo en Acceso condicional.

Este es un problema más estrecho y más tajante que "existen detecciones de riesgo pero nadie actúa sobre ellas" (la carencia más general de Identity Protection que EtcSec ya cubrió por separado). Aquí, un tenant puede tener hoy una política de riesgo funcionando y aplicada, y aun así terminar con cero aplicación basada en riesgo el 2 de octubre de 2026 — no porque nadie haya cambiado nada, sino porque nadie lo hizo.

Detección: ¿sigue dependiendo de la política heredada?

Hay que comprobar dos cosas, y la propia guía de migración de Microsoft Learn indica exactamente dónde mirar:

1. Políticas de riesgo heredadas. En el centro de administración de Microsoft Entra, vaya a ID Protection → Panel, y abra los mosaicos de política de Riesgo de usuario y Riesgo de inicio de sesión. Si alguno muestra Aplicar política: Activado, ese tenant todavía depende del tipo de política que se está retirando.
2. Cobertura basada en riesgo en Acceso condicional. Vaya a Entra ID → Acceso condicional → Políticas y compruebe si alguna política usa Condiciones → Riesgo de usuario o Condiciones → Riesgo de inicio de sesión. Si no existe ninguna — o las únicas presentes siguen en Solo informe — todavía no hay un reemplazo funcional, sin importar lo que muestre el panel heredado.

Un tenant puede fallar en cualquiera de las dos comprobaciones de forma independiente: algunos ya han creado políticas de riesgo en Acceso condicional y simplemente olvidaron retirar las antiguas (redundante, no urgente); otros no tienen ninguna de las dos, que es la combinación que lleva a cero aplicación basada en riesgo en la fecha de retiro.

Remediación: migrar antes del 1 de octubre de 2026

Microsoft Learn documenta una ruta de migración específica de tres pasos:

1. Construya primero los equivalentes en Acceso condicional, en modo solo informe. Cree una política basada en riesgo de usuario y una política basada en riesgo de inicio de sesión en Acceso condicional (manualmente, o a partir de una plantilla de Acceso condicional), dirigidas a Todos los usuarios con las cuentas de acceso de emergencia (break-glass) excluidas. Si parte de una plantilla, añada usted mismo esa exclusión una vez creada la política: las plantillas de Microsoft solo excluyen la cuenta que crea la política, no las cuentas break-glass del tenant. Deje primero Habilitar política en Solo informe.
2. Valide y luego active las políticas. Use los datos de solo informe de Acceso condicional para confirmar que las nuevas políticas se disparan igual que lo hacían las antiguas, antes de cambiar Habilitar política de Solo informe a Activado.
3. Deshabilite las políticas heredadas. De vuelta en ID Protection → Panel, abra cada política heredada de Riesgo de usuario y Riesgo de inicio de sesión, y ponga Aplicar política en Deshabilitado — las directrices de Microsoft se detienen antes de eliminarlas, solo piden deshabilitarlas.

Para los tenants que necesiten ayuda directa, Microsoft Learn documenta una ruta específica de solicitud de soporte: presente una Nueva solicitud de soporte, describa el problema como "Migrate legacy ID Protection policy" [Migrar política heredada de ID Protection], y seleccione Inicio de sesión de Microsoft Entra y autenticación multifactor → Configuración de ajustes de política nuevos o existentes.

Vale la pena revisar dos temas relacionados junto con esta migración: las políticas de riesgo — de inicio de sesión y de usuario, ya provengan de ID Protection o de Acceso condicional — están entre las funciones que Microsoft reserva a Entra ID P2 o a Microsoft Entra Suite y no están disponibles en Free ni en P1, y cualquier política nueva debería seguir la misma disciplina de validación en modo solo informe que se aplica a cualquier otro despliegue de Acceso condicional — una política dejada indefinidamente en modo solo informe ofrece la misma ausencia total de aplicación que no tener ninguna política. También vale la pena revisar la cobertura básica de Acceso condicional ya que está en ello, puesto que un tenant que migra sus políticas de riesgo es un tenant que ya está auditando su postura de Acceso condicional.

Este retiro se suma a una serie de plazos de Entra fechados en 2026 — la aplicación de SSPR limitada a métodos registrados en noviembre es otro, con un corte definitivo y sin repliegue silencioso — y la lección operativa es siempre la misma: un aviso de "se retirará" de Microsoft es una tarea pendiente, no una migración en segundo plano.

Cómo lo detecta EtcSec

La auditoría de Azure de EtcSec mide lo que sigue existiendo tras el retiro: si una política de Acceso condicional habilitada realmente incluye una condición de riesgo. CA_NO_RISK_BASED_USER y RISK_NO_USER_RISK_POLICY se disparan cuando ninguna política de Acceso condicional habilitada establece niveles de riesgo de usuario; CA_NO_RISK_BASED_SIGNIN y RISK_NO_SIGNIN_RISK_POLICY se disparan cuando ninguna establece niveles de riesgo de inicio de sesión. Los cuatro controles leen el conjunto de políticas de Acceso condicional del tenant — ninguno lee el panel heredado de políticas de ID Protection.

Dos consecuencias merecen indicarse con precisión. Primero, un tenant cuya respuesta al riesgo vive solo en la interfaz heredada de ID Protection falla estos controles hoy mismo, no el 2 de octubre de 2026 — el hallazgo ya está presente en la auditoría, y es exactamente la tarea de migración que crea este plazo. Segundo, los controles solo cuentan una política en estado enabled: una política de Acceso condicional basada en riesgo todavía estacionada en solo informe no los supera, lo cual es la misma realidad de aplicación descrita anteriormente.