Retiro de los controles personalizados de Entra ID: guía de migración a External MFA antes de septiembre de 2026

Retiro de los controles personalizados de Entra ID y los métodos de autenticación externa: qué cambia y por qué

El retiro de los controles personalizados de Entra ID —los Custom Controls de Conditional Access— en favor de los métodos de autenticación externa ya tiene una fecha fijada por Microsoft. Según la propia documentación de Conditional Access de Microsoft Learn, a partir de septiembre de 2026 dejará de ser posible crear nuevos controles personalizados o editar los existentes, y el retiro completo está previsto para principios de 2027. Un aviso del Centro de mensajes de Microsoft 365, MC1422061 ("Microsoft Entra ID: retiro de los controles personalizados en Conditional Access y migración a External MFA"), confirma el mismo congelamiento de septiembre de 2026 y fija el retiro completo en mayo de 2027, fecha en la que los controles personalizados dejarán de ser compatibles por completo. Los métodos de autenticación externa (External Authentication Methods) — la capacidad basada en estándares que Microsoft ahora comercializa como External MFA — son el único reemplazo compatible.

Los controles personalizados nunca fueron una función de Conditional Access disponible de forma general para el público masivo — Microsoft Learn los describe desde siempre como "una funcionalidad en versión preliminar". Cuando una directiva usaba uno, el navegador del usuario conectado se redirigía a un servicio de terceros aprobado, la autenticación se completaba allí y luego se redirigía de vuelta a Entra ID, que verificaba la respuesta antes de continuar el flujo de inicio de sesión. Esa indirección es exactamente lo que se está retirando: el mismo resultado —MFA de terceros aplicada dentro de Conditional Access— ahora se ejecuta mediante un método de autenticación nativo y de disponibilidad general, en lugar de una negociación de redirección y verificación.

Cómo funcionan los controles personalizados — y por qué External MFA los reemplaza

El retiro no es cosmético. Las propias guías de migración de Microsoft enumeran vacíos funcionales concretos que los controles personalizados siempre han tenido, vacíos que External MFA cierra:

Fuente: Microsoft Learn, "Migrate from custom controls to external MFA in Conditional Access".

La documentación de Microsoft Learn sobre controles personalizados enumera el mismo vacío desde el otro ángulo: los controles personalizados explícitamente no pueden usarse para satisfacer el requisito de MFA automatizado de Identity Protection, el restablecimiento de contraseña de autoservicio de Microsoft Entra, los requisitos de notificación MFA, los controles de frecuencia de inicio de sesión, la activación de roles de PIM, la inscripción de dispositivos de Intune, la relación de confianza entre inquilinos o la incorporación de dispositivos. Un inquilino que depende de un control personalizado para "hacer MFA" ha estado, en la práctica, ejecutando un sustituto que varias otras funciones de Entra no reconocen en absoluto como MFA — una brecha significativa frente a los métodos nativos que cubrimos en nuestro análisis de los cambios en el registro de MFA sin contraseña.

También hay un matiz de nomenclatura que conviene señalar para evitar confusión durante la migración: el reemplazo se lanzó en versión preliminar como "external authentication methods" y luego alcanzó la disponibilidad general bajo el nombre External MFA (External Multifactor Authentication), según el anuncio de disponibilidad general de Microsoft en el blog de Entra. Microsoft Learn, la interfaz del centro de administración y los objetos de la API de Graph (externalAuthenticationMethodConfiguration) siguen usando internamente la terminología "external authentication method", así que es de esperar ver ambos nombres según dónde se consulte.

Detección: localizar cada directiva de Conditional Access que use controles personalizados

Antes de tocar nada, haga un inventario de qué directivas de Conditional Access usan realmente hoy un control personalizado. Para un panorama más amplio de las malas configuraciones de Conditional Access más allá de los controles personalizados, consulte nuestra guía sobre las brechas de acceso condicional en Entra ID. Según la guía de migración de Microsoft, esto puede hacerse de dos formas:

Portal: inicie sesión en el centro de administración de Microsoft Entra al menos con el rol de Administrador de directivas de autenticación, vaya a Protection > Conditional Access > Policies, y revise los controles de concesión de cada directiva en busca de una referencia a un control personalizado. Por cada coincidencia, registre el nombre e ID de la directiva, los usuarios/grupos y aplicaciones en la nube afectados, el proveedor del control personalizado referenciado, y las condiciones aplicables (ubicaciones, plataformas de dispositivo).

