El teléfono de la ficha era una credencial: Entra ID deja de aceptarlo

Piensa en el campo «teléfono móvil» de la ficha de un empleado cualquiera de tu directorio. ¿Quién lo escribió? En la mayoría de empresas que conocemos ese número no lo puso el usuario: llegó de una sincronización desde el Active Directory de casa, o de alguien que estaba dando de alta a una persona un martes por la mañana. Y hasta ahora, con ese campo relleno, esa persona podía restablecer su contraseña en el portal de autoservicio. Microsoft va a dejar de aceptarlo.

Qué cambia exactamente

El autoservicio de restablecimiento de contraseña de Microsoft Entra ID —SSPR, por sus siglas en inglés— pasará a exigir métodos de autenticación registrados explícitamente para verificar a quien pide el cambio. Los datos de contacto que viven en los atributos del directorio dejarán de valer si el usuario no los ha registrado como método. La documentación nombra los tres: mobilePhone, businessPhone y otherMails. El aviso del centro de mensajes que lo describe es el MC1325414 y afecta a todos los inquilinos con SSPR activado, en la nube pública y en las nubes de gobierno de Estados Unidos.

La razón que da Microsoft es que la verificación pase a basarse en «métodos de confianza validados por el usuario, en lugar de en atributos procedentes del directorio». Es una frase de nota de producto, pero describe con precisión lo que había antes.

Quién escribe ese campo

Lo interesante es que esto no era un descuido tapado: está documentado como funcionalidad, con página propia en Microsoft Learn y con un título que lo dice todo, «Rellenar previamente la información de contacto de autenticación». Dos frases de esa página, literales:

«Estos datos sincronizados se ponen a disposición de Microsoft Entra ID y de SSPR sin requerir interacción del usuario. Cuando los usuarios necesiten cambiar o restablecer su contraseña, podrán hacerlo aunque no hayan registrado previamente su información de contacto.»

«Si proporcionaste un valor para Teléfono móvil o Correo alternativo, los usuarios pueden usar esos valores de inmediato para restablecer sus contraseñas, aunque no se hayan registrado en el servicio.»

La misma página trae la tabla de correspondencias del conector de sincronización: telephoneNumber del Active Directory local pasa a ser Teléfono de oficina, y mobile pasa a ser Teléfono móvil. Con eso ya está el circuito completo. Un valor escrito en un objeto del dominio de casa sube por la sincronización y, al otro lado, sirve para demostrar identidad en el portal de recuperación sin que su titular haya hecho nada.

La diferencia con un método registrado está en quién lo escribe. Un método registrado lo da de alta el propio usuario desde su página de información de seguridad, demostrando que controla ese teléfono o ese buzón; también puede ponerlo por él un administrador con el rol de Administrador de autenticación con privilegios, que es una lista corta y auditable. Un atributo de contacto lo escribe cualquiera con permiso de escritura sobre el objeto, y esa lista no la ha revisado nadie desde que se creó.

Puesto así, tener permiso de escritura sobre los datos de contacto de un usuario ha equivalido, en la práctica, a poder recuperar su cuenta. Con la política de SSPR exigiendo dos métodos hacen falta dos campos, móvil y correo alternativo, cosa que una delegación sobre el objeto normalmente sí concede. Ese permiso no aparece en ninguna matriz de roles, no lo revisa ninguna auditoría de accesos privilegiados y no dispara ninguna alerta cuando cambia. Nadie lo concedió a propósito: se coló por la puerta de atrás de una funcionalidad pensada para que la gente no llame al soporte el primer día.

La pregunta que sale de aquí se responde en una tarde y no depende de Microsoft: ¿quién puede escribir hoy en los datos de contacto de un usuario cualquiera de tu directorio? Haz la lista de verdad, con nombres. Si aparece gente de administración, o un proceso automatizado que nadie mantiene, ya sabes por dónde se recuperan cuentas en tu empresa. Sobre lo que se acumula en un directorio cuando nadie lo mira escribimos hace unas semanas, contando por qué hay más fichas que empleados.

El caso híbrido, que es el que más duele

Si sincronizas desde un Active Directory local, ese número no nace en Entra. Nace en un objeto del dominio de casa, y el permiso de escritura sobre los atributos de contacto de una unidad organizativa es exactamente el tipo de delegación que se hizo hace diez o quince años para que administración pudiera actualizar números de contacto sin molestar a sistemas. No hay nada malintencionado en ello. Simplemente, la cadena completa —quién escribe en el AD local, qué sube por la sincronización, qué acepta el portal de recuperación— nunca se dibujó entera en una sola pizarra.

