SSPR Hardening: Find Users Who Will Be Locked Out When Unregistered Phone Numbers Stop Working

For years, many organizations have relied on a quiet convenience in Microsoft Entra ID Self-Service Password Reset (SSPR): if a user never registered any security info, SSPR could still fall back to the mobilePhone or businessPhones attributes synchronized from on-premises Active Directory or populated by HR provisioning.

That fallback is going away. Under Message Center notice MC1325414, SSPR only accepts authentication methods that the user has explicitly registered as authentication methods. Directory contact attributes that were never registered are no longer valid proofs for password reset.

The impact is predictable: the users who never bothered to register — often frontline workers, shared-device users, and long-tenured staff — are exactly the ones who will call the helpdesk on Monday morning saying "the password reset page says I have no methods."

In this guide we will: 1. Explain the difference between directory contact info and registered authentication methods. 2. Run a Microsoft Graph PowerShell audit to find every SSPR-enabled user who is not SSPR-registered but has a directory phone number they may be counting on. 3. Remediate with a targeted registration campaign, or by pre-provisioning authentication phone methods through Graph.

---

Directory Contact Info vs. Registered Authentication Methods

These two things look similar in the portal but live in completely different places:

---

Prerequisites

• Microsoft Graph PowerShell SDK (PowerShell 7 recommended — see Migrating from PowerShell 5.1 to 7 for Graph SDK).
• An account with Reports Reader, Security Reader, or Global Reader for the audit; Authentication Administrator for remediation.
• The authentication method registration report requires Microsoft Entra ID P1 or P2 licensing.

Install-Module Microsoft.Graph.Reports, Microsoft.Graph.Users, Microsoft.Graph.Identity.SignIns -Scope CurrentUser -Repository PSGallery

# Read-only scopes for the audit
Connect-MgGraph -Scopes "AuditLog.Read.All", "User.Read.All"

---

Step 1: Quick Health Check

Before running the full audit, get a feel for the size of the problem:

$reg = Get-MgReportAuthenticationMethodUserRegistrationDetail -All

[PSCustomObject]@{
    TotalUsers         = $reg.Count
    SsprEnabled        = ($reg | Where-Object IsSsprEnabled).Count
    SsprRegistered     = ($reg | Where-Object IsSsprRegistered).Count
    SsprCapable        = ($reg | Where-Object IsSsprCapable).Count
    EnabledNotCapable  = ($reg | Where-Object { $_.IsSsprEnabled -and -not $_.IsSsprCapable }).Count
}

The number to watch is EnabledNotCapable: users who are in scope of your SSPR policy but cannot currently complete a reset with registered methods.

---

Step 2: Full At-Risk User Audit Script

This script joins the registration report with each user's directory phone attributes, so you can separate users who will be newly locked out (they had a directory phone they were probably relying on) from users who were never able to reset at all.

<#
.SYNOPSIS
    Finds Entra ID users at risk of SSPR lockout after registered-methods-only enforcement.
.DESCRIPTION
    Joins the authentication method registration report with directory phone attributes
    to identify SSPR-enabled users who are not SSPR-capable and classifies the risk.
