Microsoft endurecerá la seguridad de Azure de forma escalonada y obligará al uso de MFA (autenticación multifactor) en la gestión de recursos a partir de octubre de 2025, con opciones limitadas de aplazamiento para algunos clientes. La medida, enmarcada en la Secure Future Initiative (SFI), busca reducir accesos no autorizados y blindar el plano de control de la nube de Redmond frente a el uso de credenciales robadas. La compañía ya está aplicando MFA obligatorio en portales administrativos desde 2024 y extenderá la exigencia a CLI, PowerShell, SDKs y API REST a partir del 1 de octubre de 2025.
Más allá del titular, el diablo está en los detalles: quién queda afectado, qué herramientas y versiones son compatibles, cómo se gestiona el impacto en scripts y automatizaciones, y qué margen real existe para aplazar la aplicación según el tipo de inquilino (tenant). A continuación, un repaso exhaustivo —y práctico— de la nueva política.
Dos fases, varios hitos y un calendario que se acelera
Microsoft ha dividido la implantación en dos fases:
- Fase 1 (portales y centros de administración)
Desde octubre de 2024, se exige MFA para iniciar sesión en el Azure portal, Microsoft Entra admin center y Microsoft Intune admin center para cualquier operación CRUD (Create, Read, Update, Delete). Desde febrero de 2025, la obligación se amplía al Microsoft 365 admin center. El despliegue es progresivo a escala global. - Fase 2 (herramientas de administración y plano de control)
A partir del 1 de octubre de 2025, comenzará gradualmente la exigencia de MFA para cuentas que inicien sesión en Azure CLI, Azure PowerShell, Azure mobile app, herramientas IaC (vía CLI o PowerShell), SDKs de Azure y endpoints REST del plano de control para cualquier operación Create/Update/Delete. Las operaciones Read no requerirán MFA.
Aplazamientos posibles: los administradores globales podrán posponer la Fase 1 (portales) hasta el 30 de septiembre de 2025, y la Fase 2 (CLI/PowerShell/APIs) hasta el 1 de julio de 2026. Microsoft avisa: aplazar aumenta el riesgo y recomienda activar MFA cuanto antes.
Quién queda afectado (y quién no)
- Afectados: todos los usuarios que inicien sesión en las aplicaciones y herramientas indicadas para realizar operaciones de administración. No se limita a roles administrativos: cualquier cuenta que ejecute una operación cubierta por el ámbito deberá superar MFA. También aplica a cuentas B2B invitadas (vía claims MFA entre tenants).
- No afectados: identidades de carga de trabajo (workload identities), como managed identities y service principals, no quedan sujetas a la aplicación de MFA. El objetivo es migrar automatizaciones que hoy usan identidades de usuario a identidades de carga de trabajo.
- Nubes soberanas: la aplicación obligatoria se limita a Azure público. De momento no se fuerza en Azure for US Government ni en otras nubes soberanas.
Impacto en automatizaciones y scripts: qué cambia
Un punto especialmente sensible es el uso de cuentas de usuario como cuentas de servicio en scripts, pipelines y herramientas IaC. Microsoft recomienda descubrir esos usos y migrar a workload identities (service principal/managed identity) antes del inicio de la Fase 2: las cuentas de usuario tendrán que pasar MFA, lo que rompe la no interacción típica de la automatización.
Además, el flujo ROPC (Resource Owner Password Credentials) de OAuth 2.0 —empleado por algunas bibliotecas/credenciales “usuario/contraseña”— no es compatible con MFA: al habilitar MFA, las API basadas en ROPC fallarán. Microsoft ofrece guías para migrar desde ROPC en MSAL y desde UsernamePasswordCredential en Azure Identity hacia métodos compatibles.
Requisitos de versión y compatibilidad
Para evitar errores y soportar los nuevos desafíos de claims, Microsoft aconseja:
- Azure CLI: actualizar a v2.76 o superior.
- Azure PowerShell: actualizar a v14.3 o superior (módulo Az).
Estos requisitos aseguran compatibilidad con claims challenge y mejores mensajes de error cuando una operación falla por políticas de MFA.
Nota práctica: versiones recientes de Az.Accounts incorporan el parámetro
-ClaimsChallengeenConnect-AzAccount, facilitando responder a exigencias de MFA impuestas por aplicaciones/recursos.
¿Y si ya se aplicaba MFA en mi organización?
Para organizaciones que ya exigen MFA (por Conditional Access o Security Defaults), no hay cambios: el nuevo requisito se “superpone” a lo existente. Si solo una parte de los usuarios estaba obligada, el resto deberá cumplir MFA al acceder a las aplicaciones afectadas cuando comience la aplicación para su tenant.
Licenciamiento: el uso de Conditional Access requiere Microsoft Entra ID P1 o P2; si no es posible, activar Security Defaults. Las políticas más restrictivas (p. ej., MFA resistente al phishing con FIDO2/passkey) seguirán aplicándose.
Métodos de MFA y proveedores externos
- Métodos como passkeys FIDO2, claves de seguridad, certificado o Microsoft Authenticator cumplen con el requisito.
- Soporte para MFA externo: existe en vista previa mediante “external authentication methods”; los custom controls heredados de Conditional Access no satisfacen la obligación. En entornos federados (AD FS u otros IdP), el IdP debe enviar la claim de MFA correctamente.
Cuentas de emergencia (“break glass”): también deberán usar MFA cuando se aplique. Microsoft recomienda passkey (FIDO2) o autenticación basada en certificado para cumplir sin depender de un segundo dispositivo “frágil”.
Por qué ahora: datos de eficacia y tendencia del sector
Microsoft subraya que la MFA bloquea el 99,2 % de los intentos de compromiso de cuentas y que reduce el riesgo de compromiso en un 98,56 %, incluso si el atacante usa credenciales robadas. Además, en comunicaciones recientes ha citado que el 99,99 % de las cuentas con MFA resisten ataques. Estas métricas explican la decisión de pasar de las recomendaciones a la imposición por defecto.
La medida sigue la senda de otras acciones del ecosistema: GitHub —propiedad de Microsoft— empezó a exigir 2FA de forma general a los desarrolladores activos desde enero de 2024, precisamente para reforzar la seguridad de la cadena de suministro de software.
Qué verán los usuarios y cómo se notificará
Cuando un usuario sin MFA intente crear/actualizar/eliminar recursos en aplicaciones de la Fase 2, recibirá un error con claims challenge indicando que debe iniciar sesión con MFA. Algunas aplicaciones podrán elevar (step-up) y solicitar MFA en el momento; otras mostrarán solo el error. Por eso Microsoft recomienda aplicar MFA antes mediante Conditional Access o Security Defaults, para evitar fricciones de usuario.
En la Fase 1, Microsoft ha venido avisando con mensajes del Centro de mensajería en M365 con ~30 días de antelación al tenant; la misma práctica se mantendrá para nuevas oleadas.
Hoja de ruta para equipos de TI: pasos concretos
- Inventario de accesos y cuentas
- Identificar usuarios que administren Azure vía portal, Intune, Entra, CLI, PowerShell, SDKs o APIs.
- Localizar cuentas de usuario usadas como servicio en scripts/pipelines.
- Migrar automatizaciones a identidades de carga de trabajo
- Sustituir cuentas de usuario por service principal o managed identity.
- Actualizar scripts para autenticación no interactiva compatible. Microsoft publica guías específicas para CLI y PowerShell.
- Política de acceso condicional o Security Defaults
- Requerir MFA por aplicación y condición; priorizar FIDO2/passkey (resistentes a phishing).
- Revisar exclusiones: ya no aplicarán frente a la aplicación obligatoria.
- Actualizar herramientas
- Azure CLI ≥ 2.76; Azure PowerShell (Az) ≥ 14.3. Validar
Connect-AzAccountcon claims challenge.
- Azure CLI ≥ 2.76; Azure PowerShell (Az) ≥ 14.3. Validar
- Pruebas controladas
- Usar plantillas de Conditional Access para probar MFA.
- Verificar que ROPC no se utilice; migrar a MSAL interactivo/device code/credentials compatibles.
- Monitoreo y soporte
- Revisar sign-in logs en Entra para confirmar qué aplicación exigió MFA.
- Habilitar reportes de registro de métodos para seguir el alta de usuarios en MFA.
Riesgos de aplazar (y por qué no conviene)
Microsoft permite diferir el inicio de la aplicación (Fase 1 y Fase 2), pero advierte que los accesos administrativos a Azure son objetivos de alto valor para los atacantes. Aplazar significa exposición durante más tiempo y dependencia de credenciales que, en demasiadas ocasiones, circulan en mercados ilícitos. La recomendación oficial es activar MFA ya y usar el aplazamiento solo si existen barreras técnicas reales que requieran más tiempo de preparación.
Contexto y lectura estratégica
La obligatoriedad de MFA en el plano de control de Azure encaja en una tendencia clara: securizar por defecto las superficies críticas de la nube, reducir la superficie de ataque de password spraying/credential stuffing y frenar la escalada de incidentes con origen en tokens robados o portales sin MFA. A la luz de los datos de eficacia —resistencias por encima del 99,2 %—, el equilibrio entre usabilidad y seguridad bascula definitivamente hacia el segundo factor.
Para las organizaciones, el reto inmediato no es tecnológico, sino operativo: descubrir automatizaciones basadas en cuentas de usuario, migrarlas a identidades de carga de trabajo, educar a los equipos y estandarizar métodos de MFA robustos (passkey/FIDO2) que minimicen fricción y tickets de soporte. Es, en definitiva, una oportunidad para ordenar la casa antes de que la plataforma imponga lo que —a tenor de las cifras— ya no es negociable.
Preguntas frecuentes (FAQ)
1) ¿Afecta a todos los usuarios o solo a administradores?
A todos los usuarios que inicien sesión en las aplicaciones y herramientas dentro del alcance (portales, Azure CLI, PowerShell, SDKs, API REST) para operaciones de administración. No se limita a roles con privilegios.
2) ¿Mis scripts dejarán de funcionar?
Si usan cuentas de usuario, sí: deberán pasar MFA y fallarán en escenarios no interactivos. La guía es migrar a workload identities (service principal o managed identity) y actualizar la autenticación.
3) ¿Puedo usar un proveedor externo de MFA o un IdP federado?
Sí, en vista previa mediante external authentication methods en Entra ID. En federación (AD FS/u otro IdP), el IdP debe enviar la claim MFA a Entra para satisfacer el requisito. Los custom controls antiguos no valen.
4) ¿Qué versiones mínimas debo tener para evitar errores?
Azure CLI ≥ 2.76 y Azure PowerShell (Az) ≥ 14.3. Además, versiones recientes de Az.Accounts incluyen -ClaimsChallenge para responder a exigencias de MFA.
Fuentes: documentación oficial de Microsoft sobre la aplicación obligatoria de MFA para Azure/Entra y anuncios correlacionados en Tech Community y prensa técnica. (Microsoft Learn, TECHCOMMUNITY.MICROSOFT.COM, BleepingComputer)