Es la misma idea que defendimos al explicar que tu proveedor de identidad no es una aplicación más: si el directorio decide quién entra en todo, los permisos sobre el directorio pesan más que los permisos sobre cualquier aplicación de las que cuelgan de él. Un campo de texto incluido.

El 86 %: mira el denominador

La cifra que acompaña a este cambio y que tranquiliza a todo el mundo es esta: aproximadamente el 86 % de las verificaciones de SSPR ya usan métodos registrados. El sustantivo importa. Son verificaciones, no usuarios.

Una verificación la genera alguien que usa el sistema. Piensa en la persona que entró en 2019, se sabe su contraseña de memoria y no ha pisado nunca el portal de recuperación: no aporta ni una verificación a esa estadística, ni para bien ni para mal. Es invisible en el numerador y en el denominador. Y es exactamente quien se encontrará la puerta cerrada el día que la necesite, probablemente después de unas vacaciones o de una baja larga, que es cuando a la gente se le olvida la contraseña. El 86 % describe cómo le va al que ya usa el sistema. No dice nada del que nunca lo ha usado.

La medida útil es una lista de cuentas, no un porcentaje. Se saca del informe de detalles de registro de usuario del centro de administración de Entra, en Métodos de autenticación → Supervisión, filtrando por usuarios capaces de SSPR; o por línea de órdenes, que es más cómodo de repetir cada semana:

Get-MgReportAuthenticationMethodUserRegistrationDetail -All ``
  -Filter "isSsprEnabled eq true and isSsprRegistered eq false" ``
  | Select-Object UserPrincipalName, UserDisplayName

Una advertencia sobre ese informe, porque va justo en la dirección del problema: no hemos encontrado documentado si isSsprRegistered distingue un método registrado por el usuario de un valor heredado del directorio. Si no lo distingue, el informe arrastra el mismo sesgo que el 86 % y deja fuera a la gente que corre peligro. Contrástalo en una muestra pequeña mirando los atributos en crudo, que es media docena de comandos:

Get-MgUser -UserId '[email protected]' ``
  | Select businessPhones, mobilePhone, otherMails | Format-Table

Cuatro fechas para un mismo corte

Si has leído algo sobre esto en los últimos meses, probablemente lleves apuntado el 7 de septiembre de 2026. Esa era la fecha de la primera versión del aviso, publicado el 28 de mayo. El MC1325414 se actualizó el 4 de agosto y el calendario se movió entero. Pero al recopilar las fechas nos encontramos con que no hay una, hay cuatro, y no cuadran entre sí:

La última fila es la que importa, y no es un matiz. Microsoft Learn tiene las dos fechas invertidas respecto al centro de mensajes: dice que el 5 de octubre «SSPR solo aceptará métodos de autenticación registrados explícitamente» y que la campaña de registro arranca el 9 de noviembre. O sea, la campaña que sirve para preparar a la gente llegaría un mes después del corte. Una de las dos páginas está mal, y desde fuera no se puede saber cuál.

La conclusión práctica es corta: planifica como si el 5 de octubre fuera la fecha de corte, porque es la primera fecha en la que una página oficial de Microsoft dice que esto deja de funcionar. Y confirma en tu propio centro de mensajes, que es donde está la versión que aplica a tu inquilino. Nosotros leemos el MC1325414 en archivos públicos que recopilan esos avisos, no en un tenant real.

Esto no viene solo

El cambio de SSPR es una pieza de un movimiento más grande y los plazos se solapan. Desde el 1 de septiembre de 2026, hace cinco días, los usuarios habilitados para SMS o voz se autohabilitan para claves de acceso y entran en una campaña de registro gestionada por Microsoft que les insiste al completar el segundo factor. Y a partir del 1 de febrero de 2027 se retira la entrega de SMS y voz proporcionada por Microsoft: quien la necesite tendrá que contratar un proveedor de telecomunicaciones propio a través de la tienda de seguridad de Microsoft. La documentación no deja margen: «No hay exclusión voluntaria de este comportamiento del 1 de febrero. Se aplicará a todos los inquilinos». Hay una exclusión temporal, sí, pero solo cubre el tramo de septiembre a febrero.

Sobre el arranque de septiembre y los casos que no encajan en el guion feliz ya escribimos con detalle hace unos días. Y si tu plan pasa por apoyarte en un doble factor de terceros, conviene leer antes por qué hay un MFA que Entra no cuenta como MFA. La lección se parece a la de hoy: lo que vale es lo que el directorio reconoce como método, no lo que tú sabes que el usuario tiene.

