SSPR stops accepting unregistered phone numbers and email addresses on 9 November

Samantha Kloos-Kilkens

Nov 04, 2026 · Samantha Kloos-Kilkens

From 9 November 2026, self-service password reset in Microsoft Entra ID only accepts authentication methods a user has actually registered. Phone numbers and email addresses that only exist as attributes on the user object (synced from Active Directory, filled in by an HR feed or typed in by an admin) no longer count. With a few days to go, the work is to find the users who will hit a dead end next week, and to get them onto a method that still works after February.

Photo: Alex Shuper on Unsplash

What changes and when

Microsoft announced this on the Microsoft Entra blog and in Message Center as MC1325414. The timeline has moved twice and is well covered elsewhere, so briefly: the original Message Center post from May had a registration campaign on 6 July and enforcement on 7 September, which is why you still find blogs quoting September. The August update moved the campaign to 5 October and enforcement to 9 November, with the rollout running into mid-November. The body of the same Message Center post says enforcement begins on 7 November and lists 6 November as the act-by date, so I would treat Saturday the 7th as the real start and 9 November as the date by which every tenant should expect it. The Learn article on prepopulating authentication contact info currently has the two dates the other way round (enforcement on 5 October, campaign on 9 November); go by the Message Center post.

The scope is every user in a tenant with SSPR enabled, administrators included. The directory properties Microsoft names are mobilePhone, businessPhones and otherMails: if the user never registered that number or address as an authentication method, SSPR will no longer use it to verify them. According to Microsoft about 86% of SSPR verifications already use registered methods, which also tells you that roughly one in seven resets today runs on directory data.

How directory data became a reset path

Microsoft documented this as a way to bootstrap SSPR. The same Learn article describes how Microsoft Entra Connect maps the on-premises telephoneNumber and mobile attributes to Office phone and Mobile phone, and states that if you provided a value for Mobile phone or Alternate email, users can immediately use those values to reset their password, even if they haven't registered for the service. The SSPR FAQ says the same thing from the other side: users don't have to register if you define enough authentication information on their behalf.

What makes this risky is where that data lives and who can write it. Registered authentication methods are stored in private authentication fields that, per the FAQ, only the user and Privileged Authentication Administrators can see, and users add them in Security info after an MFA prompt. mobilePhone, businessPhones and otherMails are ordinary profile properties. Every user in the tenant can read them, and the list of sensitive actions shows which admin roles can update them; Microsoft treats them as sensitive precisely because they feed SSPR. For synced users the real source of truth is Active Directory, and there the circle of writers is usually much wider: service desk delegations on user OUs, HR connectors, identity management tooling, and the account itself (the AD schema lists the update privilege for mobile as domain administrator or account owner).

Put those together and you get a reset path that bypasses everything you configured for MFA registration. Anyone who can write mobile on an AD account can put their own number there, wait for the next sync cycle, and, if your SSPR policy allows mobile phone, complete an SSPR flow that only requires one method with a text message to that number. Password writeback then sets the new password in AD as well. For an attacker who already phished a password, their own number in the victim's profile is persistence that survives the next password change. And without any attacker involved, HR data ages: numbers of former company phones, numbers people ported away years ago, numbers a carrier has since recycled to someone else.

Who is affected

The affected population is users who are enabled for SSPR, don't have enough registered methods to meet your SSPR policy, and do have directory contact data. In practice a few groups keep coming back. Synced users in organisations where HR or AD has always populated mobile numbers and SSPR was rolled out years ago on the strength of that data. Users whose MFA runs through a third-party provider via federation or external MFA, because none of that counts as an SSPR method, so for them the directory mobile was often the only reset path there ever was. Cloud-only accounts created by onboarding scripts that set mobilePhone and called it done.

There is a newer group as well: users who only have passwordless credentials. Microsoft's method overview lists passkeys (device-bound and synced), Windows Hello for Business and Temporary Access Pass as not usable for SSPR. With Microsoft nudging SMS and voice users towards passkeys since 1 September, that group grows every week, and for them the directory mobile was often the only fallback.

The registration campaign that started on 5 October is meant to catch these users, but the Learn article ties it to your SSPR setting that requires users to register when signing in. If you switched that off at some point (common in tenants that moved to combined registration and their own nudges), check whether your users have seen any prompt at all.

Finding them before enforcement

The admin center has this under Entra ID > Authentication methods > User registration details (filter on SSPR enabled and SSPR capable), which tells you who can't reset but not why. The more useful list joins the userRegistrationDetails report with the directory attributes, so you see exactly who is currently being carried by mobilePhone, businessPhones or otherMails:

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

# Registration state for everyone SSPR applies to
$reg = Get-MgReportAuthenticationMethodUserRegistrationDetail -All -Filter "isSsprEnabled eq true"

