Retirada MFA SMS Entra ID Passkeys: el calendario de migración

Retirada MFA SMS Entra ID Passkeys: qué está cambiando

La migración retirada MFA SMS Entra ID passkeys de Microsoft sustituye su propia entrega de códigos por SMS y llamada de voz para la autenticación multifactor (MFA) por las passkeys como experiencia de autenticación predeterminada. No se trata de una simple inferencia de catálogo: es un cambio de política de producto fechado y publicado, documentado directamente por Microsoft (Passkeys by default and retirement of Microsoft-provided SMS and voice authentication, Microsoft Learn).

Esta es una historia distinta, más concreta, que el caso general que planteamos en Identidad Azure: MFA, metodos y Security Defaults — ese artículo defiende que la mera presencia de MFA no basta por sí sola; este trata sobre un canal de entrega concreto y phishable (SMS/voz proporcionado por Microsoft) que se apaga en una fecha fija, junto a otros patrones heredados débiles como el MFA fatigue / push bombing que métodos resistentes al phishing como las passkeys buscan cerrar.

El motivo es explícito en la propia FAQ de Microsoft: los códigos por SMS y voz son phishables y vulnerables al SIM-swapping, y ya no cumplen el nivel que Microsoft quiere como opción predeterminada para la autenticación en Entra ID (FAQ for Microsoft-provided SMS and voice retirement, Microsoft Learn).

El calendario de retirada

La retirada se aplica solo a tenants de la nube pública (otros entornos cloud siguen un calendario posterior, anunciado por separado), cubre tanto el SSPR como el MFA de inicio de sesión, y no afecta a Azure AD B2C. Microsoft Entra External ID se ve afectado en un calendario separado y posterior, con su propio anuncio aún pendiente.

Existe un opt-out temporal para la ventana de auto-inscripción (1 de septiembre de 2026 → 1 de febrero de 2027) — no para la aplicación del 1 de febrero en sí — mediante la propiedad passkeyDynamicMigration en la política de métodos de autenticación del tenant:

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
{
   "optOutSettings": {
     "passkeyDynamicMigration": true
   }
}

Detección: quién en su tenant sigue expuesto

Antes de que esto se implemente automáticamente en su tenant, averigüe cuántos usuarios dependen todavía realmente del SMS o la voz proporcionados por Microsoft, y si su configuración actual de Conditional Access y de Registration Campaign interactuará limpiamente con los propios cambios de Microsoft del 1 de septiembre. Si no ha revisado su base de Conditional Access recientemente, vea primero Brechas acceso condicional Entra ID: que errores dejan una exposicion real.

Remediación

1. Inventaríe primero a los usuarios expuestos. Use el script oficial de PowerShell para listar cada cuenta todavía habilitada para, o usando, SMS/voz. Cualquier resultado distinto de cero significa que el tenant está en alcance.
2. Migre a los usuarios hacia passkeys de forma proactiva, en su propio calendario. Habilite Passkey (FIDO2) como método de autenticación, incluya a su población de SMS/voz en un grupo de Authentication Methods Policy habilitado para passkeys, y active usted mismo una Registration Campaign (centro de administración de Entra → Authentication methods → Registration campaign → State: Microsoft Managed, con alcance a su grupo de seguridad de SMS/voz) — es el mismo mecanismo que Microsoft aplicará automáticamente el 1 de septiembre de 2026, pero usted controla el mensaje y el momento.
3. Si algún segmento tiene una necesidad genuina de cumplimiento u operativa de SMS/voz, documente ahora la regulación o el escenario concreto, evalúe después un proveedor de telecomunicaciones gestionado por el cliente a través del Microsoft Security Store desde el 18 de septiembre de 2026, y configúrelo desde el 30 de octubre de 2026, antes del cambio del 1 de febrero de 2027.
4. Use el opt-out passkeyDynamicMigration solo como puente, no como plan a largo plazo. Retrasa la auto-inscripción y la presión de la Registration Campaign mientras completa el trabajo de migración; no retrasa ni exime la aplicación del 1 de febrero de 2027.
5. Comunique con antelación. Microsoft recomienda un plan de comunicación por fases de concienciación → acción → recordatorio y publica plantillas para usuarios finales para el cambio a passkeys — dirija la comunicación al grupo de seguridad que construyó en el paso 1 para que los usuarios adecuados se enteren antes de que empiece el aviso.
6. Vuelva a revisar el Conditional Access. Un tenant que ya bloquea la autenticación legacy y exige MFA de forma amplia a todos los usuarios, no solo a los administradores, absorbe este cambio con mucha menos disrupción que uno que depende del SMS/voz como respaldo silencioso. Para una guía completa, vea Cómo auditar la seguridad de Microsoft Entra ID (Azure AD): guía práctica.

Cómo lo detecta EtcSec

La auditoría de Azure/Entra de EtcSec marca los tenants que siguen expuestos a esta retirada antes de que se convierta en una migración involuntaria. AUTH_METHODS_SMS_ENABLED informa cuando el SMS está habilitado como método de autenticación, sin más; MFA_PHONE_ONLY marca las cuentas donde los métodos basados en teléfono (SMS, voz) son la única opción MFA registrada — exactamente la población que recibirá el aviso bloqueante de passkey el 1 de febrero de 2027. MFA_NO_PASSWORDLESS y MFA_NO_FIDO2 marcan los tenants que no han habilitado en absoluto métodos passwordless o FIDO2/passkey, que es el hueco previo que hay que cerrar antes de poder iniciar cualquier migración proactiva.