Microsoft Entra SSPR 於 2026 年 11 月起只接受已註冊驗證方法，如何找出受影響用戶

From early November 2026, Entra self-service password reset only accepts methods a user actually registered. The phone number and alternate email that sit in the directory stop counting. The users this catches can be listed today with read-only commands.

What changes: SSPR verification uses only registered authentication methods. Directory attributes (mobilePhone, businessPhones, otherMails) no longer work for SSPR unless the user registered them.
Who: all users in tenants with SSPR enabled, administrators included.
By when: Microsoft says act by 6 November 2026. Enforcement starts 7 November in the rollout schedule and 9 November in the title of the same message.
Do this:
1. List users who are allowed to use SSPR but aren't registered for it.
2. Turn on the registration campaign and brief the helpdesk.
Check: Get-MgReportAuthenticationMethodUserRegistrationDetail (read-only)
Source: MC1325414, Microsoft Learn "Prepopulate user authentication contact information for SSPR"

What Microsoft actually said

Message Center MC1325414 (published 28 May 2026, version 6 updated 4 August 2026):

• "SSPR will require explicitly registered authentication methods for verification."
• Directory attributes such as mobilePhone, businessPhone and otherMails "will no longer be valid unless registered."
• It applies to all users, including administrators, in tenants with SSPR enabled, in the public cloud and the US Government clouds.
• Users without a registered method at enforcement can't finish a reset. They are prompted to register or to contact an administrator.
• Dates in the message: registration campaign from 5 October 2026, enforcement from 7 November 2026, act by 6 November 2026. The title says 9 November. Plan for the earlier date.

The Learn page on prepopulating contact information carries the same warning in an Important box. It is also the page that shows how those directory values got there in the first place: Entra Connect syncs telephoneNumber and mobile from on-premises AD into Office phone and Mobile phone, and admins set otherMails and mobilePhone with Update-MgUser. That was the documented way to pre-load SSPR for years. Every tenant that followed it has users who never registered anything themselves.

The person who finds out first is the one who forgot their password on a Friday afternoon.

Step 1: list who is enabled but not registered

The user registration details report is the view Microsoft points to in the message (Entra admin center > Authentication methods > User registration details). Access needs a role such as Reports Reader, Security Reader or Global Reader, and the Usage and insights reports need Entra ID P1 or P2. The Graph permission is AuditLog.Read.All.

Three flags matter here, and they mean different things:

• IsSsprEnabled: policy allows the user to use SSPR.
• IsSsprRegistered: the user has registered the number of methods SSPR needs.
• IsSsprCapable: both of the above.

The users to worry about are enabled but not registered.

Connect-MgGraph -Scopes AuditLog.Read.All

$r = @(Get-MgReportAuthenticationMethodUserRegistrationDetail -All)

$gap = @($r | Where-Object { $_.IsSsprEnabled -and -not $_.IsSsprRegistered })

"Users in report: $($r.Count)"
"SSPR enabled: $(@($r | Where-Object { $_.IsSsprEnabled }).Count)"
"Enabled but not registered: $($gap.Count)"
"  of which admins: $(@($gap | Where-Object { $_.IsAdmin }).Count)"

$gap | Select-Object UserPrincipalName, UserType, IsAdmin,
    @{n='Methods';e={$_.MethodsRegistered -join ';'}} |
    Export-Csv -NoTypeInformation -Encoding UTF8 .\sspr-gap.csv

Every call here is a Get-. Nothing changes in the tenant.

If SSPR enabled is zero, SSPR is either off or scoped to a group that is empty. Check the scope in Entra admin center > Password reset > Properties before you decide the change doesn't affect you.

Step 2: see who was relying on directory data

The report says who isn't registered. It doesn't say who had a phone or email in the directory that SSPR was quietly using. That second list is the one the helpdesk will hear from, so join the two:

Connect-MgGraph -Scopes AuditLog.Read.All, User.Read.All

$rows = foreach ($u in $gap) {
    $d = Get-MgUser -UserId $u.Id -Property userPrincipalName, mobilePhone, businessPhones, otherMails
    [pscustomobject]@{
        UserPrincipalName = $d.UserPrincipalName
        IsAdmin           = $u.IsAdmin
        DirMobile         = [bool]$d.MobilePhone
        DirOffice         = [bool]@($d.BusinessPhones).Count
        DirOtherMail      = [bool]@($d.OtherMails).Count
        Registered        = ($u.MethodsRegistered -join ';')
    }
}

$rows | Where-Object { $_.DirMobile -or $_.DirOffice -or $_.DirOtherMail } |
    Export-Csv -NoTypeInformation -Encoding UTF8 .\sspr-directory-only.csv

"Gap users with directory phone or email: $(@($rows | Where-Object { $_.DirMobile -or $_.DirOffice -or $_.DirOtherMail }).Count)"

The export holds true/false flags, not the phone numbers themselves. Keep it that way if the file is going into a ticket.

For a few thousand users this is one Graph call per gap user. Run it once, not on a schedule.

Step 3: split the list

• Admins. The message is explicit that administrators are included. Admin SSPR has its own policy and usually needs two methods. Break-glass accounts should not depend on SSPR at all; check they are excluded by design and documented.
• Guests. Guests rarely reset passwords in your tenant. Note them and move on unless they hold access you care about.
• Members. The main number. These users get the registration campaign and a short message: what changes, where to register (My Security Info), and who to call.

Step 4: let the campaign do the asking

Microsoft's own advice in the message: allow or enable the registration campaign so users are prompted at sign-in, plan helpdesk-assisted registration as the fallback, and tell IT admins, the helpdesk and users before enforcement.

Check the campaign state without changing it:

Connect-MgGraph -Scopes Policy.Read.All
(Get-MgPolicyAuthenticationMethodPolicy).RegistrationEnforcement.AuthenticationMethodsRegistrationCampaign |
    Select-Object State, SnoozeDurationInDays

Then re-run Step 1 every couple of days until enforcement. The "Enabled but not registered" count is the number to track. It should go down; if it doesn't, the campaign isn't reaching those users.

Before you change anything

Write down the count from Step 1 today. If a reset ticket comes in after enforcement, that number tells you whether it was expected or something else.

Sources

• Message Center MC1325414, "Microsoft Entra ID SSPR will require registered authentication methods starting November 9, 2026" (v6, 4 August 2026)
• Microsoft Learn: Prepopulate user authentication contact information for Microsoft Entra self-service password reset (SSPR): https://learn.microsoft.com/entra/identity/authentication/howto-sspr-authenticationdata
• Microsoft Graph reference: userRegistrationDetails resource type, List userRegistrationDetails
• Microsoft Learn: Authentication Methods Activity (roles and licence)

Drafted with AI assistance and checked against Microsoft Learn and Message Center before publishing.