El recambio de la política de riesgo no cubre invitados (y la anterior tampoco)

El 1 de octubre venció el plazo que Microsoft llevaba un año anunciando para las políticas de riesgo heredadas de Entra ID Protection. No hubo caída, ni correo, ni icono rojo en ninguna consola — tampoco lo hubo el 31 de julio de 2025, cuando esas dos pantallas pasaron a solo lectura y dejaste de poder tocarlas sin que se notara. Lo que nos interesa de la fecha no es el drama, es lo que descubres al reconstruir esas políticas en Acceso Condicional: el control que Microsoft recomienda declara por escrito que no está soportado para usuarios externos e invitados. Es la línea que no encontramos en ninguna de las guías de migración que leímos.

El control de destino no hace lo mismo que el de origen. Deja fuera a un tipo de cuenta concreto, y con ese tipo de cuenta la historia completa es más rara de lo que cuenta nadie. Y para saber si está funcionando hay que bajar al registro de inicios de sesión, donde el campo que lo contaría se llama de una forma que engaña. Lo que viene sale, casi entero, de leerse seguidas unas cuantas páginas de la documentación de Microsoft que normalmente se leen por separado.

Qué se retiró, con la cita delante

Microsoft lo escribe en un recuadro de aviso en las dos páginas que tocan el tema, con la misma fecha y con dos redacciones distintas: «The legacy risk policies configured in Microsoft Entra ID Protection are retiring on October 1, 2026» en la página de concepto, y «…will be retired on October 1, 2026» en la del procedimiento. Son dos políticas: la de riesgo de usuario y la de riesgo de inicio de sesión, las que se configuraban desde ID Protection —antes Identity Protection—, no las que vives hoy como condiciones dentro de Acceso Condicional. Esas siguen ahí; de hecho son el destino.

Lo que la documentación no dice es qué le pasa al objeto el día después. Y aquí hay una diferencia que merece la pena mirar despacio, porque casi toda la cobertura del tema se la salta: las guías que circulan afirman que las políticas dejan de aplicarse, mientras que el anuncio original de Microsoft, el de junio de 2025, hablaba de retirar la interfaz de usuario de esas dos políticas. No es lo mismo apagar una protección que quitar la pantalla desde la que se configuraba. No hemos encontrado una frase de Microsoft que diga que dejan de evaluarse, así que no la vamos a poner nosotros.

Si lo que ocurre es lo que asume toda la industria —que dejan de aplicarse—, el modo de fallo es el que ya conocemos de otras retiradas en este mismo producto: una política retirada no devuelve error. No hay inicio de sesión fallido ni alerta ni ticket; hay un usuario marcado como de alto riesgo que entra como cualquier otro día. Es el mecanismo que describimos cuando Entra retiró la pertenencia dinámica por memberOf: lo que se retira no se cae, se queda quieto. Y si lo que ocurre es lo otro —que la pantalla desaparece y la regla sigue viva—, tampoco te conviene, porque entonces tienes una protección en vigor que ya nadie puede leer ni corregir.

Migrar no es mover, y el orden importa

El procedimiento que publica Microsoft tiene dos pasos obligatorios y uno opcional, y el orden de los dos primeros no es decorativo. Uno: crear las políticas equivalentes de riesgo de usuario y de riesgo de inicio de sesión en Acceso Condicional en modo solo informe y, una vez confirmado el comportamiento, pasar el conmutador de «Solo informe» a «Activada». Dos: sólo entonces ir a ID Protection y poner la política antigua en «Deshabilitada». El tercero, que Microsoft marca como opcional, es crear otras políticas de riesgo si hacen falta. Si inviertes los dos primeros —apagar y luego construir— te quedas con la ventana descubierta justo durante los días en que estás tocando identidad.

Hay una señal de que esto no es automático y no es una opinión nuestra: en la misma página, debajo del procedimiento, Microsoft publica un guion detallado para abrir una incidencia de soporte dedicada a esta migración, con el asunto literal «Migrate legacy ID Protection policy» y la ruta exacta de menús hasta el equipo que la atiende. Un fabricante no documenta un camino de soporte para algo que se mueve solo.

Y un detalle que se salta mucha gente al reconstruir: Microsoft avisa de que no se deben combinar la condición de riesgo de inicio de sesión y la de riesgo de usuario en la misma política de Acceso Condicional. Son dos políticas separadas. Si venías de dos políticas en ID Protection y te tienta juntarlas en una sola «política de riesgo» más limpia, el fabricante te está diciendo que no.

El control recomendado no es el que tenías

