Problema

Microsoft ha anunciado que dejará de ofrecer SMS y llamadas de voz como método de autenticación multifactor (MFA) dentro de Azure Entra ID. Los inquilinos que dependen de esos canales deben migrar a un método soportado, y la política predeterminada empuja a los usuarios que todavía usan SMS a adoptar Passkeys. El reto no es solo cambiar la UI; implica actualizar la configuración de MFA, validar que los usuarios tengan un método alternativo y evitar que el acceso se bloquee durante la transición. En entornos donde cientos o miles de cuentas usan SMS, la migración mal planificada genera tickets de soporte, bloqueos de cuentas y, en el peor caso, pérdida de acceso a recursos críticos.

Causa

  1. Descontinuación del servicio interno – Microsoft retiró la infraestructura que envía códigos por SMS/voice, por lo que cualquier intento de usar esos métodos falla con error “method not available”.
  2. Política de Passkeys por defecto – Cuando la plataforma detecta que un usuario solo tiene SMS configurado, marca automáticamente la cuenta para que registre un Passkey, pero no fuerza la eliminación del método antiguo.
  3. Falta de proveedor externo – La única forma de seguir usando SMS es registrar un proveedor MFA certificado (por ejemplo, Twilio, Nexmo). Si la organización nunca habilitó un proveedor externo, la transición queda sin fallback.
  4. Dependencias de scripts y automatizaciones – Muchos pipelines de CI/CD o scripts de PowerShell asumen que el método de MFA es SMS y fallan al recibir un desafío no soportado.

Solución

Una estrategia de migración en tres fases minimiza interrupciones y mantiene la seguridad.

1. Inventario y clasificación

Utiliza Azure CLI o PowerShell para obtener la lista de usuarios que sólo tienen SMS/voice como método MFA. Esto permite segmentar a los que necesitan intervención inmediata.

az ad user list --filter "strongAuthenticationMethods/any(m:m/method eq 'OneWaySMS')" \
    --query "[].{UserPrincipalName:userPrincipalName,Methods:strongAuthenticationMethods}" -o json > sms_users.json

Exporta el JSON y filtra con jq para identificar cuentas sin métodos alternativos.

2. Habilitar un proveedor MFA externo

Registra el proveedor en Azure Entra ID:

az ad authentication method provider create \
    --name "TwilioSMS" \
    --type "Sms" \
    --properties '{"apiKey":"<TU_API_KEY>","senderId":"<TU_SENDER_ID>"}'

Una vez creado, asigna la política a los usuarios o grupos afectados:

az ad authentication method policy update \
    --policy-id "MfaPolicy" \
    --allowed-providers "TwilioSMS" "MicrosoftAuthenticator"

Con esto, los usuarios que aún no tengan Passkey pueden seguir recibiendo códigos SMS a través del nuevo proveedor.

3. Forzar registro de Passkeys

Azure Entra ID permite requerir Passkeys mediante Conditional Access (CA). Crea una política CA que exija Passkey para todas las aplicaciones críticas, pero permite un “grace period” de 30 días donde el método SMS sigue activo.

az identity conditional-access policy create \
    --name "RequirePasskey" \
    --conditions '{"applications":{"include":["All"]},"users":{"include":["All"]}}' \
    --grant-controls '{"operator":"OR","builtInControls":["Passkey"]}' \
    --session-controls '{"signInFrequency": {"value":30,"type":"Days"}}'

Durante el periodo de gracia, comunica a los usuarios la necesidad de registrar su Passkey mediante el portal de Azure o la app Microsoft Authenticator. Automatiza recordatorios con Microsoft Graph:

curl -X POST https://graph.microsoft.com/v1.0/users/{id}/sendMail \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "message": {
          "subject": "Registra tu Passkey",
          "body": {
            "contentType": "Text",
            "content": "Tu método SMS será retirado en 30 días. Usa la app Authenticator para crear un Passkey."
          },
          "toRecipients": [{"emailAddress":{"address":"user@example.com"}}]
        }
      }'

4. Limpieza post‑migración

Una vez que el 100 % de los usuarios tengan Passkey activo y el proveedor externo esté probado, elimina el método SMS de la política:

az ad authentication method policy update \
    --policy-id "MfaPolicy" \
    --allowed-providers "MicrosoftAuthenticator"

Y desinstala el proveedor externo si ya no se necesita.

Cuándo aplicar esta solución

  • Síntomas: errores de MFA al iniciar sesión, tickets de “código SMS no recibido”, o alertas de Azure AD que indican “method not available”.
  • Entorno: cualquier tenant de Azure Entra ID con usuarios que dependen exclusivamente de SMS/voice MFA.
  • No aplica: organizaciones que ya migraron a Passkeys o que usan exclusivamente autenticadores basados en aplicación (Microsoft Authenticator, YubiKey). En esos casos basta con actualizar la política CA para eliminar la referencia a SMS.

Verificación

  1. Ejecuta el script de inventario y confirma que sms_users.json está vacío.
  2. Inicia sesión con una cuenta que tenía solo SMS; el desafío debe presentarse como Passkey o como código del nuevo proveedor.
  3. Revisa los logs de Azure AD Sign‑in (Azure portal > Sign‑ins) y busca eventos con authenticationMethod=Passkey.
  4. Verifica que la política CA “RequirePasskey” está en estado Enabled y que el grace period se muestra en la configuración.
  5. Después del periodo de gracia, intenta usar SMS; la autenticación debe fallar, confirmando que el método fue removido.

Notas adicionales

  • Los proveedores externos pueden incurrir en costos por mensaje; revisa la facturación antes de habilitar Twilio u otro servicio.
  • Los Passkeys no son compatibles con todos los navegadores antiguos; si tienes usuarios con versiones legacy, mantén una vía de recuperación mediante códigos de respaldo.
  • En entornos híbridos (AD on‑prem + Azure AD), sincroniza los atributos de MFA con Azure AD Connect para evitar que los cambios locales sobrescriban la nueva configuración.
  • Si alguna aplicación crítica no soporta Passkey, crea una excepción en la política CA antes de eliminar SMS por completo.
  • Documenta el proceso interno y guarda los scripts en un repositorio Git; así podrás reproducir la migración en otros tenants o en pruebas de recuperación.