Retirada MFA SMS Entra ID a Passkeys: calendario

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

Fecha	Qué ocurre
1 de septiembre de 2026	Los usuarios actualmente habilitados para SMS o voz en la Authentication Methods Policy (AMP) o en la configuración MFA heredada quedan auto-habilitados para passkeys. Su Registration Campaign pasa a Microsoft Managed, apuntando a passkeys, y se anima a los usuarios a registrar una passkey la próxima vez que completen el MFA. Por defecto, el aviso tiene snoozes ilimitados.
18 de septiembre de 2026	Microsoft publica los detalles de los proveedores de telecomunicaciones gestionados por el cliente disponibles a través del Security Store.
30 de octubre de 2026	Los clientes que todavía necesiten SMS o voz pueden seleccionar y configurar un proveedor de telecomunicaciones a través del Security Store.
1 de febrero de 2027	La entrega de SMS y voz proporcionada por Microsoft queda totalmente retirada. Los usuarios cuyo único método MFA disponible siga siendo SMS o voz reciben un aviso de registro de passkey bloqueante: no pueden iniciar sesión hasta que registren una passkey. Microsoft afirma explícitamente: «No hay opt out de este comportamiento del 1 de febrero. Se aplicará a todos los tenants».

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.

Señal	Dónde mirar	Qué le indica
Alcance SMS/Voz en la Authentication Methods Policy	Centro de administración de Entra → Authentication methods → SMS / Voice call, o `GET /policies/authenticationMethodsPolicy` vía Microsoft Graph	Confirma si su tenant tiene usuarios dentro del alcance de la auto-inscripción del 1 de septiembre de 2026
Métodos habilitados/usados por usuario	El script oficial de PowerShell de Microsoft entra-sms-voice-usage-analyzer (enlazado desde el artículo de retirada en Learn)	Enumera exactamente qué usuarios siguen habilitados para, o usando activamente, SMS/voz — ejecútelo antes de planificar una oleada de migración
Sign-in logs, pestaña Authentication Details	Centro de administración de Entra → Sign-in logs → un evento de inicio de sesión → Authentication Details, o la propiedad `authenticationDetails` en `signIns` vía Graph	Muestra qué método se usó realmente en un inicio de sesión concreto (SMS, voz, passkey, FIDO2, Authenticator...) — uso, no solo habilitación
Informe de actividad de Authentication Methods	Centro de administración de Entra → Authentication methods → Activity	Vista de tendencia a nivel de tenant propia de Microsoft sobre registro y uso de métodos a lo largo del tiempo
Estado de la Registration Campaign	Centro de administración de Entra → Authentication methods → Registration campaign	Si esto no está ya en Microsoft Managed / apuntando a passkeys, Microsoft lo sobrescribirá para apuntar a sus usuarios de SMS/voz el 1 de septiembre de 2026 — compruebe ahora si gestiona una campaña personalizada
`optOutSettings.passkeyDynamicMigration`	`GET /policies/authenticationMethodsPolicy` vía Microsoft Graph	Confirma si el tenant ya ha optado por salir de la ventana de auto-inscripción

Remediación

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.
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.
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.
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.
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.
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.