Entra Self-Service Password Reset (SSPR) Security Gaps: Not Enabled, Not Required for Admins, Weak Reset Methods

Entra Self Service Password Reset SSPR Security Gaps: What They Are

Self-service password reset (SSPR) in Microsoft Entra ID is supposed to close the account-recovery loop that multi-factor authentication opens elsewhere in the tenant. In practice, the same three entra self service password reset sspr security gaps keep showing up across real tenants: SSPR left disabled tenant-wide, administrators excluded from a policy that actually requires strong verification, and weak reset methods like security questions or SMS accepted as sufficient proof of identity on their own.

SSPR lets users regain access to a locked account without opening a helpdesk ticket, by verifying their identity through one or more registered methods (Authenticator app, email, phone, or security questions) at passwordreset.microsoftonline.com. Enabling it requires at least a Microsoft Entra ID P1 license and the Authentication Policy Administrator role, and it can be scoped to None, a single (optionally nested) group, or All users, per Microsoft's enablement tutorial.

Most rollouts stop there, framed purely as a cost saver — fewer helpdesk calls, faster reset for end users, one line item on a licensing spreadsheet. That framing is how the following three gaps survive unnoticed:

• SSPR left disabled entirely (SSPR_NOT_ENABLED) — no self-service path exists, so every reset routes through a human.
• Administrators not covered by a reset policy that actually requires strong verification (SSPR_NOT_REQUIRED_ADMINS) — privileged accounts fall back to the same manual, social-engineerable path.
• Weak methods accepted as sufficient proof of identity (SSPR_METHODS_WEAK) — security questions or SMS/voice calls satisfy the reset policy on their own.

None of these are exotic misconfigurations. They're default-adjacent states that a tenant drifts into simply by never revisiting SSPR after initial setup — which is also why they're rarely caught in a routine review: a penetration test or MFA audit typically checks whether sign-in requires a second factor, not whether the recovery path for that same account is just as strong. An attacker doesn't need to beat MFA at the front door if the back door — password recovery — only needs a guessed security question or a convincing phone call.

The Three SSPR Security Gaps, One at a Time

Gap 1 — SSPR Disabled Entirely

When SSPR scope is None, every password reset has to go through IT or the helpdesk. That manual path is exactly the vector described in CISA's Scattered Spider advisory (AA23-320A): threat actors call or text helpdesk staff while posing as an employee, requesting a password reset or an MFA device change as their initial access vector. A tenant with SSPR disabled hasn't removed the reset path — it has forced 100% of resets through the exact channel that technique targets, and given the helpdesk no self-service baseline to compare an unusual request against.

Gap 2 — Admins Not Required to Use SSPR

By default, Microsoft Entra treats administrator accounts differently: they're covered by a built-in, non-changeable two-gate policy requiring two pieces of authentication data, distinct from the (often single-gate) policy applied to regular users, per Microsoft's SSPR policy documentation. Tenants that disable the admin password-reset policy — without explicitly excluding admins from the user-facing policy — leave privileged accounts to reset the same way as Gap 1: manually, through the helpdesk. This is the single highest-value account to protect from that path, since a successfully socially-engineered reset on a Global Administrator is a full-tenant compromise, not just one mailbox.

Gap 3 — Weak Reset Methods Accepted

Security questions are answerable by anyone who has done light reconnaissance on a target, and Microsoft is retiring them from SSPR entirely by March 2027 for exactly that reason — Microsoft's own documentation flags them as "less secure than other methods" and recommends pairing them with a second method if they're used at all. Mobile phone (SMS/voice call) methods carry their own well-known interception and SIM-swap risk — NIST's digital identity guidelines classify phone-network-delivered codes as a restricted authenticator for exactly that reason, directing verifiers to check for SIM change and number porting before relying on it, per NIST SP 800-63B. A reset policy that accepts either of these as a single satisfying gate is functionally as weak as no policy at all — the account is one guessed answer or one intercepted text away from takeover.

Detection

If you're running a broader Entra ID security review, SSPR posture belongs in the same pass as Conditional Access and PIM — it's checked with the same Graph permissions and the same admin center session.

Querying Registration Coverage Directly

Connect-MgGraph -Scopes "Reports.Read.All", "Policy.Read.All"

# Admin SSPR posture
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy" |
  Select-Object -ExpandProperty allowedToUseSSPR

# Users enabled for SSPR but not actually registered
Get-MgReportAuthenticationMethodUserRegistrationDetail -All `
  -Filter "isSsprEnabled eq true and isSsprRegistered eq false" |
  Select-Object UserPrincipalName, IsAdmin, IsSsprRegistered, MethodsRegistered

Anyone this second query returns can be enabled for SSPR on paper while having no compliant method actually registered — meaning their real reset path, today, is still the helpdesk. Cross-reference the IsAdmin column against your privileged-role list first; a directory or Global Administrator account sitting in that output is Gap 2 and Gap 3 stacked on the same identity, which is the combination worth triaging before anything else on this list.

Remediation

Close Gap 1 — Enable SSPR Tenant-Wide

In the Entra admin center under Protection → Password reset → Properties, set scope to All rather than None or a single pilot group. This requires the Authentication Policy Administrator role and an Entra ID P1+ license, per Microsoft's tutorial.

Close Gap 2 — Bring Admin Accounts Under a Real Reset Policy

Confirm allowedToUseSSPR on authorizationPolicy reflects an intentional decision, and that privileged roles are covered by Entra's built-in two-gate admin policy rather than silently excluded, per Microsoft's SSPR policy documentation. For your most sensitive roles (Global Administrator and equivalent), pair this with phishing-resistant methods and tightly monitored break-glass emergency access accounts excluded from Conditional Access, so recovery never depends solely on SSPR or a helpdesk call. Cross-check standing assignments with your privileged access review — an account that shouldn't be a permanent admin in the first place doesn't need this problem solved for it at all.

Close Gap 3 — Require Two Methods and Drop the Weak Ones

Set the reset policy to require at least two gates, and remove Security questions as a standalone option — Microsoft is retiring it from SSPR by March 2027 anyway, per its documentation. Favor Authenticator app or passkey registration over SMS/voice call.

Then Close the Loop on Registration and Monitoring

Turn on the authentication-methods registration campaign so users have compliant methods registered before they ever need to reset a password, closing AUTH_METHODS_NO_REGISTRATION alongside the other three gaps. If your tenant is also working through the November 2026 SSPR registered-methods enforcement, the same registration report drives both fixes — that change stops accepting unregistered directory phone/email as a fallback, which only matters if registration coverage is actually being tracked in the first place.

Finally, monitor the two audit activities that matter most — Self-service password reset policy changes and Reset password (by admin) — so a future weakening of scope, method count, or allowed methods surfaces immediately instead of silently reopening these gaps. A spike in admin-performed resets for the same handful of users is usually the first visible sign that SSPR quietly stopped working for them, well before anyone files a ticket about it.

How EtcSec Detects This

EtcSec's Entra ID audit checks SSPR_NOT_ENABLED (SSPR scoped to None), SSPR_NOT_REQUIRED_ADMINS (administrators not covered by a compliant reset policy), and SSPR_METHODS_WEAK (security questions or mobile phone alone satisfying the policy), alongside AUTH_METHODS_SMS_ENABLED and AUTH_METHODS_NO_REGISTRATION for the surrounding authentication-methods posture. Together these five checks give a single view of whether the account-recovery path is actually as strong as the sign-in path it's meant to back up — because a tenant that has hardened every sign-in with Conditional Access and MFA, but left password recovery on a default SSPR configuration, has just built a strong front door next to an unlocked side entrance.