Entra SSPR Portal Can Enumerate Users and MFA Methods — What NZ Tenants Should Check This Week

LevelBlue SpiderLabs published research on 23 September 2026 showing that Microsoft’s Self-Service Password Reset (SSPR) portal at passwordreset.microsoftonline.com leaks more than most tenants expect. Without signing in, anyone who submits a work email can learn whether that account exists, which password-reset verification methods are registered (SMS, alternate-email OTP, authenticator app, and similar), and — in some configurations — which accounts are likely administrators.

Hackread.com covered the same findings on 24 September 2026. Neither report claims the portal hands out passwords or grants access. The risk is reconnaissance: a confirmed target list, ranked by weak second factors, before any password spray or phishing campaign begins.

Why NZ organisations should care

Most New Zealand mid-market and public-sector Microsoft 365 tenants run Entra ID with SSPR enabled for helpdesk relief. That is reasonable. The portal is public by design, and Microsoft’s August 2026 change under Message Center item MC1400824 removed the legacy visual CAPTCHA, replacing it with backend throttling and behaviour-based abuse detection. Bulk probing is easier than it was a few months ago. A public tool, ResetSpy (github.com/mlcsec/ResetSpy), automates the two-request flow against email lists.

Three outcomes matter for a typical NZ tenant:

• User enumeration. A valid account advances toward method selection. An invalid one does not. Policy errors such as “SSPR not enabled for this user” (SSPR_0011) or “not in the scoped SSPR group” (SSPR_0013) still confirm the account exists — the directory resolved the username before applying policy.
• Method leakage. For accounts where SSPR proceeds, the portal lists registered verification methods. SMS and alternate-email OTP are weaker against SIM swap, real-time phishing proxies, and secondary-inbox compromise than a strong authenticator or phishing-resistant factor. Attackers can tailor the next step to what they see.
• Admin identification. Microsoft forces SSPR for privileged roles even when SSPR is disabled for standard users. In a tenant that turned SSPR off for everyone else, any account that still reaches the method screen is likely an admin — and their registered methods are visible too.

Under the Privacy Act 2020, if you hold personal information in a Microsoft tenant you need reasonable safeguards against misuse of that information. Unauthenticated confirmation of staff accounts and recovery methods is not a breach by itself, but it lowers the cost of targeted phishing and social engineering that can become a mailbox or directory incident. Knowing which recovery paths your privileged users expose — and monitoring abuse of the reset portal — is part of that safeguard story.

This sits beside our earlier note on passkey-themed helpdesk lures. That campaign also turned identity convenience into reconnaissance and social engineering. SSPR portal enumeration is the same pattern on a different Microsoft surface: a legitimate feature that tells outsiders too much about who is real and how they protect themselves.

What to do this week

• Scope SSPR deliberately. Prefer Selected groups over All users if your licensing and helpdesk model allow it. Restrict reset access to people who genuinely need it. Monitor Entra Audit Logs for status failures such as “user is not member of the password reset users group” — spikes across many usernames with no completed reset are a classic enumeration pattern.
• Strip weak reset methods. Remove alternate email and security questions from permitted SSPR methods where policy allows. Prefer authenticator app (or better) as a minimum for password reset. Treat “no methods registered” accounts as high priority: on modern tenants with combined registration, that often correlates with thin MFA posture, though FIDO2-only or legacy registration edge cases can look empty on SSPR even when sign-in MFA is strong.
• Harden privileged accounts first. You cannot turn SSPR off for Microsoft-enforced admin roles, but you can require phishing-resistant MFA (passkeys / FIDO2, certificate-based) for those roles and keep weak methods off the admin registration path. Even if an attacker identifies an admin via the portal, a phishing-resistant factor raises the cost of the next step.
• Watch the portal, not just the inbox. Bulk SSPR probes — many username submissions, varied addresses, few or no completed resets — belong in your Entra / Defender alert queue. Confirm someone owns unusual SSPR activity the same way you own odd sign-in or consent events.
• Use Conditional Access for the rest of the stack. Privileged and high-risk users should land on phishing-resistant MFA and, where licensing allows, managed or compliant devices for Exchange, SharePoint, and admin portals. Portal enumeration is reconnaissance; Conditional Access and strong methods are what stop it becoming a session.
• Brief helpdesk and staff. Unsolicited “we need you to reset” or “confirm your recovery methods” contact is a red flag. Legitimate resets start from the user or a known internal process — not from an outsider who already knows which methods you registered.

What this is not

It is not a claim that Microsoft “gave away passwords,” and it is not a reason to disable SSPR blindly if your helpdesk depends on it. It is also not a substitute for reviewing authentication methods and Conditional Access. The lasting moves are the same ones that survive the next public recon tool: scoped SSPR, strong methods only, phishing-resistant MFA for privileged roles, and monitoring that treats bulk password-reset probes as suspicious.

If you want a practical backlog for the controls that survive the next kit, see our Conditional Access starter checklist and the Microsoft Secure Score Quick-Start Checklist.

Sources: LevelBlue SpiderLabs — Enumerating Users and MFA via Microsoft’s Password Reset Portal (23 Sep 2026), Hackread — Microsoft Password Reset Portal Can Leak Account Verification Details (24 Sep 2026), ResetSpy on GitHub, MC1400824 — SSPR CAPTCHA protection updated.