Aquí está el primer salto que la palabra «migrar» esconde. Para riesgo de usuario alto, lo que Microsoft recomienda hoy no es «exigir cambio de contraseña», sino un control distinto: «Require risk remediation», corrección del riesgo. Y al seleccionarlo se aplican automáticamente dos ajustes más: «Require authentication strength» queda seleccionado como control de concesión, y «Sign-in frequency – Every time» se aplica como control de sesión y la documentación lo marca como obligatorio. No son opcionales ni los has elegido tú: vienen con el control.

Que sea mejor no significa que sea igual. La fuerza de autenticación es un control con criterio propio sobre qué métodos valen —hablamos de él cuando contamos por qué un MFA de terceros puede no contar como MFA para Entra—, y la reautenticación «cada vez» es un cambio que el usuario nota. Si llegas a esto el lunes migrando a toda prisa y el martes recibes llamadas de gente a la que se le pide identificarse continuamente, no es un fallo: es el control que te recomendaron, haciendo lo que trae escrito.

Hay además reglas de precedencia que importan precisamente durante la ventana de convivencia: «Require risk remediation» tiene prioridad sobre «Require password change», y «Block» sobre todas; y Microsoft pide asignar cada usuario a una sola de esas políticas a la vez para evitar conflictos. Durante la migración vas a tener, a propósito, la vieja y la nueva vivas al mismo tiempo. Es lo correcto, pero conviene saber cuál manda mientras dura.

La parte que no está en ninguna lista: los invitados

La frase está en la documentación del control, en la sección de consideraciones especiales, y es tan corta que se pasa por alto: «Require risk remediation is not supported for external and guest users because Microsoft Entra ID doesn't support session revocation for those users». No está soportado para usuarios externos e invitados, porque Entra no puede revocar sesiones de esas cuentas.

El motivo es coherente y por eso no va a cambiar: la credencial y la sesión de un invitado viven en su tenant de origen, no en el tuyo. Tú le das acceso a un recurso; no eres el dueño de su identidad. Lo que sí es tuyo es la consecuencia: en una pyme que trabaja con proveedores, consultores, un auditor externo o un cliente metido en un Teams compartido, las cuentas invitadas son justamente aquellas cuya higiene de credenciales no controlas. No ves su MFA, no gestionas su contraseña, no sabes si su portátil tiene EDR.

Conviene ser preciso, porque aquí es fácil pasarse de frenada en la dirección contraria y vender una regresión que no existe. La política antigua tampoco corregía a los invitados. Microsoft lo documenta en una página aparte, la de ID Protection para usuarios B2B: «If a guest user triggers the ID Protection user risk policy to force password reset, they will be blocked», porque no se pueden restablecer contraseñas en el directorio del recurso; «Guest users do not appear in the risky users report», porque el riesgo se evalúa en su directorio de origen; y un administrador del tenant que invita «cannot dismiss or remediate a risky B2B collaboration user». Traducido: con la política heredada, al proveedor en riesgo lo bloqueabas sin tener forma de desbloquearlo tú, y sin verlo en ningún informe.

Lo que nunca tuviste, y ahora por fin está escrito donde toca, es la corrección automática del riesgo de usuario para esas cuentas. La capacidad es la misma de siempre; lo que ha mejorado es la franqueza del fabricante. Antes bloqueaba a tu proveedor y lo contaba en una página que había que ir a buscar a propósito; ahora el control nuevo lo declara en sus consideraciones especiales, a la vista de quien escribe la política.

¿Y entonces qué se hace con los invitados? Aquí la respuesta de Microsoft es la contraria de la que esperábamos cuando empezamos a leer, y es la parte que más nos ha hecho corregir el borrador de este post. Su guía Zero Trust para acceso de invitados dice, literalmente: «we recommend that you exclude guests from risk-based MFA policies and require these users to always use MFA». Y la guía de Acceso Condicional para usuarios B2B llega a explicar el cómo: crear un grupo con todos los externos de tu organización y añadirlo como exclusión de tus políticas basadas en riesgo, tanto la de usuario como la de inicio de sesión. Es decir: para los invitados no se condiciona el MFA al riesgo, se exige siempre.

Con dos trampas que conviene saber antes de tocar nada, porque las dos acaban en el mismo sitio —el proveedor llamándote porque no puede entrar—. La primera: la política de riesgo de inicio de sesión sí se evalúa para un invitado, pero «if a user hasn't previously registered for Microsoft Entra multifactor authentication in the resource tenant, the user is blocked», y es deliberado, para que un atacante con la contraseña robada no registre su propio segundo factor en tu casa. La segunda es más fina y se la salta todo el mundo: «you can only apply authentication strength policies to external users who authenticate with Microsoft Entra ID»; para los invitados de contraseña de un solo uso por correo, SAML/WS-Fed o federación con Google hay que usar el control de MFA a secas. El invitado de código por correo es el más común en una pyme, y es justo el que se queda fuera de la fuerza de autenticación.

