Passkeys el 1 de septiembre: los casos que no encajan

El 25 de julio publicamos aquí el calendario de la retirada del SMS y la voz en Entra ID, cuando el anuncio tenía doce días. Cinco días después de aquel post Microsoft publicó una FAQ que en aquel momento no existía, y pasado mañana llega la primera de las dos fechas. Así que este no es el mismo artículo otra vez: es lo que sigue sin resolverse a cuarenta y ocho horas del 1 de septiembre, y son casi todo casos raros.

Conflicto de interés por delante: administramos inquilinos de Microsoft 365 de clientes y vendemos puesto de trabajo gestionado, así que nos gana dinero que esto te preocupe. Por eso todo lo que sigue lleva pegada la fuente, y la fuente es la documentación pública de Microsoft. Contrástalo tú.

Qué pasa pasado mañana, en una frase

No se cae ninguna sesión. Lo que cambia el 1 de septiembre es la configuración de tu inquilino: los usuarios habilitados para SMS o voz en la Authentication Methods Policy —o en la configuración heredada de MFA— quedan auto-habilitados para passkeys, en un perfil que admite todos los tipos, y tu campaña de registro pasa a estado «Microsoft Managed» apuntando a passkeys, con esos usuarios ya dentro del alcance. La próxima vez que hagan MFA les sale el aviso, y por defecto pueden posponerlo indefinidamente.

La campaña de registro es una política tuya: la administras desde Entra ID > Authentication methods > Registration campaign. La documentación deja la única salida admitida escrita en una frase seca: «si no quieres que esto ocurra, saca a los usuarios de SMS o voz en la AMP antes del 1 de septiembre». Es decir, la forma de que el proveedor no te toque la política es hacer tú, en cuarenta y ocho horas, aquello mismo hacia lo que la política empuja. Se entiende el diseño, y sigue sin gustarnos el mecanismo.

La tabla de hitos del artículo tiene tres filas, no dos: el 1 de septiembre, el 1 de febrero de 2027 —cuando se retira la entrega de SMS y voz que da Microsoft— y una tercera que describe qué pasa después de esa fecha. Cinco meses entre la primera y la segunda. Eso es todo el margen que hay, y empieza pasado mañana.

La salida por operador propio tiene sus propias fechas

Conviene repetir el matiz que el titular se come, porque decide lo que tienes que hacer: lo que se retira es el SMS que entrega Microsoft. El título de la propia página lleva el adjetivo delante, Microsoft-provided, y la FAQ confirma que los inquilinos que configuren un operador propio «pueden seguir usando SMS o voz según las políticas de su organización».

Lo que cambia respecto a julio son las condiciones, que ya están fechadas. La información sobre los operadores no se publica hasta el 18 de septiembre de 2026, y la posibilidad de seleccionar y configurar uno no llega hasta el 30 de octubre de 2026. La FAQ es honesta y vaga a la vez sobre el precio: sí hay coste, varía por proveedor y región, y es típicamente por mensaje según volumen y distribución geográfica. Migrar a passkeys, dice, no cuesta nada adicional.

Nuestra lectura, marcada como lectura y no como hecho publicado: esto no es una alternativa cómoda, es una salida de emergencia estrecha. Se te pide decidir ahora sobre una opción cuyo precio no conocerás hasta dentro de tres semanas y que no podrás contratar hasta finales de octubre, con la puerta cerrándose el 1 de febrero. Si tu plan es «ya contrataré un operador», entre el día que se abre la contratación y el corte quedan poco más de tres meses para elegir proveedor, firmar y pilotar.

El «No» de la FAQ, y lo que dice tres líneas más abajo

La FAQ trae una pregunta que se titula, literalmente, «¿Se van a quedar los clientes bloqueados fuera de sus cuentas el 1 de febrero de 2027?». La respuesta empieza con un «No» y sigue así: recibirán un aviso bloqueante de registro, ya no podrán saltárselo y tendrán que completar el registro de la passkey antes de poder seguir entrando. El artículo principal lo repite con las mismas palabras y añade, en negrita y tres veces a lo largo de la página, que para ese comportamiento no hay exclusión posible y que se aplica a todos los inquilinos.

Técnicamente el «No» es correcto: la cuenta no se cierra. Pero para el usuario la distinción entre «cuenta bloqueada» y «no pasas hasta que hagas una cosa» solo existe si esa cosa la puede hacer donde está y con lo que lleva encima. El comercial en el aeropuerto, el operario del almacén con un móvil de empresa sin biometría configurada, la persona de administración que entra desde un equipo compartido: para esos tres, el 1 de febrero un «No» de la FAQ vale exactamente lo mismo que un sí.

Dónde cae el trabajo: el restablecimiento de contraseña

