Custom controls: el MFA de terceros que Entra no cuenta como MFA

La página de Microsoft Learn sobre los custom controls de Acceso Condicional tiene un recuadro con ocho cosas para las que ese control no sirve. La tercera dice, literalmente: «Satisfying multifactor authentication claim requirements». El usuario pasa el segundo factor de tu proveedor y entra, pero el token con el que sigue navegando no lleva la marca de haber hecho MFA.

Conviene acotar el titular antes de seguir, porque esto no aplica a todo el MFA de terceros. Un proveedor federado que emite el claim correcto sí cuenta. El External MFA que Microsoft ofrece hoy como sustituto también cuenta. Lo que no cuenta es el mecanismo concreto de los custom controls, que es el que se montó en su día en muchos tenants y el que sigue funcionando cada mañana en unos cuantos.

Montamos y mantenemos Acceso Condicional en tenants de clientes, así que esta página nos toca de cerca. La traemos ahora por una razón de calendario: la misma documentación dice que a partir de septiembre de 2026 —este mes— ya no se pueden crear custom controls nuevos ni editar los que hay.

Primero, mira si tienes uno

Casi nadie sabe de memoria si su tenant lleva un custom control, porque quien lo tiene suele haberlo heredado con el tenant. Se ve en el portal, en la sección «Custom controls» de Acceso Condicional, pero eso solo te dice que existe; lo que importa es qué políticas lo referencian. Eso se pregunta a Microsoft Graph.

El recurso conditionalAccessGrantControls de Graph v1.0 tiene una propiedad llamada customAuthenticationFactors, descrita como «List of custom controls IDs required by the policy». Si en alguna política viene con contenido, ahí está tu respuesta. Con el SDK de PowerShell y permiso Policy.Read.All:

Connect-MgGraph -Scopes Policy.Read.All

Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object { $_.GrantControls.CustomAuthenticationFactors } |
  Select-Object DisplayName, State,
    @{n='CustomControls'; e={ $_.GrantControls.CustomAuthenticationFactors -join ', ' }}

Si no devuelve nada, este post no va contigo y te has ahorrado el resto. Si devuelve algo, apunta el nombre de esas políticas: son las que hay que revisar, y lo interesante no es que caduquen, sino qué han estado cubriendo hasta hoy.

Qué es un custom control, y por qué eso lo explica todo

La documentación lo describe así: el navegador del usuario se redirige al servicio externo, allí hace lo que tenga que hacer, y vuelve; Entra verifica la respuesta y, si es válida, el usuario continúa el flujo de Acceso Condicional. Una redirección y una vuelta, y ahí está la explicación de las ocho limitaciones: Entra no recibe una aserción de autenticación que pueda integrar en el token, sino un «este usuario ha vuelto y el proveedor dice que sí», que le sirve para tomar esa decisión de acceso en esa política concreta y para nada más.

La primera frase de la página, por cierto, dice algo que a mucha gente le va a sorprender: «Custom controls are a preview capability of Microsoft Entra ID». Nunca salió de preview, y ha sostenido el segundo factor de organizaciones enteras durante años.

Las ocho, y qué significa cada una en tu tenant

Estos son los ocho usos excluidos, en el orden en que los enumera Microsoft, con la traducción a lo que pasa en un tenant real:

Léela otra vez pensando en un cuadro de cumplimiento. No son casos raros: son la elevación de privilegios, el alta de dispositivos, la recuperación de cuenta, la respuesta automática al riesgo, la caducidad de la sesión y la relación con terceros. El control existe, se ve en el portal, redirige y funciona todos los días, y no cubre ninguna de esas seis cosas.

Es el mismo patrón del que ya hemos hablado aquí: una casilla marcada que no equivale a un control ejercido. Lo vimos con un informe de impacto cero que solo medía lo que sabía mirar y con el token de una app conectada que no vuelve a pedir MFA.

La fecha: el mes, no el día

La página de Learn, revisada el 19 de mayo de 2026, lo dice así: «Adding new custom controls and editing existing custom controls will not be allowed starting September 2026. Full retirement is scheduled for early 2027». El aviso del centro de mensajes de Microsoft 365 —MC1422061, publicado el 9 de julio de 2026, visible solo desde el propio inquilino— coincide en septiembre de 2026 para el congelado, pero sitúa la retirada total en mayo de 2027 con una fecha de actuación del 30 de abril de 2027.

Dos fuentes oficiales, dos redacciones distintas: «principios de 2027» y «mayo de 2027» no son lo mismo, y nosotros planificamos contra la más temprana de las dos, porque el coste de equivocarse en esa dirección es tener el trabajo hecho antes de tiempo. Hay además un detalle que casi nadie mira: ninguna de las dos da un día de septiembre. Si cuentas con hacer un último ajuste antes de que cierre la ventana, no sabes qué mañana te vas a encontrar el botón en gris.

«Editar» significa borrar y volver a crear