El resto del trabajo con invitados no es una casilla. Es alcance —qué puede tocar y desde cuándo—, caducidad —revisiones de acceso con fecha, no para siempre— y la decisión escrita de qué se le exige a quien entra desde fuera. Lo decimos sabiendo que es la parte que más se aplaza: en los tenants que llevamos, el padrón de invitados es casi siempre el inventario más viejo de la casa.

El híbrido que no puede corregirse solo

El siguiente aviso no está en esa página, está en la otra: la del procedimiento, justo donde haces la migración. Pone dos requisitos previos: los usuarios deben haber registrado MFA antes de encontrarse en una situación que exija corrección, y para los usuarios híbridos sincronizados desde un directorio local hay que tener habilitada la escritura diferida de contraseñas (password writeback). Del primero, Microsoft escribe también el desenlace: «Users not registered are blocked and require administrator intervention». Y una línea más, que vale su peso: un cambio de contraseña hecho fuera del flujo de corrección —el usuario que entra en su perfil y la cambia por su cuenta— no cumple el requisito de cambio seguro de contraseña.

Júntalo con el parque típico de una pyme con años encima: directorio local sincronizado a Entra, gente que registró el MFA hace tres años y gente que lo fue esquivando, y una escritura diferida que alguien configuró en su día y nadie ha vuelto a mirar. Un usuario sale marcado como de alto riesgo un lunes por la mañana. Si no tenía MFA registrado, la documentación dice sin rodeos cómo acaba: bloqueado, y hace falta un administrador. Lo que le pasa al usuario híbrido al que le falta la escritura diferida no lo hemos encontrado escrito, así que lo decimos como lo que es —una deducción nuestra, y de las que conviene probar en tu propio tenant antes de darlas por buenas—: sin writeback no hay cambio seguro de contraseña contra el directorio local, y sin cambio seguro no hay autocorrección. Pruébalo tú; nosotros no podemos afirmarlo.

Cómo se prueba que está migrado (mirar la pantalla no vale)

Una política encendida en una pantalla no prueba que esté actuando. La prueba vive en el registro de inicios de sesión, y tiene una trampa documentada que conviene conocer antes de dar el trabajo por cerrado. Tres lecturas:

• Que tu política aparezca no significa que se aplicara. La sección del registro se llama appliedConditionalAccessPolicies, y la propia documentación de Microsoft lo advierte con todas las letras: «the section is called applied Conditional Access policies; however, policies that were not applied also appear in this section». Hay una entrada por política. Lo que te dice algo es el resultado de la entrada de la tuya, no su presencia. Si sigue en modo solo informe, está documentando lo que habría hecho; no lo está haciendo.
• Comprueba que hay riesgo que leer. El campo riskLevelAggregated devuelve el valor hidden cuando el usuario o el inicio de sesión no estaba habilitado para ID Protection. Un hidden sobre alguien que crees cubierto significa que tu política de riesgo no tiene de dónde leer. Aquí es donde asoma la licencia: las políticas basadas en riesgo requieren Microsoft Entra ID P2 (o Entra Suite para el acceso completo a ID Protection). Sin eso, la política existe y no evalúa nada.
• Hazlo con dos cuentas, no con la tuya. Un miembro y un invitado. Es la única forma de ver con tus ojos el agujero de la sección anterior en lugar de fiarte de que alguien te lo cuente —nosotros incluidos—. Y revisa también las exclusiones que la propia documentación recomienda y que hay que rehacer en la política nueva: cuentas de acceso de emergencia (break-glass) y cuentas de servicio. Con un matiz que sorprende a mucha gente y está escrito: las llamadas hechas por entidades de servicio no las bloquea una política de Acceso Condicional dirigida a usuarios; para eso están las políticas de identidades de carga de trabajo.

Las excepciones que tu motor de políticas ya tiene

Leyendo la misma página aparece algo que merece su propio apartado. Durante la corrección del riesgo, Entra usa un flujo dedicado y seguro para acciones como la revocación de sesión, y la documentación dice que ese flujo «se permite continuar sin verse afectado por otras políticas de Acceso Condicional». Publica incluso los identificadores: AppId 93625bc8-bfe2-437a-97e0-3d0060024faa en la nube pública y ResourceId 00000003-0000-0000-c000-000000000000.

No es un agujero y no lo vamos a vender como tal. Es la salida de un abrazo mortal: si la política bloquea al usuario en riesgo, el usuario no puede corregir su riesgo, y entonces la pieza que te protege te deja la cuenta inservible hasta que alguien la rescate a mano. La excepción existe porque sin ella el sistema se muerde la cola.