.NOTES
    Author: Sunil Chauhan (https://www.lab365.in)
    Requires: Microsoft.Graph.Reports, Microsoft.Graph.Users
    Scopes:   AuditLog.Read.All, User.Read.All
#>

[CmdletBinding()]
param (
    [string]$ExportPath = ".\SSPR_AtRisk_Users_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv",
    [switch]$IncludeGuests
)

if (-not (Get-MgContext)) {
    Connect-MgGraph -Scopes "AuditLog.Read.All", "User.Read.All" -NoWelcome
}

Write-Host "[*] Loading authentication method registration details..." -ForegroundColor Cyan
$registration = Get-MgReportAuthenticationMethodUserRegistrationDetail -All

Write-Host "[*] Loading enabled users and directory phone attributes..." -ForegroundColor Cyan
$users = Get-MgUser -All -Filter "accountEnabled eq true" `
    -Property "id,userPrincipalName,displayName,userType,mobilePhone,businessPhones,department,onPremisesSyncEnabled"

# Index users by Id for fast lookup
$userIndex = @{}
foreach ($u in $users) { $userIndex[$u.Id] = $u }

$results = [System.Collections.Generic.List[PSCustomObject]]::new()

foreach ($r in $registration) {
    if (-not $r.IsSsprEnabled -or $r.IsSsprCapable) { continue }

    $u = $userIndex[$r.Id]
    if (-not $u) { continue }                       # disabled or not returned
    if (-not $IncludeGuests -and $u.UserType -eq 'Guest') { continue }

    $hasDirectoryPhone = [bool]($u.MobilePhone -or ($u.BusinessPhones -and $u.BusinessPhones.Count -gt 0))

    $risk = if ($hasDirectoryPhone -and $r.MethodsRegistered.Count -eq 0) {
        'HIGH - Relied on directory phone, no registered methods'
    } elseif ($r.MethodsRegistered.Count -gt 0) {
        'MEDIUM - Partially registered, below SSPR method requirement'
    } else {
        'LOW - No directory phone, never able to use SSPR'
    }

    $results.Add([PSCustomObject]@{
        UserPrincipalName  = $u.UserPrincipalName
        DisplayName        = $u.DisplayName
        Department         = $u.Department
        SyncedFromAD       = [bool]$u.OnPremisesSyncEnabled
        DirectoryMobile    = $u.MobilePhone
        DirectoryBusiness  = ($u.BusinessPhones -join ';')
        MethodsRegistered  = ($r.MethodsRegistered -join ';')
        IsMfaRegistered    = $r.IsMfaRegistered
        Risk               = $risk
        UserId             = $u.Id
    })
}

$results = $results | Sort-Object Risk, Department, UserPrincipalName
$results | Export-Csv -Path $ExportPath -NoTypeInformation -Encoding utf8

Write-Host ""
Write-Host "[!] At-risk users found: $($results.Count)" -ForegroundColor Yellow
$results | Group-Object Risk | Select-Object Count, Name | Format-Table -AutoSize
Write-Host "[+] Report exported to: $ExportPath" -ForegroundColor Green

Reading the output

• HIGH — These users are the ones who will be surprised. They have a phone number in the directory, have never registered anything, and probably believed SSPR "just worked". Prioritize them.
• MEDIUM — They registered something (for example, only email) but not enough methods to satisfy your SSPR policy's number of methods required.
• LOW — They were never able to use SSPR. Not a new problem, but a good registration campaign target.

Step 3: Remediation Options

Option A — Targeted registration campaign (recommended)

Use the HIGH list to drive a focused campaign rather than nagging the entire tenant:

1. Add the HIGH users to a security group and enable the registration campaign (Entra admin center → Protection → Authentication methods → Registration campaign) targeting that group, nudging them to Microsoft Authenticator. 2. Make sure combined security info registration is reachable at https://aka.ms/mysecurityinfo and is protected by a Conditional Access policy for Register security information (trusted locations or Temporary Access Pass). 3. Email managers the department breakdown from the CSV — departmental pressure works far better than generic IT notices.

Option B — Pre-provision authentication phone methods (with care)

If your directory phone data is trustworthy (for example, HR-mastered corporate mobiles), an Authentication Administrator can register the number as an authentication phone method on the user's behalf:

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All", "User.Read.All" -NoWelcome

$highRisk = Import-Csv ".\SSPR_AtRisk_Users_20261104_170000.csv" |
    Where-Object { $_.Risk -like 'HIGH*' -and $_.DirectoryMobile }

foreach ($u in $highRisk) {
    # Graph expects E.164-style format, e.g. "+44 7700900123"
    $phone = $u.DirectoryMobile.Trim()
    if ($phone -notmatch '^\+\d') {
        Write-Warning "Skipping $($u.UserPrincipalName): '$phone' is not in +CountryCode format."
        continue
    }

    try {
        New-MgUserAuthenticationPhoneMethod -UserId $u.UserId -PhoneNumber $phone -PhoneType "mobile" -ErrorAction Stop | Out-Null
        Write-Host "[+] Registered authentication phone for $($u.UserPrincipalName)" -ForegroundColor Green
    } catch {
        Write-Warning "Failed for $($u.UserPrincipalName): $($_.Exception.Message)"
    }
}

[!WARNING] Pre-registering phone numbers turns directory data into a password reset credential. Only do this if the source of the number is authoritative. A stale or attacker-modified mobilePhone attribute would hand over account recovery. SMS is also the weakest SSPR method — treat Option B as a bridge, and keep moving users to Microsoft Authenticator or passkeys.

Option C — Temporary Access Pass for the stragglers

For users who cannot self-register (no smartphone, shared devices), issue a Temporary Access Pass (TAP) at the helpdesk so they can sign in once and register a method, instead of the helpdesk resetting passwords repeatedly.

---

Verification

After remediation, re-run the quick health check from Step 1. EnabledNotCapable should trend toward zero. Schedule the audit script weekly (Azure Automation with a managed identity works well) so new joiners who skip registration are caught early.

---

Summary Checklist

• [ ] Run the quick health check and record the EnabledNotCapable baseline.
• [ ] Run the at-risk audit and review the HIGH group first.
• [ ] Launch a targeted registration campaign for HIGH and MEDIUM users.
• [ ] Pre-provision authentication phone methods only from authoritative data.
• [ ] Brief the helpdesk on TAP issuance and the new "no methods available" error.
• [ ] Schedule the audit weekly.

Related: Office 365 MFA Method Report with Microsoft Graph · Auditing Entra Dynamic Groups Using the Deprecated memberOf Operator