Azure ya exige MFA para cambiar recursos desde la CLI: qué se rompe en tu automatización

Desde el 1 de julio de 2026 ya no hay forma de aplazarlo: cualquier cuenta de usuario que cree, modifique o borre recursos de Azure tiene que haber pasado por MFA, lo haga desde el portal, la CLI, PowerShell, Terraform o el SDK. Microsoft empezó a aplicar la segunda fase del MFA obligatorio el 1 de octubre de 2025, de forma gradual, y permitió a los inquilinos con entornos complejos posponerla hasta el 1 de julio de 2026. Esa fecha ya pasó.

Para la persona que entra al portal con el teléfono a mano, el cambio pasa casi desapercibido. Lo que se rompe es la automatización que corre con una cuenta de usuario: el script nocturno que escala un clúster, el pipeline que despliega con el usuario devops@ de la empresa, la tarea programada que alguien dejó con su propia contraseña hace cuatro años. Y se rompe tarde, porque las lecturas siguen funcionando: el script que solo consulta pasa, el que cambia algo falla.

¿Qué exige exactamente la fase 2 del MFA obligatorio de Azure?

MFA para toda operación de creación, actualización o borrado que llegue a Azure Resource Manager con la identidad de un usuario. Según la documentación de Microsoft Entra, la regla se aplica del lado del servidor: cualquier petición a https://management.azure.com entra en el alcance, sin importar el cliente. Eso incluye:

• Azure CLI y Azure PowerShell, que se identifican en los registros de inicio de sesión por sus ID de aplicación: 04b07795-8ddb-461a-bbee-02f9e1bf7b46 y 1950a258-227b-4e31-a9cf-717495945fc2.
• Las herramientas de infraestructura como código, que heredan la identidad de la CLI o de PowerShell.
• El SDK de Azure, la API REST del plano de control y la app móvil de Azure.

Las lecturas no exigen MFA. Microsoft Graph, en general, queda fuera. La cuenta de sincronización de Microsoft Entra Connect no se ve afectada.

Lo que no tiene excepción: las cuentas de emergencia, los administradores, los invitados B2B y los inquilinos de pruebas. Para las cuentas de emergencia, Microsoft recomienda passkeys FIDO2 o autenticación basada en certificados. Queda una sola válvula: una vez iniciada la aplicación, un administrador global puede pedir a soporte de Microsoft que la levante de forma temporal, sin que eso arregle nada.

¿Qué deja de funcionar en los scripts y pipelines?

Todo lo que obtiene un token con usuario y contraseña. El flujo OAuth 2.0 de credenciales de contraseña del propietario del recurso (ROPC) es incompatible con MFA, y Microsoft documenta el error que devuelve az login --username --password cuando el usuario tiene que usar MFA: AADSTS50076. Los casos típicos:

1. Scripts con az login -u -p guardados en un servidor o en una tarea programada. Si el inquilino ya exige MFA al iniciar sesión, fallan en el login con ese error. Si no, inician sesión, leen sin problema y fallan en la primera operación que cambia algo.
2. Código que usa DefaultAzureCredential con las variables de entorno AZURE_USERNAME y AZURE_PASSWORD definidas. Es el caso traicionero: el código no menciona ninguna contraseña, la credencial la toma del entorno por la vía de EnvironmentCredential, y Microsoft lo incluye entre los usos que exigen cambios.
3. Llamadas a AcquireTokenByUsernamePassword de MSAL, marcada como obsoleta para clientes públicos en las bibliotecas de .NET, Java, Node.js, Python y Go.
4. Cuentas de servicio sincronizadas desde Active Directory. Que vivan en el directorio local no las exime: quedan sujetas al mismo requisito que cualquier otro usuario.

Para diagnosticar: hasta Azure CLI 2.75, el fallo llega como un genérico “Resource was disallowed by policy. Reasons: MFA is required”. Desde la 2.76, la CLI devuelve además el comando exacto para reautenticarse con el desafío de claims. Microsoft recomienda Azure CLI 2.76 y Azure PowerShell 14.3 o posteriores.

¿Cómo encuentro las cuentas de usuario que hacen de cuenta de servicio?

Con los registros de inicio de sesión y una política en modo de solo informe, antes de que el error lo haga por ti. Tres fuentes, de la más barata a la más completa:

• Registros de inicio de sesión de Microsoft Entra, filtrados por los ID de aplicación de la CLI y de PowerShell, que es el filtro que sugiere Microsoft. Lo que buscamos: un usuario que inicia sesión siempre desde la IP de un servidor, a la misma hora, sin completar nunca un segundo factor. Eso no es una persona.
• Una política de acceso condicional en modo de solo informe que exija MFA sobre las aplicaciones Windows Azure Service Management API y Microsoft Admin Portals. El libro de trabajo de acceso condicional muestra cuántos inicios de sesión habrían fallado; requiere Entra ID P1 o P2 y los registros en Log Analytics.
• Azure Policy en modo auditoría, con las dos definiciones integradas que Microsoft publica en versión preliminar: una para crear o actualizar recursos y otra para borrarlos. Cada evento de auditoría es una operación real hecha sin MFA.