Microsoft Graph PowerShell (más rápido para inquilinos grandes — la guía de Microsoft señala que algunos entornos tienen decenas o cientos de directivas de Conditional Access que revisar):

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.GrantControls -and (
        @($_.GrantControls.CustomAuthenticationFactors) |
        Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }
    ).Count -gt 0
} | Select-Object Id, DisplayName, State, @{
    N = "CustomAuthFactors"
    E = { ($_.GrantControls.CustomAuthenticationFactors | Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }) -join "," }
}

Fuente: Microsoft Learn, "Migrate from custom controls to external MFA in Conditional Access".

Exporte los resultados antes de empezar a migrar. Si una directiva no tiene ninguna referencia a un control personalizado, según la propia guía de Microsoft no se requiere ninguna acción sobre ella — no dedique esfuerzo de migración a directivas no afectadas.

Corrección: migrar a los métodos de autenticación externa antes del plazo

Una vez realizado el inventario, la guía de migración de Microsoft plantea una ruta por fases. Primero los requisitos previos: una licencia de Microsoft Entra ID P1 o P2, el rol de Administrador de directivas de autenticación (el de Administrador global también sirve), el rol de Administrador de roles con privilegios para conceder el consentimiento del administrador a la aplicación del proveedor, y los metadatos de su proveedor de External MFA — su Application ID, Client ID y URL de descubrimiento OIDC.

1. Registrar el proveedor de External MFA. En el centro de administración, vaya a Protection > Authentication methods > Policies > Add external method, indique el nombre visible (no se puede cambiar tras la creación), el Client ID, el App ID y el punto de conexión de descubrimiento, y luego conceda el consentimiento del administrador a la aplicación del proveedor. La misma configuración está disponible mediante la API de Graph (POST /policies/authenticationMethodsPolicy/authenticationMethodConfigurations con @odata.type: "#microsoft.graph.externalAuthenticationMethodConfiguration") o el cmdlet de PowerShell New-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration, para los equipos que automatizan el despliegue.
2. Dirigirse solo a un grupo de prueba —no a todos los usuarios— al habilitar el método, y registrar a esos usuarios de prueba en el método de autenticación externa antes de continuar.
3. Crear una nueva directiva de Conditional Access en modo Solo informe (Report-only) que use el control de concesión estándar Requerir autenticación multifactor (no el control personalizado), con el mismo alcance de aplicaciones en la nube y condiciones que la directiva heredada, dirigida al grupo de prueba, y excluyendo las cuentas de acceso de emergencia break-glass.

🚨 Peligro: la guía de Microsoft es explícita: External MFA todavía no es compatible con "Requerir solidez de autenticación" —solo el control de concesión estándar "Requerir autenticación multifactor" lo satisface—. Crear la directiva de prueba sobre un requisito de solidez de autenticación fallará de forma silenciosa y no funcionará como se espera.

4. Verificar primero en modo Solo informe mediante la pestaña de Conditional Access de los registros de inicio de sesión, confirmar que la directiva se evalúa como se espera y que el método MFA aparece como su proveedor externo, y luego cambiar la directiva a Activada.
5. Excluir al grupo de prueba de la directiva heredada basada en el control personalizado y confirmar con la herramienta What If que solo la nueva directiva se les aplica, y que los inicios de sesión de prueba realmente son desafiados por el proveedor externo y no por el control personalizado.
6. Desplegar por fases —grupo de prueba, luego TI/usuarios pioneros, luego departamento por departamento, luego todos los usuarios— ampliando en cada etapa tanto el grupo objetivo del método External MFA como el alcance de la nueva directiva de Conditional Access.
7. Retirar la directiva heredada al final, no al principio. Deshabilite (sin eliminar) la antigua directiva basada en el control personalizado y supervise los registros de inicio de sesión durante una o dos semanas antes de eliminarla y retirar la definición del control personalizado, manteniendo una vía de reversión disponible por si hay regresiones.

Cómo lo detecta EtcSec

Las comprobaciones de Conditional Access de EtcSec señalan la brecha que este retiro pone al descubierto: CA_NO_MFA_REQUIREMENT identifica aplicaciones en la nube y ámbitos de usuarios sin ninguna directiva de Conditional Access que realmente exija MFA —exactamente el estado en el que cae un inquilino si una directiva basada en un control personalizado deja de funcionar silenciosamente y nada la reemplaza—. MFA_NOT_ENFORCED_ADMINS y MFA_NO_STRONG_METHOD detectan cuentas con privilegios y configuraciones de método débil que un control personalizado roto o no migrado puede ocultar, ya que los controles personalizados nunca se reflejaron como una notificación MFA nativa. CA_POLICY_REPORT_ONLY señala las directivas —incluida la directiva de prueba en modo Solo informe que recomienda esta migración— que nunca se cambiaron a modo forzado, para que una migración pausada no pase inadvertida.