Entra ID SSPR fallos de seguridad: de qué se trata
El restablecimiento de contraseña de autoservicio (SSPR) en Microsoft Entra ID se supone que cierra el ciclo de recuperación de cuenta que la autenticación multifactor abre por otro lado en el tenant (ver también por qué el MFA solo no es suficiente). En la práctica, los mismos tres entra id sspr fallos de seguridad aparecen una y otra vez en tenants reales: SSPR dejado desactivado para todo el tenant, administradores excluidos de una política que en realidad exige verificación fuerte, y métodos de restablecimiento débiles — preguntas de seguridad o SMS — aceptados como prueba de identidad suficiente por sí solos.
SSPR permite a los usuarios recuperar el acceso a una cuenta bloqueada sin abrir un ticket al helpdesk, verificando su identidad mediante uno o más métodos registrados (app Authenticator, correo electrónico, teléfono, o preguntas de seguridad) en passwordreset.microsoftonline.com. Activarlo requiere al menos una licencia Microsoft Entra ID P1 y el rol Authentication Policy Administrator, y su alcance puede definirse como None, un solo grupo (opcionalmente anidado), o All (todos los usuarios), según el tutorial de activación de Microsoft.
La mayoría de los despliegues se detienen ahí, presentados únicamente como un ahorro de costes — menos llamadas al helpdesk, restablecimiento más rápido para los usuarios finales, una línea más en una hoja de licencias. Ese enfoque es lo que permite que las tres siguientes fallas pasen desapercibidas:
- SSPR completamente desactivado (
SSPR_NOT_ENABLED) — no existe ningún camino de autoservicio, así que cada restablecimiento pasa por un humano. - Administradores no cubiertos por una política de restablecimiento que realmente exija verificación fuerte (
SSPR_NOT_REQUIRED_ADMINS) — las cuentas privilegiadas caen en el mismo camino manual, explotable mediante ingeniería social. - Métodos débiles aceptados como prueba de identidad suficiente (
SSPR_METHODS_WEAK) — preguntas de seguridad o llamadas SMS/voz que satisfacen por sí solas la política de restablecimiento.
Ninguna de estas es una mala configuración exótica. Son estados cercanos al valor por defecto en los que un tenant deriva simplemente por no revisar nunca SSPR después de la configuración inicial — lo que también explica por qué rara vez se detectan en una revisión rutinaria: un test de intrusión o una auditoría de MFA suele comprobar si el inicio de sesión exige un segundo factor, no si el camino de recuperación de esa misma cuenta es igual de sólido. Un atacante no necesita vencer el MFA en la puerta principal si la puerta trasera — la recuperación de contraseña — solo necesita una pregunta de seguridad adivinada o una llamada telefónica convincente.
Las tres fallas de seguridad SSPR, una por una
Falla 1 — SSPR completamente desactivado
Cuando el alcance de SSPR es None, cada restablecimiento de contraseña tiene que pasar por TI o el helpdesk. Ese camino manual es exactamente el vector descrito en el aviso de CISA sobre Scattered Spider (AA23-320A): los actores de amenazas llaman o envían SMS al personal del helpdesk haciéndose pasar por un empleado, solicitando un restablecimiento de contraseña o un cambio de dispositivo MFA como su vector de acceso inicial. Un tenant con SSPR desactivado no ha eliminado el camino de restablecimiento — ha forzado el 100 % de los restablecimientos a pasar exactamente por el canal que esa técnica ataca, sin darle al helpdesk una línea base de autoservicio con la que comparar una solicitud inusual.
Falla 2 — Admins no obligados a usar SSPR
Por defecto, Microsoft Entra trata las cuentas de administrador de forma diferente: están cubiertas por una política de dos puertas integrada y no modificable que exige dos elementos de autenticación, distinta de la política (a menudo de una sola puerta) aplicada a los usuarios normales, según la documentación de Microsoft sobre la política SSPR. Los tenants que desactivan la política de restablecimiento admin — sin excluir explícitamente a los admins de la política orientada al usuario — dejan que las cuentas privilegiadas se restablezcan de la misma forma que en la Falla 1: manualmente, a través del helpdesk. Esta es la cuenta de mayor valor a proteger de ese camino, ya que un restablecimiento logrado mediante ingeniería social sobre un Global Administrator es un compromiso total del tenant, no solo de un buzón.
Falla 3 — Métodos de restablecimiento débiles aceptados
Las preguntas de seguridad pueden responderlas quien haya hecho un reconocimiento ligero sobre un objetivo, y Microsoft las está retirando por completo de SSPR para marzo de 2027 por esa misma razón — la propia documentación de Microsoft las señala como "menos seguras que otros métodos" y recomienda combinarlas con un segundo método si se usan. Los métodos de teléfono móvil (SMS/llamada de voz) conllevan su propio riesgo bien conocido de interceptación y SIM-swap — las directrices de identidad digital del NIST clasifican los códigos entregados por red telefónica como un autenticador restringido por esa misma razón, indicando a los verificadores que comprueben cambios de SIM y portabilidad numérica antes de confiar en ellos, según NIST SP 800-63B. Una política de restablecimiento que acepta cualquiera de estos como única puerta suficiente es funcionalmente tan débil como no tener política alguna — la cuenta está a una respuesta adivinada o un SMS interceptado de la toma de control.
⚠️ Advertencia: una configuración SSPR desactivada, no registrada, o débil no elimina el camino de restablecimiento de su tenant — simplemente lo mueve al canal que quede, y ese canal suele ser el que tiene menos verificación: un humano al teléfono.
Detección
Si está realizando una revisión de seguridad de Entra ID más amplia, la postura de SSPR pertenece al mismo repaso que Conditional Access y PIM — se verifica con los mismos permisos de Graph y la misma sesión del admin center.
| Señal | Dónde mirar | Qué indica |
|---|---|---|
allowedToUseSSPR | Microsoft Graph GET /policies/authorizationPolicy (referencia del recurso) | Si los administradores tienen permitido usar SSPR bajo la política de restablecimiento admin del tenant |
Alcance de activación de SSPR (None / grupo / All) | Admin center de Entra → Protection → Password reset → Properties, o Graph authenticationMethodsPolicy | Confirma que SSPR no está silenciosamente limitado a None o a un grupo piloto obsoleto |
isSsprRegistered, isSsprEnabled | Graph GET /reports/authenticationMethods/userRegistrationDetails (resumen de insights de uso) | Qué usuarios — incluidos los admins — están habilitados para SSPR pero no han registrado un método conforme |
| Lista de métodos permitidos por la política SSPR | Admin center de Entra → Authentication methods → Password reset properties | Si Security questions o Mobile phone por sí solos pueden satisfacer la puerta de restablecimiento |
| Registro de auditoría, Servicio = Self-service Password Management, Actividad = Self-service password reset policy changes | Admin center de Entra → Users → Audit Logs (referencia de reporting) | Quién debilitó la política SSPR (alcance, número de métodos, métodos permitidos) y cuándo |
| Registro de auditoría, Actividad = Reset password (by admin), alta frecuencia | Mismo registro de auditoría, filtrado por Actividad | Usuarios — especialmente admins — que caen habitualmente en restablecimientos manuales en lugar de autoservicio, señal de que SSPR no es utilizable para ellos |
Consultar directamente la cobertura de registro
Connect-MgGraph -Scopes "Reports.Read.All", "Policy.Read.All"
# Postura SSPR de los admins
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy" |
Select-Object -ExpandProperty allowedToUseSSPR
# Usuarios habilitados para SSPR pero no realmente registrados
Get-MgReportAuthenticationMethodUserRegistrationDetail -All `
-Filter "isSsprEnabled eq true and isSsprRegistered eq false" |
Select-Object UserPrincipalName, IsAdmin, IsSsprRegistered, MethodsRegistered
Cualquier cuenta que devuelva esta segunda consulta puede estar habilitada para SSPR sobre el papel sin tener ningún método conforme realmente registrado — lo que significa que su camino real de restablecimiento, hoy, sigue siendo el helpdesk. Cruce primero la columna IsAdmin con su lista de roles privilegiados; una cuenta Global Administrator o de directorio presente en ese resultado acumula la Falla 2 y la Falla 3 sobre la misma identidad, lo que la convierte en la combinación a priorizar antes que cualquier otra cosa en esta lista.
Remediación
💡 Solución rápida: active SSPR para All (todos los usuarios), y luego ejecute la consulta de cobertura de registro anterior antes de tocar cualquier otra cosa — corregir la política sin corregir el registro solo desplaza la misma falla un paso más adelante.
Cerrar la Falla 1 — Activar SSPR en todo el tenant
En el admin center de Entra, en Protection → Password reset → Properties, defina el alcance en All en lugar de None o un solo grupo piloto. Esto requiere el rol Authentication Policy Administrator y una licencia Entra ID P1+, según el tutorial de Microsoft.
Cerrar la Falla 2 — Someter las cuentas admin a una política de restablecimiento real
Confirme que allowedToUseSSPR en authorizationPolicy refleja una decisión intencional, y que los roles privilegiados están cubiertos por la política admin integrada de dos puertas de Entra en lugar de excluidos silenciosamente, según la documentación de Microsoft sobre la política SSPR. Para sus roles más sensibles (Global Administrator y equivalentes), combine esto con métodos resistentes al phishing y con cuentas de acceso de emergencia break-glass estrechamente supervisadas y excluidas de Conditional Access, de modo que la recuperación nunca dependa únicamente de SSPR o de una llamada al helpdesk. Verifique las asignaciones permanentes cruzándolas con su revisión de acceso privilegiado — una cuenta que no debería ser admin permanente en primer lugar no necesita que se le resuelva este problema.
Cerrar la Falla 3 — Exigir dos métodos y eliminar los débiles
Configure la política de restablecimiento para exigir al menos dos puertas, y elimine Security questions como opción autónoma — Microsoft las retira de SSPR de todos modos para marzo de 2027, según su documentación. Priorice la app Authenticator o el registro de passkey sobre SMS/llamada de voz.
Después, cierre el círculo del registro y la supervisión
Active la campaña de registro de métodos de autenticación para que los usuarios tengan métodos conformes registrados antes de necesitar restablecer una contraseña, cerrando AUTH_METHODS_NO_REGISTRATION junto con las otras tres fallas. Si su tenant también está trabajando en la aplicación de SSPR solo métodos registrados de noviembre 2026, el mismo informe de registro impulsa ambas correcciones — ese cambio deja de aceptar el teléfono/correo del directorio no registrado como respaldo, lo cual solo importa si la cobertura de registro se está siguiendo realmente en primer lugar.
Finalmente, supervise las dos actividades de auditoría más importantes — Self-service password reset policy changes y Reset password (by admin) — para que un futuro debilitamiento del alcance, el número de métodos, o los métodos permitidos, salga a la luz de inmediato en lugar de reabrir silenciosamente estas fallas. Un pico de restablecimientos realizados por un admin para el mismo puñado de usuarios suele ser la primera señal visible de que SSPR dejó de funcionar para ellos, mucho antes de que alguien abra un ticket al respecto.
Cómo lo detecta EtcSec
La auditoría de Entra ID de EtcSec verifica SSPR_NOT_ENABLED (SSPR limitado a None), SSPR_NOT_REQUIRED_ADMINS (administradores no cubiertos por una política de restablecimiento conforme), y SSPR_METHODS_WEAK (preguntas de seguridad o teléfono móvil solo satisfaciendo la política), junto con AUTH_METHODS_SMS_ENABLED y AUTH_METHODS_NO_REGISTRATION para la postura circundante de métodos de autenticación. Juntos, estos cinco controles ofrecen una vista única de si el camino de recuperación de cuenta es realmente tan sólido como el camino de inicio de sesión que se supone debe respaldar — porque un tenant que ha reforzado cada inicio de sesión con Conditional Access y MFA, pero ha dejado la recuperación de contraseña en una configuración SSPR por defecto, acaba de construir una puerta principal sólida junto a una entrada lateral sin cerrar.
ℹ️ Nota: EtcSec verifica automáticamente la activación de SSPR, la cobertura de admins, y la robustez de los métodos de restablecimiento en cada auditoría de Entra ID. Ejecute una auditoría gratuita para ver cuáles de sus admins todavía caerían hoy en un restablecimiento manual.
Explore las páginas de identidad que apoyan este tema