La trampa de la tercera opción: los eventos solo aparecen en el registro de actividad. La lista de cumplimiento de la política muestra siempre cero recursos, porque la política evalúa peticiones y no recursos, y es fácil concluir que no hay nada pendiente mirando esa pantalla. Para pasar de auditar a denegar, Microsoft recomienda hacerlo por regiones con selectores de recursos, empezando por las de menor riesgo.

¿A qué identidad migro cada automatización?

A una identidad de carga de trabajo: identidades administradas y principales de servicio quedan fuera del MFA obligatorio en las dos fases. Cuál depende de dónde corre el proceso:

• Si corre dentro de Azure (una VM, Functions, Automation): identidad administrada. Las credenciales no son visibles para nadie; Azure gestiona secretos, certificados y claves.
• Si es un pipeline de GitHub Actions: federación de identidades con OIDC. El job pide un token a GitHub y lo cambia por uno de Microsoft, sin secreto guardado. Según la guía de Microsoft, basta con el permiso id-token: write y la acción azure/login@v2 con los ID de cliente, de inquilino y de suscripción. Ese permiso va solo en el job que despliega, nunca a nivel de workflow.
• Si es Azure Pipelines: conexión de servicio con federación de identidades, que Microsoft recomienda como primera opción. Una conexión existente con secreto se convierte con un botón si la creó Azure DevOps y la usa un solo proyecto, y la conversión se puede revertir durante siete días. Anota además otro vencimiento: el emisor de Azure DevOps, vstoken.dev.azure.com, se retira el 1 de julio de 2027 a favor del emisor de Microsoft Entra.
• Si corre fuera de Azure (Kubernetes propio, AWS, Google Cloud o cargas con SPIFFE): la misma federación de identidades de carga de trabajo. El emisor, el sujeto y la audiencia del token tienen que coincidir exactamente, mayúsculas incluidas, con lo configurado en Entra. Si la federación rechaza un token que parece correcto, es lo primero que hay que revisar.

El principal de servicio con secreto también esquiva el MFA, pero cambia un problema por otro: un secreto que hay que guardar, rotar y que un día caduca en mitad de un despliegue. Lo usamos solo cuando no hay federación posible, y con certificado en lugar de secreto.

¿Y la trazabilidad, si el cambio ya no lo firma una persona?

Mejora, si se hace bien. Es el argumento que más se oye para conservar cuentas de usuario en la automatización, pero detrás de devops@ suele haber cuatro personas con la misma contraseña. Quién hizo el cambio lo responde el pipeline: quién aprobó la ejecución, qué commit se desplegó y con qué identidad. Un entorno protegido con aprobación obligatoria deja esa cadena registrada sin que nadie comparta credenciales.

¿Qué cambia en Google Cloud a partir del 20 de octubre?

La verificación en dos pasos pasa a ser obligatoria para entrar a la consola de Google Cloud y a la de Firebase en las organizaciones con Cloud Identity empresarial sin SSO. El calendario de Google, actualizado el 24 de septiembre, fija las fechas que afectan a una empresa:

• Cloud Identity empresarial sin SSO, organizaciones creadas antes del 3 de agosto de 2026: a partir del 20 de octubre de 2026, con una extensión única de 90 días que se activa a nivel de organización.
• Organizaciones creadas desde el 3 de agosto de 2026: 30 días después de su creación.
• Cuentas con autenticación federada: fecha por anunciar.

La diferencia con Azure es de fondo. En Google, la CLI gcloud no tiene requisito de verificación en dos pasos, y las aplicaciones, las cargas de trabajo y el plano de datos no se ven afectados; el segundo factor se exige para gestionar desde la consola. En Google, el requisito recae sobre las personas; en Azure, rompe la automatización. Google permite además a estas organizaciones excluirse del requisito. La opción existe y no la usaríamos: la cuenta que no puede tener segundo factor suele ser justo la que conviene convertir en identidad de carga de trabajo.

Por dónde empezaríamos esta semana

1. Confirmar el estado del inquilino. Un administrador global ve en aka.ms/postponePhase2MFA si la fase 2 ya se aplica.
2. Listar los inicios de sesión de la CLI y de PowerShell de los últimos 30 días y separar personas de procesos.
3. Buscar AZURE_USERNAME y az login -u en servidores, tareas programadas y variables de los pipelines, no solo en los repositorios.
4. Migrar por orden de impacto: primero lo que despliega o escala en producción; cada proceso con su propia identidad y el rol mínimo.
5. Configurar las cuentas de emergencia con passkey FIDO2 y entrar con una de ellas. Una cuenta de emergencia que nunca se probó no es un plan.
6. Si hay organizaciones de Google Cloud sin SSO, activar la verificación en dos pasos antes del 20 de octubre en lugar de gastar la extensión de 90 días.

Cómo te ayudamos en Athrun Data Intelligence

Llamada de 30 minutos para revisar qué procesos de tu nube siguen corriendo con cuentas de usuario y cuáles se van a romper la próxima vez que intenten cambiar algo. Si encaja, hacemos el inventario desde los registros de inicio de sesión, migramos cada automatización a identidades administradas o federadas con el rol mínimo, y dejamos Azure Policy en modo de denegación región por región, sin cortar producción.