Microsoft pone fecha de fin a la autenticación por SMS de Entra ID: qué debes saber antes de adoptar passkeys

Durante años, los mensajes SMS y las llamadas telefónicas han servido como métodos de autenticación y recuperación en numerosas organizaciones. Sin embargo, el aumento del phishing, la interceptación de códigos y los ataques de ingeniería social ha puesto de manifiesto las limitaciones de estos mecanismos.

Microsoft ha iniciado una transición hacia métodos de autenticación resistentes al phishing, situando las passkeys en el centro de su estrategia. Desde el 1 de septiembre de 2026, los usuarios habilitados para SMS o voz pueden ser dirigidos automáticamente hacia el registro de passkeys. Además, el 1 de febrero de 2027 se retirará la prestación de SMS y voz gestionada directamente por Microsoft en Entra ID.

Este cambio no consiste únicamente en activar una nueva opción. Obliga a revisar cómo se autentican los usuarios, qué métodos utilizan para recuperar su contraseña y qué configuraciones heredadas continúan gobernando el tenant.

Frente a este escenario, las organizaciones necesitan una transición progresiva que combine seguridad, continuidad operativa y una experiencia de usuario asumible. ¡Sigue leyendo y descubre cómo abordar el cambio!

Qué cambia en Microsoft Entra ID

Microsoft está avanzando hacia un modelo en el que las passkeys se convierten en la experiencia de autenticación preferente y los métodos basados en telecomunicaciones dejan de ser proporcionados de forma nativa por Entra ID.

El calendario establece dos momentos especialmente relevantes:

• Desde el 1 de septiembre de 2026: los usuarios habilitados para SMS o llamada pueden ser incluidos automáticamente en la experiencia de registro de passkeys.
• A partir del 1 de febrero de 2027: Microsoft dejará de proporcionar directamente la entrega de SMS y voz en Entra ID.

Después de esa fecha, los usuarios cuyo único método disponible sea SMS o llamada pueden encontrar un proceso de registro obligatorio antes de continuar accediendo a su cuenta. Para las organizaciones que necesiten conservar estos canales, será necesario analizar las alternativas disponibles y su encaje en la estrategia de identidad.

El impacto depende de la situación de cada tenant. Una organización que ya utiliza Microsoft Authenticator, Windows Hello for Business o FIDO2 parte de una posición muy diferente a otra en la que numerosos usuarios todavía dependen del teléfono.

Por eso, el primer paso no debería ser activar o desactivar métodos, sino conocer el uso real.

Qué son las passkeys y por qué son más seguras

Las passkeys son credenciales basadas en el estándar FIDO2 y en criptografía de clave pública. En lugar de utilizar una contraseña o un código que el usuario debe recordar e introducir, el sistema genera un par de claves:

• La clave privada permanece protegida en el dispositivo o proveedor de passkeys.
• La clave pública se registra en Microsoft Entra ID.
• El usuario desbloquea la credencial mediante biometría, PIN u otro mecanismo local.

La clave privada no se envía durante el acceso. Además, la credencial queda vinculada al servicio para el que fue creada, lo que dificulta que pueda utilizarse desde una página de phishing.

Desde el punto de vista de seguridad, las passkeys reducen la exposición a:

• Robo y reutilización de contraseñas.
• Interceptación de códigos de un solo uso.
• Ataques de phishing en tiempo real.
• Fatiga de notificaciones MFA.
• Ingeniería social dirigida al usuario.

Microsoft considera las passkeys un método resistente al phishing y permite utilizarlas para satisfacer MFA. Existen diferentes modalidades, como credenciales vinculadas a un dispositivo, llaves de seguridad físicas o passkeys sincronizadas, cuya idoneidad debe evaluarse según el perfil de riesgo y el tipo de usuario.

No obstante, passkey y Windows Hello for Business no son exactamente lo mismo. Como vimos en nuestro artículo sobre Windows Hello for Business y Passwordless, WHfB está orientado también al inicio de sesión en el dispositivo y al acceso integrado a recursos corporativos. Una passkey de Entra ID en Windows es una credencial FIDO2 vinculada al dispositivo, pero no sustituye por sí sola el inicio de sesión en el equipo.

Impacto sobre la configuración actual del tenant

Uno de los principales errores en este tipo de proyectos es asumir que Microsoft Entra ID tiene una única configuración de autenticación claramente definida.

En muchos tenants conviven tres realidades:

1. La política moderna de métodos de autenticación.
2. Las configuraciones heredadas de MFA.
3. Las configuraciones heredadas de autoservicio de restablecimiento de contraseña o SSPR.

Cuando el tenant se encuentra en estado Migration in Progress, la política moderna y las configuraciones heredadas pueden participar simultáneamente en el comportamiento efectivo. Como consecuencia, un método que aparentemente está deshabilitado en una pantalla podría continuar disponible debido a otra política.

Al completar la migración, Microsoft Entra ID pasa a utilizar exclusivamente la política moderna para gobernar los métodos de autenticación y SSPR. Este cambio no copia automáticamente la configuración heredada ni garantiza que todos los usuarios conserven los métodos que necesitan.

Antes de modificar el estado del tenant es necesario conocer:

• Qué métodos están permitidos en cada política.
• Qué usuarios y grupos están incluidos o excluidos.
• Qué métodos han registrado realmente los usuarios.
• Cuáles se utilizan para iniciar sesión.
• Qué mecanismos intervienen en la recuperación de contraseña.
• Si existen colectivos cuyo único método efectivo sea SMS o llamada.

También es importante diferenciar entre un método permitido y un método registrado. Habilitar una passkey para un grupo no significa que sus integrantes ya dispongan de ella.

Convivencia con MFA y recuperación de contraseña

Las passkeys pueden utilizarse como método MFA, pero actualmente no son válidas para el autoservicio de restablecimiento de contraseña.

Esta diferencia tiene una implicación práctica: una organización no debería retirar los métodos existentes simplemente para forzar el uso de passkeys.

Si SSPR requiere dos métodos de verificación, cada usuario deberá conservar suficientes métodos compatibles y permitidos. De lo contrario, podría iniciar sesión mediante una passkey, pero no recuperar su cuenta cuando lo necesite.

Un escenario habitual consiste en encontrar usuarios que utilizan Microsoft Authenticator para MFA, pero dependen del teléfono o el correo para SSPR. En otros casos, existen usuarios cuyo único segundo factor continúa siendo SMS.

La solución no consiste en replicar sin criterio todas las configuraciones heredadas. Es necesario definir un escenario objetivo que responda a las necesidades reales:

• Métodos resistentes al phishing para el acceso.
• Alternativas válidas para recuperación.
• Mecanismos especiales para cuentas administrativas o de emergencia.
• Un periodo de convivencia mientras se completa la adopción.
• Una estrategia específica para los usuarios que todavía dependen del teléfono.

Este análisis permite evitar dos extremos: mantener indefinidamente métodos débiles o retirarlos antes de que exista una alternativa operativa.

Compatibilidad con dispositivos y experiencia de usuario

Las passkeys mejoran la seguridad, pero su adopción depende también de los dispositivos y del contexto de trabajo.

En Windows es necesario comprobar la compatibilidad con Windows Hello, el estado del sistema y la posible existencia de credenciales corporativas anteriores. Si una cuenta ya utiliza Windows Hello for Business en el mismo entorno, el registro de una nueva passkey puede requerir una revisión específica para evitar duplicidades o errores de credencial existente.

En dispositivos móviles también deben considerarse:

• Versión del sistema operativo.
• Aplicación utilizada como proveedor de passkeys.
• Biometría o bloqueo seguro.
• Políticas de administración del dispositivo.
• Restricciones de acceso condicional.
• Diferencias entre dispositivos corporativos y personales.

La experiencia de usuario cambia de forma importante. El acceso puede ser más rápido y seguro, pero el registro inicial necesita acompañamiento. Si los usuarios reciben una solicitud inesperada y no entienden qué están creando o dónde quedará almacenada la credencial, aumentarán las consultas al equipo de soporte.

Un escenario frecuente es que la tecnología funcione correctamente durante las pruebas, pero la adopción encuentre fricción por una comunicación insuficiente. Por eso, el despliegue debe contemplar tanto la validación técnica como la preparación operativa:

• Comunicación previa.
• Instrucciones sencillas.
• Canales de soporte.
• Procedimientos de recuperación.
• Tratamiento de cambios o pérdidas de dispositivo.

Artículos recomendados:

• Backup en Microsoft 365: por qué es clave, qué cubre Veeam y cómo Aitana puede ayudarte
• Impacto económico de implantar Microsoft Defender
• Windows Hello for Business y Passwordless: cómo implementarlo en entornos corporativos (con casos reales)

Enfoque de adopción y piloto controlado

La transición hacia passkeys debe plantearse como un proceso gradual. En Aitana proponemos un enfoque dividido en fases.