La retirada no es solo del segundo factor. La FAQ lo contesta en una línea: la retirada del SMS y la voz nativos «aplica a todo Entra, incluido el restablecimiento de contraseña de autoservicio». Y añade la puerta de atrás en la frase siguiente, que conviene no cortar: los usuarios sí pueden seguir usando SMS y voz si contratas operador propio en el Security Store. Sin operador propio, el SSPR por SMS se va con todo lo demás.

Es una cadena corta y bastante fea. Quien olvidaba su contraseña y la recuperaba solo con un código por SMS deja de poder. Ese usuario no llama a seguridad: llama a quien coge el teléfono, un lunes por la mañana, a la vez que otros veinte. Y la propia FAQ reconoce que la pieza que cerraría ese hueco todavía no existe: Microsoft dice que planea introducir soporte para que cambien la contraseña los usuarios que entran sin contraseña, y remata con un «más detalles próximamente». Cuando la documentación de un proveedor dice eso a cinco meses del corte, no es una función: es una intención.

Quién no está en esto, y el hueco de los invitados

Toca decir también a quién no afecta, porque hay bastante gente asustada sin motivo. El calendario vale solo para la nube pública; los demás entornos irán después y Microsoft dice que avisará con antelación. Azure AD B2C queda fuera y no le afecta. Microsoft Entra External ID tiene su propio anuncio el año que viene. Y los métodos de MFA externos no entran, salvo que además el usuario esté habilitado para SMS o voz.

Y luego están los invitados, que en la FAQ ocupan dos frases seguidas que conviene leer juntas. Una: el soporte de passkeys para usuarios B2B e invitados internos «está previsto que esté disponible para finales del año natural 2026». Dos, inmediatamente después: «estos usuarios están incluidos en el alcance de la retirada». El sustituto está previsto para diciembre y la puerta se cierra en febrero. Si tu negocio vive de colaborar con externos —asesorías, ingenierías, cualquiera con una carpeta compartida con proveedores— esa es la casilla que miraríamos primero, y esta semana. Va en la línea de lo que contábamos sobre el directorio con más fichas que empleados: el problema casi nunca son tus empleados, son los que no lo son.

Lo único urgente esta semana es un número

Todo lo anterior es opinión hasta que sepas cuántos usuarios de tu inquilino siguen habilitados para SMS o voz. Con ese número delante, la decisión se toma sola: si son cuatro, esto es una tarde; si son ciento cuarenta, es un proyecto con comunicación a usuarios y ventana de soporte reforzado.

Microsoft publica un script para sacarlo, el entra-sms-voice-usage-analyzer, en su organización de GitHub. Pide tener activo uno de estos tres roles: lector global, administrador de directivas de autenticación o lector de seguridad. La FAQ resume el criterio de alcance en una línea que va muy bien para un correo interno: cualquier resultado distinto de cero significa que estás dentro.

El interruptor de salida existe, vive en /beta, y no te lo recomendamos

Hay una exclusión temporal para el tramo del 1 de septiembre al 1 de febrero. No está en el portal: se aplica con una llamada a Microsoft Graph, con el permiso Policy.ReadWrite.AuthenticationMethod, poniendo la propiedad passkeyDynamicMigration a true dentro de optOutSettings en la directiva de métodos de autenticación. El endpoint que documenta Microsoft para esa llamada es /beta.

Dos cosas sobre eso. La primera es de oficio: escribir en /beta significa que la forma de esa llamada puede cambiar sin que nadie te avise, así que si la aplicas, apúntala con fecha y con dueño y ponte un recordatorio para revisarla en enero. La segunda es criterio nuestro: úsalo solo en dos casos. Uno, que ya tengas decidido con fecha que vas a contratar operador propio y solo necesites llegar al 30 de octubre. Dos, que el 1 de septiembre te pille en mitad de otra migración y no puedas meter ruido en el inicio de sesión. Fuera de ahí te compra cinco meses que no vas a usar, y el 1 de febrero llega igual, con la diferencia de que entonces el aviso ya no se puede posponer.

Lo que la documentación no dice y sí decide tu lunes

Hemos leído las dos páginas enteras y hay una cosa que no aparece en ninguna: las cuentas de emergencia. Ese par de cuentas de administrador global que casi todo el mundo tiene apartadas para el día que se cae el acceso condicional o el proveedor de identidad. Si alguna de ellas tiene como segundo factor un SMS a un número de empresa, esa es la primera que hay que mover, y lo decimos como criterio propio y no como cita: no queremos descubrir en febrero que la cuenta reservada para cuando nada funciona depende justo de lo que se acaba de retirar. Es la misma idea que ya escribimos sobre tratar el proveedor de identidad como infraestructura y no como una aplicación más.