La lectura honesta para quien está montando Zero Trust es ésta: «todo pasa por la política» es falso en cualquier motor de políticas real, incluido el tuyo. Lo que distingue a una implantación madura no es no tener excepciones; es tener la lista escrita, con su identificador, su motivo y quién la firmó. La de arriba viene con las tres cosas de fábrica, y por eso es un buen ejemplo. Las que montas tú un viernes para desatascar a alguien, normalmente no vienen con ninguna —y de eso ya hablamos cuando contamos las políticas de Acceso Condicional que aparecen en tu tenant sin que las escribas—.

Lo que no estamos diciendo

No decimos que la retirada sea mala. Es mejor, y la propia página enumera por qué: gestionar las políticas de acceso en un solo sitio, modo solo informe, API de Graph, poder exigir reautenticación, combinar el riesgo con otras condiciones como la ubicación, varias políticas de riesgo apuntando a grupos y niveles distintos, mejor diagnóstico en el registro de inicios de sesión sobre qué política de riesgo se aplicó, y soporte del sistema de autenticación de respaldo. Son ventajas reales y las queremos.

Tampoco decimos que Microsoft lo haya escondido. El aviso está en un recuadro, con la fecha, en las dos páginas que tocan el tema; lo hemos citado literal arriba. Lo que nos chirría es el verbo. «Migrar» sugiere mover algo de un sitio a otro con sus propiedades intactas, y aquí lo que hay que hacer es reconstruirlo, comprobarlo y aceptar que el resultado no es idéntico. Con una parte —los invitados— que no tiene equivalente y hay que cubrir por otro camino.

Y la pega contra nuestro propio interés, que es la que menos gusta: si nunca tuviste activadas aquellas políticas, el 1 de octubre no te pasó absolutamente nada. Tampoco te pasó nada en julio de 2025, cuando dejaste de poder crearlas. Eso no es una buena noticia: significa que llevas años sin respuesta automática al riesgo de identidad, y el calendario de Microsoft no tiene nada que ver con ello. Si además no tienes P2, este artículo entero no te aplica; el primer paso entonces no es una política, es una decisión de licencia, y hay cosas más baratas y más rentables que hacer antes —empezando por MFA resistente a phishing para quien administra—. Conflicto de interés por delante: vendemos exactamente este trabajo, así que lee lo de arriba con esa sospecha puesta.

Fuentes (verificadas el 3 de octubre de 2026): la fecha de retirada con su redacción, los controles de las políticas de riesgo de usuario y de inicio de sesión, el comportamiento de «Require risk remediation» según el método de autenticación, las reglas de precedencia, la no compatibilidad con usuarios externos e invitados y el flujo exento con su AppId y ResourceId salen de Microsoft Entra ID Protection risk-based access policies (Microsoft Learn). Los pasos de migración, el guion de la incidencia de soporte, el aviso de no combinar condiciones de riesgo en la misma política, las recomendaciones de nivel de riesgo, los dos ajustes que se aplican solos, el requisito de registro previo de MFA y de escritura diferida de contraseñas, la nota sobre el cambio de contraseña fuera del flujo, las exclusiones recomendadas, la frase sobre las entidades de servicio y el requisito de licencia P2 o Entra Suite, de Risk policies (Microsoft Learn). Las tres limitaciones con invitados —bloqueo al forzar cambio de contraseña, ausencia en el informe de usuarios de riesgo e imposibilidad de descartar o corregir su riesgo desde el tenant del recurso— de Microsoft Entra ID Protection for B2B users. El bloqueo del invitado sin MFA registrado en el tenant del recurso, el límite de la fuerza de autenticación a externos que autentican con Entra ID y el procedimiento de excluir a los externos de las políticas de riesgo, de Authentication and Conditional Access for B2B users. La recomendación literal de excluir a los invitados del MFA basado en riesgo y exigirles MFA siempre, de la guía Zero Trust de acceso de invitados y usuarios externos. La advertencia sobre appliedConditionalAccessPolicies y el valor hidden de riskLevelAggregated, de Learn about the monitoring and health activity log schemas. Con una salvedad declarada: el paso a solo lectura el 31 de julio de 2025 y la formulación de que lo que se retira es la interfaz de usuario proceden del anuncio What's new in Microsoft Entra – June 2025, cuyo cuerpo no hemos conseguido abrir; los tomamos de las coberturas de ese anuncio y los damos como lo que son, no como una cita que hayamos leído en el original. Lo nuestro, y no de esas fuentes: que «migrar» describe mal un trabajo de reconstrucción, la distinción entre retirar la interfaz y dejar de aplicar la política, lo que significa el hueco de invitados para una empresa con proveedores, la deducción sobre el usuario híbrido sin escritura diferida —declarada como deducción—, el procedimiento de prueba con dos cuentas y la lectura Zero Trust de la excepción documentada.