Aquí es donde el congelado de septiembre deja de ser una molestia burocrática. La sección «Editing custom controls» de la documentación tiene una sola frase: «To edit a custom control, delete the current control and create a new one with the updated information». Y para borrarlo, dice unas líneas antes, «ensure that it isn't being used in any Conditional Access policy».

Encadena las tres reglas: desde septiembre no puedes crear, para editar hay que borrar, y para borrar hay que desvincularlo de toda política. El control que tienes montado es de un solo uso. Si tu proveedor cambia el bloque JSON —renovación de certificado, cambio de endpoint, una migración suya— no puedes aplicarlo, y si lo borras para intentarlo, no vuelve. Eso no es un plazo de migración: es una pieza que ya no se puede reparar.

Lo que la documentación NO dice

Nos falta un dato y preferimos decirlo que rellenarlo: en ninguna de las dos páginas oficiales que hemos leído se explica qué le pasa a una política de Acceso Condicional que referencia un custom control el día que la función se retire del todo. ¿Deja de aplicarse la concesión y el usuario entra sin más? ¿Bloquea? ¿La política queda inválida? No lo dice. Circula por ahí la afirmación de que se abre —de que el usuario pasa sin desafío y sin aviso—, pero no la hemos podido anclar a una fuente de Microsoft, así que no la damos por buena. Y un control de seguridad cuyo modo de fallo no está documentado obliga a mover ficha antes de la fecha, no después.

El reemplazo trae su propia letra pequeña

El sustituto se llama External MFA (antes «external authentication methods») y funciona de otra manera: se configura con un Client ID, un Application ID de una app multiinquilino del proveedor y una Discovery URL, que es el endpoint de descubrimiento OIDC. Se gestiona desde la directiva de métodos de autenticación, dice la documentación, «just like built-in methods». Eso arregla el problema de fondo: la propia página afirma que estos usuarios «can use an external MFA to satisfy MFA», y describe cómo se les redirige al proveedor según los requisitos de frescura configurados en las políticas de frecuencia de inicio de sesión. Las dos cosas que el mecanismo viejo no podía hacer.

Dicho lo cual, no es gratis. Lo que nos apuntamos antes de tocar un tenant:

Para la transición, la parte más útil de todo el material es la guía de convivencia: Microsoft recomienda dos políticas de Acceso Condicional —una que exige el custom control y otra que exige MFA— con un grupo de prueba en cada una, pero no en las dos. Si un usuario cae en ambas tiene que satisfacer las dos, y acaba redirigido al proveedor externo dos veces seguidas. Después va lo que de verdad justifica el proyecto y casi nadie apunta, porque cree que ya lo tenía: volver a poner MFA en la elevación de PIM, en la inscripción de dispositivos y en las políticas de riesgo.

Lo que se lleva uno de aquí

Que un control esté activo no dice nada sobre su alcance. Este redirige usuarios a un proveedor de MFA, se cobra su licencia y sale en verde en el informe, mientras la página del propio fabricante enumera, en letra pequeña, ocho usos para los que no sirve. Nadie mintió; nadie leyó el recuadro. Por eso insistimos en que el Zero Trust se audita por efecto y no por configuración: la pregunta no es si la política está puesta, sino qué le pasa exactamente al que intenta pasar.

El plano de identidad, como escribimos en su día, no es una aplicación más del catálogo. Si este mes vas a revisar algo de tu tenant, mira también lo que cambió el 1 de septiembre con las passkeys: son dos movimientos de la misma pieza.

Y si la respuesta a «¿tenemos un custom control?» en tu casa es «habría que mirarlo», ahí arriba tienes la consulta. Nosotros esto lo miramos como parte del trabajo de Microsoft 365 y de ciberseguridad, y lo normal, por suerte, es no encontrar ninguno.

Fuentes (verificadas el 3 de septiembre de 2026): lista literal de limitaciones, condición de preview, congelado de septiembre de 2026, retirada «early 2027», procedimiento de edición y borrado y aviso sobre el JSON — Microsoft Learn, «Custom controls in Microsoft Entra Conditional Access» (revisión del 19-may-2026). Fechas de mayo de 2027 y 30 de abril de 2027 y pasos de migración — aviso del centro de mensajes de Microsoft 365 MC1422061, publicado el 9-jul-2026 (visible solo desde el inquilino). Configuración de External MFA, roles, nota sobre el kid en base64, exclusión de los informes de registro, comportamiento ante la pérdida de consentimiento, guía de convivencia con dos políticas y limitación de Windows 10 en OOBE — Microsoft Learn, «How to manage external MFA in Microsoft Entra ID» (actualización del 15-jun-2026). Propiedad customAuthenticationFactors — Microsoft Graph v1.0, «conditionalAccessGrantControls». No hemos encontrado en fuentes de Microsoft el comportamiento de una política que referencie un custom control tras la retirada; por eso no lo afirmamos.