La otra pieza que no está en la tabla de fechas es el inventario de quién puede registrar una passkey y quién no. Microsoft admite dos familias: las sincronizadas, que viven en un gestor de credenciales de plataforma como iCloud Keychain o Google Password Manager y viajan entre los dispositivos del usuario, y las ligadas a un dispositivo, que incluyen la passkey del propio Authenticator, Entra Passkey en Windows y las llaves FIDO2 físicas. Esa distinción decide si el usuario del taller necesita una llave de hardware o le vale el móvil que ya lleva, y también dónde acaba viviendo la credencial: si te interesa esa segunda parte, la contamos en su día al mirar de qué está hecha una passkey sincronizada. Ese inventario no te lo va a hacer ningún script.

Dónde estamos nosotros

En el fondo del asunto estamos de acuerdo con Microsoft. Su argumento es que el SMS y la voz se encuentran «entre los métodos de autenticación más vulnerables disponibles hoy» y protegen bastante peor que una passkey frente al phishing y al robo de cuentas; el nuestro es más terrenal y viene de arreglar incidentes: un código que viaja a un número de teléfono se puede pedir por otro camino, y el segundo factor que se puede pedir por otro camino no es un segundo factor, es un trámite. Ya lo vimos con el token que nunca vuelve a pedir MFA: lo que rompe una cuenta casi nunca es la contraseña.

Lo que no nos convence es la coreografía. Una fecha en la que el proveedor te cambia una política del inquilino, una alternativa cuyo precio se publica diecisiete días después de esa fecha, una contratación que no abre hasta el 30 de octubre, un hueco declarado en los invitados y un corte duro sin exclusión posible. Todo eso es defendible por separado y bastante incómodo junto, sobre todo para una empresa de treinta personas sin nadie dedicado a identidad a tiempo completo. Es la asimetría de siempre: el calendario lo pone quien no va a atender las llamadas del lunes.

Si solo te llevas una cosa de todo esto: saca el número esta semana. Es lo único que no puede esperar, y es también lo único que convierte esta conversación en un plan.

Fuentes (consultadas el 30 de agosto de 2026): todas las fechas, comportamientos, propiedades y frases entrecomilladas salen de dos páginas de la documentación oficial de Microsoft: Passkeys by default and retirement of Microsoft-provided SMS and voice authentication (Microsoft Learn, actualizada el 10 de agosto de 2026) y su FAQ (fechada el 30 de julio y actualizada el 3 de agosto de 2026, o sea publicada después de nuestro post del 25 de julio). En concreto, del artículo principal: la tabla de hitos con sus tres filas —1 de septiembre de 2026, 1 de febrero de 2027 y el comportamiento posterior a esa fecha—, el aviso bloqueante y las tres menciones en negrita a que no hay exclusión posible; la auto-habilitación en la AMP, el perfil con todos los tipos de passkey, el paso de la campaña de registro a «Microsoft Managed», los aplazamientos ilimitados y la frase sobre sacar a los usuarios de SMS o voz antes del 1 de septiembre, en el recuadro «Important»; la ruta Entra ID > Authentication methods > Registration campaign, en el paso 2; el 18 de septiembre de 2026 para la publicación de la información de operadores y el 30 de octubre de 2026 para poder seleccionarlos y configurarlos, en el paso 3; el opt-out temporal con passkeyDynamicMigration, el permiso Policy.ReadWrite.AuthenticationMethod y el endpoint /beta, en la sección de exclusión temporal; el script entra-sms-voice-usage-analyzer con sus tres roles, en el paso 1; y la descripción de las dos familias de passkeys. De la FAQ: la cita «entre los métodos de autenticación más vulnerables disponibles hoy»; el coste por mensaje del operador propio y que migrar a passkeys no añade coste; el alcance a todo Entra incluido SSPR, junto con la frase inmediatamente posterior según la cual los usuarios sí pueden seguir usando SMS y voz mediante un operador contratado en el Security Store; el «más detalles próximamente» sobre el cambio de contraseña sin contraseña; el alcance solo a nube pública; la exclusión de Azure AD B2C y el anuncio separado de External ID; el soporte de passkeys para B2B previsto para finales de 2026 junto con que esos usuarios sí están en el alcance de la retirada; que los métodos de MFA externos no entran salvo que el usuario también esté en SMS o voz; el criterio de que cualquier resultado distinto de cero significa estar en alcance; y la pregunta sobre bloqueo de cuentas con su respuesta «No». Son nuestras, y las marcamos como criterio y no como hechos publicados: que la salida por operador propio es estrecha por el orden de sus propias fechas; que el coste real de esto cae en el servicio de soporte por la vía del SSPR; que el hueco de los invitados es la casilla a mirar primero si trabajas con externos; la recomendación de no usar el opt-out salvo en los dos casos citados; la advertencia sobre escribir en un endpoint /beta; y el aviso sobre las cuentas de emergencia, que la documentación no menciona en ninguna de las dos páginas.