# Directory contact data for all users, indexed by object ID
$dir = @{}
Get-MgUser -All -Property id,userPrincipalName,mobilePhone,businessPhones,otherMails,onPremisesSyncEnabled |
    ForEach-Object { $dir[$_.Id] = $_ }

$atRisk = foreach ($r in ($reg | Where-Object { -not $_.IsSsprCapable })) {
    $u = $dir[$r.Id]
    if (-not $u) { continue }
    if ($u.MobilePhone -or $u.BusinessPhones.Count -gt 0 -or $u.OtherMails.Count -gt 0) {
        [pscustomobject]@{
            UserPrincipalName = $r.UserPrincipalName
            IsAdmin           = $r.IsAdmin
            Synced            = [bool]$u.OnPremisesSyncEnabled
            MobilePhone       = $u.MobilePhone
            BusinessPhones    = $u.BusinessPhones -join '; '
            OtherMails        = $u.OtherMails -join '; '
            MethodsRegistered = $r.MethodsRegistered -join ', '
        }
    }
}
$atRisk | Export-Csv .\sspr-directory-only.csv -NoTypeInformation

Reading the report needs AuditLog.Read.All and a role such as Reports Reader or Global Reader. Two caveats from the Authentication Methods Activity documentation: the report can lag by up to 36 hours, and disabled users aren't in it. Spot-check a handful of results against the user's Authentication methods blade before you send anyone a mail. The IsAdmin column is there because the change applies to admin accounts too.

Which methods to steer users to

The obvious fix is to have these users register the phone number that's already in their profile. The SSPR registration page shows those directory values to the user, who can confirm or change them, so the campaign makes it a quick job. I would not do that. MC1426371 retires Microsoft-provided SMS and voice on 1 February 2027 (1 July 2027 for Global Administrators and external users), and the retirement FAQ states that this applies across Microsoft Entra, including SSPR. A phone number registered this week works for less than three months unless you contract a telephony provider through Microsoft Security Store. (I went into what that retirement means for SSPR in more detail in Passkeys by default: what we're running into.)

What does count for SSPR: Microsoft Authenticator (push or code), software and hardware OATH tokens, email OTP, and SMS and voice for as long as they last. Security questions still exist for non-admin users, but Microsoft retires them in March 2027, so they're not a plan either. Note that Authenticator and OATH tokens count as a single method for SSPR. If your policy requires one method, Authenticator covers it. If it requires two, Authenticator plus email OTP is about the only combination left after February without a telephony provider, so think about which mailbox users register: a work address they can't reach while locked out is useless.

So my recommendation for this week is a passkey for sign-in plus the Authenticator app registered for push or code as the SSPR method, with a personal email address as the second method where your policy needs two. For users who are fully passwordless, turn on Allow password change after secure sign-in under the Password method in the Authentication methods policy (MC1437671, rolling out from the end of October, P1 or P2 required, tenant-wide). It lets them set a new password from Security info after a passwordless sign-in, which takes away a lot of the reasons they would otherwise need SSPR.

For users who are stuck with nothing usable, issue a Temporary Access Pass. One detail from the TAP limitations: users in scope of the SSPR registration policy who sign in with a TAP land in the interrupt mode of combined registration, which doesn't support passkey registration. Let them register Authenticator there (that's the SSPR method you want anyway) and add the passkey afterwards in Security info.

What the helpdesk will notice

Users without a registered method get the message to contact their administrator, so the calls arrive at the service desk, most likely on the first Monday after enforcement. Three things to settle with them beforehand. Check how they verify callers: if the procedure is calling back the mobile number in the directory, it reproduces the exact weakness Microsoft just closed. Check their roles: Helpdesk Administrator and Password Administrator can reset passwords, but creating a TAP requires Authentication Administrator (or Privileged Authentication Administrator for admins). And make sure nobody decides to fix the backlog by bulk-copying mobilePhone into phone authentication methods with a script. As far as I can tell an admin-added phone method counts as registered, but it re-imports data nobody verified and stops working on 1 February anyway.

otherMails doesn't become meaningless, by the way: SSPR still sends its password reset notifications to the primary and alternate email addresses, which is reason enough to keep that attribute accurate.

Before Saturday: run the script above, split the output into synced and cloud-only users, send the synced group a targeted message pointing at Security info for Authenticator, and confirm that the SSPR setting requiring registration at sign-in is on so the campaign actually reaches them before Monday.

SSPR stops accepting unregistered phone numbers and email addresses on 9 November

What changes and when

How directory data became a reset path

Who is affected

Finding them before enforcement

Which methods to steer users to

What the helpdesk will notice

Sources

Stay in the Loop

You might also like:

Passkeys by default: what we're running into

Moving ID Protection risk policies to Conditional Access before 1 October