Fase 1 – Evaluación del estado actual

• Revisión de la política moderna y las configuraciones heredadas.
• Análisis del estado de migración.
• Identificación de métodos registrados y utilizados.
• Detección de dependencias de SMS, voz, Authenticator, OATH y SSPR.
• Revisión de las condiciones necesarias para ejecutar el piloto.

El resultado de esta fase es una visión clara del punto de partida y de los riesgos que deben resolverse antes de avanzar.

Fase 2 – Diseño del escenario objetivo

• Definición de los métodos que deben permanecer operativos.
• Segmentación por perfiles de usuario.
• Tratamiento de las necesidades de MFA y recuperación.
• Identificación de excepciones justificadas.
• Definición de los criterios de validación y reversión.

La política final no debería ser una copia automática de la configuración heredada, sino una decisión de seguridad adaptada a la organización.

Fase 3 – Normalización de la configuración

• Alineación de la política moderna con el escenario aprobado.
• Revisión de ámbitos, exclusiones y dependencias.
• Validación de la continuidad de los métodos necesarios.
• Preparación del entorno para probar passkeys sin afectar al resto de usuarios.

Esta fase permite reducir incoherencias antes de introducir la nueva experiencia.

Fase 4 – Piloto controlado de passkeys

• Selección de un usuario del equipo IT o de un grupo muy limitado.
• Registro de una passkey en un dispositivo compatible.
• Validación del acceso.
• Comprobación de que los métodos alternativos siguen disponibles.
• Revisión de los eventos de autenticación.
• Prueba opcional en un segundo tipo de dispositivo.

El objetivo del piloto no es demostrar únicamente que la credencial puede crearse. Debe confirmar que funciona dentro del contexto real del cliente y sin perjudicar los mecanismos existentes.

Fase 5 – Adopción progresiva

Una vez validado el piloto, la organización puede decidir cómo extender el modelo:

• Incorporación por departamentos o perfiles.
• Priorización de usuarios con mayor exposición.
• Adaptación del soporte.
• Comunicación y formación.
• Seguimiento del registro y uso.
• Revisión periódica de excepciones.

Este enfoque permite avanzar hacia métodos resistentes al phishing sin convertir el cambio en un despliegue global difícil de controlar.

Riesgos habituales y cómo mitigarlos

La transición hacia passkeys implica riesgos técnicos y operativos que deben tratarse desde el inicio.

La principal lección es clara: no se deben aplicar cambios globales basándose únicamente en lo que muestra una política. Es necesario comprobar cómo se autentican y recuperan el acceso los usuarios en la práctica.

Beneficios y encaje en una estrategia Zero Trust

La adopción de passkeys aporta beneficios que van más allá de responder al calendario de Microsoft.

Seguridad:

• Mayor resistencia frente al phishing.
• Menor exposición de contraseñas y códigos.
• Reducción del riesgo asociado a SMS y llamadas.
• Autenticación vinculada al usuario, servicio y dispositivo.

Operativa:

• Menos dependencia de contraseñas.
• Accesos más sencillos para los usuarios preparados.
• Mayor visibilidad sobre los métodos utilizados.
• Procesos de soporte y recuperación mejor definidos.

Estrategia:

• Modernización de Microsoft Entra ID.
• Consolidación de la política de autenticación.
• Base para aplicar controles diferenciados según el riesgo.
• Evolución progresiva hacia un modelo Passwordless y Zero Trust.

Las passkeys no deben considerarse una funcionalidad aislada. Forman parte de una arquitectura en la que cada acceso se protege mediante una identidad verificada, una credencial resistente al phishing y unas políticas adaptadas al contexto.

La retirada de la prestación de SMS y voz de Microsoft introduce una fecha límite, pero también ofrece una oportunidad para revisar configuraciones que se han acumulado durante años y avanzar hacia un modelo de identidad más coherente.

En Aitana ayudamos a las organizaciones a evaluar su tenant, normalizar los métodos de autenticación y validar las passkeys mediante un piloto controlado antes de abordar una adopción más amplia.

¿No tienes claro cuántos usuarios dependen todavía de SMS o llamada? ¿Tu tenant continúa utilizando políticas heredadas? ¿Quieres probar las passkeys sin afectar al resto de la organización? Rellena el formulario y nuestro equipo de expertos en ciberseguridad se pondrá en contacto contigo para analizar tu escenario y definir los siguientes pasos.

Roberto González
Operaciones MSI