Lo que haríamos, en orden

• Sacar la lista de cuentas habilitadas para SSPR sin métodos registrados. Con nombre y apellidos, y repetirla cada lunes hasta que baje a cero.
• Auditar quién escribe en los atributos de contacto. En Entra y, si eres híbrido, en el AD local. Hasta el corte, esa lista es tu lista real de gente capaz de recuperar cuentas ajenas. Después del corte pasa a ser otra, mucho más corta: la de quien tiene rol de administrador de autenticación con privilegios. Merece la pena mirar las dos, porque cambia de manos un privilegio.
• No esperar a la campaña de Microsoft. Lanzar la tuya antes del 5 de octubre, con tu texto y tu tono, reparte la carga en semanas en vez de concentrarla en el día en que el sistema empiece a insistir por su cuenta. Y si Learn tiene razón con las fechas, la campaña de Microsoft llegaría tarde.
• Definir el camino de respaldo humano. Quien no pueda registrarse ni restablecer acabará llamando, y ahí el que verifica identidad es una persona con prisa. Escribe cómo se verifica a quien llama antes de que haga falta, porque ese pasa a ser tu camino de recuperación de verdad y es el más fácil de engañar.
• Ensayarlo con una cuenta de verdad, cronómetro en mano.

El último punto es el que se salta todo el mundo y el único que descubre algo. En infraestructura lo decimos así desde hace años: un backup sin probar no es un backup, es un amuleto. La recuperación de identidad se comporta igual, y le dedicamos un post entero al plan de continuidad que nadie ha ensayado, porque el patrón se repite en todas partes. Lo que solo se prueba el día del incidente es justo lo que no puedes permitirte que falle ese día.

Cuándo esto no va contigo

Si tienes veinte personas, todas con Authenticator registrado y el móvil en la mano, este cambio te va a pasar por encima sin que te enteres, y está bien que así sea. No hace falta montar un proyecto. Pero el problema de fondo tiene una versión doméstica que aplica a cualquiera: mira la dirección de correo de recuperación de la cuenta de tu registrador de dominios, o del panel de tu proveedor de nube. En más casos de los que parece apunta al buzón de alguien que ya no trabaja aquí, o a una lista de distribución que lee media empresa. Ahí el dato de recuperación tampoco lo controla el titular de la cuenta, y no hay ningún Microsoft que vaya a arreglarlo por ti.

Nos quedamos con dos preguntas para un empleado cualquiera de tu directorio. Qué campo suyo, escrito por quién, podría hoy devolverle el acceso a su cuenta. Y qué pasa cuando ese campo deje de valer y él no haya registrado nada.

Fuentes: las dos frases citadas sobre el uso de datos sincronizados sin registro previo, la tabla de correspondencias telephoneNumber/mobile, el rol de Administrador de autenticación con privilegios, los comandos de lectura de atributos y las fechas del 5 de octubre y el 9 de noviembre proceden de «Rellenar previamente la información de contacto de autenticación del usuario para SSPR», Microsoft Learn. El identificador MC1325414, la fecha de publicación (28 de mayo de 2026), la de actualización (4 de agosto de 2026), el alcance y las fechas del centro de mensajes —título el 9 de noviembre, cronología con campaña el 5 de octubre y aplicación el 7 de noviembre, campo «actuar antes de» el 6 de noviembre— salen del archivo público del centro de mensajes de Microsoft 365. Las fechas de la primera versión (campaña el 6 de julio, aplicación el 7 de septiembre) y la frase de Microsoft sobre «métodos de confianza validados por el usuario», de la cobertura de Petri. La cifra del 86 % de las verificaciones y el Get-MgReportAuthenticationMethodUserRegistrationDetail, de Tony Redmond en Office 365 for IT Pros, 17 de junio de 2026. Las fechas de claves de acceso y de la retirada de SMS y voz, y la frase sobre la ausencia de exclusión voluntaria, de Microsoft Learn, actualizado el 10 de agosto de 2026. Lo que no afirmamos: no hemos leído el MC1325414 en un inquilino real, sino en archivos públicos que recopilan los mensajes, así que las fechas debes confirmarlas en tu propio centro de mensajes; no sabemos cuál de las dos páginas de Microsoft tiene bien las fechas, solo que se contradicen; no sabemos si el informe de registro distingue un método registrado de un atributo heredado, y lo decimos donde toca; no sabemos cuántas empresas españolas tienen usuarios sin métodos registrados, porque nadie publica ese dato; y no describimos ningún abuso real de este camino, porque no tenemos ninguno documentado que citar.