Entra password reset won't take directory phone numbers from February 2027. Who gets stuck?
Microsoft's docs now say Entra self-service password reset only accepts registered methods from February 2027. Directory phone numbers and emails stop counting, SMS and security questions are leaving too, and Microsoft's own pages disagree on the date.
part 31 of 34 · Platform releases, explained from scratchthe ideaDirectory data stops proving who you are. Registered methods are all SSPR will take.
after reading, you can- Find out who's still relying on a directory phone or email, before a failed reset tells you
- Pick recovery methods that'll still work once SMS, voice and security questions have gone
- Give your helpdesk a way to check who's calling, and a pass process for people who can't self-serve
A staff member forgets their password, types in the phone number HR has on file, and gets a code. That route is closing. Microsoft's documentation now says that from February 2027, Entra password reset only accepts methods a person has actually registered, so find those people and get them registered first.
The company phone list won't get anyone through a password reset much longer
Self-service password reset, or SSPR, lets people get back into a locked work account without calling IT. To prove who they are, they enter a code sent to a phone or email address. Today that contact detail can come straight from the company directory, even if the person never set it up for this purpose. Microsoft is ending that. Anyone relying on directory details will hit a failed reset and have to contact an administrator. Nothing breaks on the day for people who can still sign in. It shows up later, when someone forgets a password.
Think of a front desk that lets you in once your name's on an old staff list. Under the new rule the list doesn't count. You need the pass you collected yourself, and if you never picked one up, you're waiting for security to come down.
- Microsoft 365 and Entra admins
- Helpdesk leads
- Security and compliance teams
- HR teams who feed phone numbers into AD
- Business owners running Microsoft 365
- School IT departments
Why this lands on the helpdesk
Microsoft says about 86% of verifications already use registered methods. It doesn't break that down, and it counts verifications, so it won't tell you much about your tenant. A company that loaded mobile numbers from AD years ago and never ran a registration push could sit far from that average.
The failure is quiet too. Nobody gets locked out when the rule starts. A user finds out when they've forgotten a password, the reset page won't take the old number, and they're told to contact an administrator. If that's a Sunday night or a shared service desk, your team takes the call and has to decide how to prove who's on the line.
Microsoft files this under its Secure Future Initiative, and the reasoning holds up. Somebody typed that directory number in, maybe years ago, and it may now reach someone who doesn't work for you. Registering ties the method to the person using it. We'd do this work even if the date slipped again.
-
01 Number sits in the directory
The mobile field came from AD or HR. The user never confirmed it, and SSPR has been happy to use it anyway.
-
02 Rule starts
SSPR stops counting mobilePhone, businessPhone and otherMails when they were never registered. Nothing visible changes for anyone yet.
-
03 Password is forgotten
Nobody thinks about any of this until the day they're locked out. That could be months after the rule started.
-
04 Reset fails
The old number doesn't work any more and nothing else is registered. The page sends them off to find an administrator.
-
05 Helpdesk takes over
Someone has to check who's calling, reset the password and get the user registered, so it doesn't happen again.
Directory values and authentication methods are two separate sets of data, and Microsoft's admin docs treat them that way. Public profile contact details live on the user object and, for synced users, are managed in on-premises AD. Authentication methods stay private and are only used for authentication. With default Entra Connect mappings, AD's telephoneNumber becomes Office phone and mobile becomes Mobile phone. Those are the values losing their standing here.
What changes, and what else goes at the same time
The change at a glance
Mobile, business phone and alternate email sitting in the directory won't verify a reset any more. They'd have to be registered first.
Everyone in a tenant with SSPR on, and that includes admins. Microsoft's notice applies it to public cloud and US government clouds alike.
The notice went from September to November. The docs went from 5 October to February 2027. Plenty of blog posts still carry the older dates.
The page edit dated 5 November dropped its note on Microsoft's prompts for affected users. Run your own prompts and don't wait for Microsoft's.
These stop counting 50 days after the sign-in retirement reaches your tenant. A number someone registers today still has a limited life.
Retired for SSPR in March 2027. The admin reset policy already bans them, so admins aren't affected by this one.
The dates to keep straight
- 28 May 2026MC1325414 published
Earlier versions pointed at September. Older write-ups you'll find still say 7 September.
- 4 Aug 2026Notice moved to November
The newest archive copy has a campaign on 5 October, then enforcement on 7 or 9 November. It depends which line you read.
- 5 Nov 2026Docs now say February 2027
It's the newest word we could find, so don't take it on trust. Your own Message Center may say something else.
- 1 Feb 2027Microsoft SMS and voice retire for sign-in
Applies to everyone except Global Administrators and external users, in public cloud and GCC first. The 50-day SSPR clock starts when this rollout reaches your tenant.
- Feb 2027Registered methods only
No day given, so plan as if it's the first.
- 22 Mar 2027Act-by on MC1536049
SMS and voice stop counting for SSPR once the tenant's 50 days run out. Anyone without another method gets stuck.
- Mar 2027Security questions retire
Anyone who still uses them needs something else by then, or they're calling you.
- 1 Jul 2027SMS and voice: Global Admins, external users
A separate rollout with its own 50 days. A Global Admin role that's only eligible in PIM doesn't count.
These changes hit the same people in the same quarter, and that's what should shape your plan. Tell everybody to register a mobile in February and it may not even work: once the SMS retirement reaches your tenant, users can't add SMS or voice methods, and numbers already registered stop working for SSPRdefinitionSelf-service password reset. Someone who's locked out proves who they are and sets a new password, and nobody in IT gets a call. after 50 days, unless you've set up a telephony providerdefinitionA phone company you hook up to Entra yourself. SMS and voice codes keep working through them after Microsoft's own service goes.. Do the registration push once, before then, and aim it at methods that will still be there in April.
| Method | Today | After the registered-only rule | After SMS and voice retire |
|---|---|---|---|
| Mobile, business phone or alternate email, directory only | Accepted | Rejected | Rejected |
| Registered SMS or voice, Microsoft-provided | Accepted | Accepted | Gone once the 50 days end |
| SMS or voice through a telephony provider | Depends on setup | Accepted if registered | Still available |
| Microsoft Authenticator or OATH token | Accepted if registered | Accepted | Accepted. These count as one method together |
| Email code, registered | Accepted | Accepted | Accepted |
| Security questions | Accepted if allowed, not for admins | Accepted until March 2027 | Retired |
| Passkey | Not on the SSPR list | Not on the SSPR list | Not on the SSPR list |
- The directory phone or email can verify a reset
- Users can reset without registering first
- HR data quietly doubles as a recovery route
- Failures are rare, so nobody watches for them
- Only registered methods verify a reset
- Someone who never registered gets sent to an admin, and that's a ticket
- Directory data goes back to being contact details
- Your helpdesk needs a way to check who's calling
Pick how each group of people gets back in
Registering everyone is the visible task, but the choice underneath it is which recovery route each group of users gets. Office staff with company phones are easy. Warehouse shifts, students, contractors and people on leave usually aren't, and they're the ones who need a plan written down.
| Option | Effort | What it costs you | The catch | Pick it when |
|---|---|---|---|---|
| App or token plus registered email | Medium: a registration push | Staff time, plus hardware tokens if you buy them | Hardware OATH is in preview, personal email needs a privacy talk, and a two-method policy may refuse this pair | Most office and hybrid staff |
| Keep phones through a telephony provider | High: procurement, setup, testing | A provider contract, priced by that provider | Test it and migrate users before the transition ends, and before 1 February for sign-in | Regulation or operations really demand phone recovery |
| Password change after secure sign-in | Low once it reaches your tenant, Entra ID P1 or P2 needed | Passkey or certificate rollout, if you don't have one | Tenant-wide setting, and no help to someone who can't sign in | Passwordless users who still need a password for old apps |
| Managed recovery with Temporary Access Pass | Medium: a process and staff cover | Helpdesk or local staff hours | A pass doesn't replace the password, and someone with the right admin role must be around to check identity | Students and frontline staff without a phone or email |
That third row catches people out. Passkeys don't meet SSPR's requirements, so a fully passwordless user can still fail a reset. Microsoft's answer is a setting called Allow password change after secure sign-in. A user who signs in with a passkey, a certificate or an Authenticator passwordless notification can set a new password in Security infodefinitionThe page in My Sign-Ins where people set up their own phone, email, app or token. Whatever they add there counts as registered. without typing the old one. Microsoft says it won't turn that on for you, and you can't scope it to a group.
Schools have the hardest version of this. An IT admin at a grades 6-12 school told Microsoft's Q&A forum that students use security questions, because not all of them have cellphones and those who do can't have them during the school day. A Microsoft moderator said there's no like-for-like replacement or education exception and suggested a Temporary Access PassdefinitionA short-lived code an admin hands out, for one sign-in or several. Someone with no methods uses it to get in and set one up.. The admin replied that it doesn't help on evenings, weekends or holidays when staff aren't around, and added that Microsoft support called this a known gap with a fix being worked on. We can't confirm that. Plan for those hours, or accept that a forgotten password waits for Monday.
# example: who can reset but hasn't registered $scopes = "AuditLog.Read.All","User.Read.All" $scopes += "UserAuthenticationMethod.Read.All" Connect-MgGraph -Scopes $scopes Get-MgReportAuthenticationMethodUserRegistrationDetail -All | Where-Object { $_.IsSsprEnabled -and -not $_.IsSsprRegistered } | Select UserPrincipalName, MethodsRegistered # then compare directory values and phones $upn = "[email protected]" $f = "mobilePhone","businessPhones","otherMails" Get-MgUser -UserId $upn -Property $f | Select $f Get-MgUserAuthenticationPhoneMethod -UserId $upn # example output (illustration, layout varies) UserPrincipalName MethodsRegistered [email protected] {}
Read that report carefully. Microsoft's notice sends you to User registration details, but it doesn't say how the report treats a directory value nobody registered. So cross-check a sample against the user's real registered methods before you trust the count. The report can lag by up to 36 hours and it leaves out disabled and soft-deleted accounts. A leaver who comes back, or a suspended contractor, won't be on your list. The report call needs AuditLog.Read.All and a reporting role, and Microsoft points to the same Entra ID P1 or P2 licensing as the Usage and insights screens. The phone lookup needs Global Reader or an authentication admin role, and Authentication Administrators only see masked numbers.
What to do now
Who does what before February
- Ask IT whether password reset is on, and how many people haven't registered a method.
- Decide who may reset a password out of hours, and how they'll check the caller is really staff.
- Budget for a telephony provider only if phones are truly required, and get a written reason why.
- Read MC1325414 in your own admin center and write down the date it shows.
- Take one account that only has directory values and try a reset. Write down what happens, because that's your real date check.
- Pull User registration details, then cross-check a sample by hand.
- Turn on Require users to register when signing in for the SSPR group. They'll get asked at every sign-in until it's done.
- Write down how you'll check who's calling when a reset fails. The number on file can't be the proof any more.
- Agree who can issue a Temporary Access Pass and how long it lasts. Nights and weekends need a name too.
- Give agents a script for callers whose number just got rejected. Most will assume the system's broken.
- Look through Registration and reset events every week and pull out the failures. That's your early warning.
- Agree which methods count, and whether personal email is acceptable for recovery.
- Go through the admin accounts one by one. Each needs two usable methods, and security questions won't count.
- Write the change into the access control records with the date you checked it. Auditors will ask.
The order we'd run it in
- 01Confirm the date for your tenant
Check MC1325414 in the admin center and test one account. If that test already fails, you're working on a live problem, so jump to the playbook below.
- 02Size the gap
Combine the registration report with the reset events from the last 30 days. Look at Password resets by authentication method to see which channels people actually use.
- 03Fix the policy first
Pick the methods you'll still accept in April. Take security questions and Microsoft's SMS out of the plan, then test the method count in a pilot group.
- 04Turn on the prompt
Require users to register at sign-in, so they're asked every time until they finish. When SSPR is the only policy in play, people can keep skipping, so watch the numbers and chase them.
- 05Handle the groups who can't self-serve
Frontline staff, students and people on leave get a named route, usually a Temporary Access Pass from a local manager or helpdesk. New joiners should register in their first sign-in.
- 06Test as a real user
Test without an admin role. Admins follow a separate two-gate policy, so a reset that works for you says nothing about how it behaves for staff.
Harden it so the next change hurts less
Before: the directory doubles as recovery
HR data flows through AD and Entra Connect into fields SSPR will accept, whether or not the person ever confirmed them.
After: recovery has its own data
Profile fields stay as contact details. SSPR reads only what the user registered, with a managed route for people who can't.
Durable fixes
- 01Make registration part of onboarding
New joiners get a Temporary Access Pass, register at first sign-in, and don't leave setup without a working recovery method. The gap stops growing, and that's half the battle.
- 02Ask people to reconfirm
SSPR can ask users to reconfirm their details on a schedule from 0 to 730 days, where 0 means never. Microsoft's tutorial uses 180. Pick a number your users will tolerate, because details go stale here too.
- 03Harden the helpdesk reset
Once self-service fails more often, callers get more leverage. Use a call-back to a known number, a manager's confirmation or a live ID check, and log who approved what.
- 04Train people on reset prompts
Registration doesn't stop someone calling a user and talking them into approving a reset. Bravura Security, which sells tools in this market, makes that point about this change, and it's fair. Tell staff that nobody from IT will ask them to approve a prompt.
- 05Watch Message Center by notice number
This date has moved several times. Have one named person check MC1325414 and MC1536049 each month, instead of trusting whichever blog post ranks first.
If it goes wrong
When resets start failing, or a stale number has been abused
Most of this is a helpdesk surge. Treat it as a security incident only when a reset went through for someone who didn't ask for it.
- 01Confirm the causefirst hour
- Open Registration and reset events and read the reason for failure on a few real cases.
- Check that user's registered methods, because a missing method and a blocked policy need different fixes.
- Read MC1325414 again. The date has moved before, so don't work from your notes.
- 02Keep people workingsame day
- Tell the helpdesk what's going on and hand them the identity check. Don't let each agent make up their own.
- Issue short-lived Temporary Access Passes once you've checked who's calling. A pass lets them in to register, but a forgotten password still needs resetting.
- Send staff the Security info link along with a plain explanation of why they're being asked.
- 03Close the gapfirst week
- Re-run the registration report and work through it by department.
- Give each group that can't self-serve a named owner. Otherwise those tickets just keep coming back.
- Allow up to 36 hours for the report to catch up before you chase anyone twice.
- 04If a reset looks hostileimmediately
- Reset the password and revoke the user's sessions first. Then go through the methods on the account, since an attacker may have added one.
- Remove any method the user doesn't recognize, and check sign-ins from around the time of the reset.
- Bring in your incident lead, and let legal and your insurer decide who else must be told.
- 05Learn from itwithin a month
- Count how many failures came from each group, and adjust the onboarding that let them through.
- Clean up old contact data in AD and HR, since people still rely on it to reach each other.
- Write down the identity check that worked, so the next surge doesn't start from zero.
Four illustrative situations
- the setup
- A professional services firm synced AD mobile numbers to Entra years ago and turned on SSPR. Many staff have reset a password that way and never opened Security info.
- what happens
- Once the rule starts, the first forgotten passwords bounce. Tickets rise slowly, so nobody links them to a change in policy until the helpdesk compares notes.
- what to do
- Run the report now, require registration at sign-in, and steer people to Authenticator and email. Leave the directory numbers alone, because staff still use them to call each other.
- the setup
- A retailer's store staff sign in on shared tablets, and they don't have company phones. Their only recovery data is a personal number HR entered.
- what happens
- Registering that number by text only buys time, since Microsoft's SMS stops counting for SSPR after the transition. Authenticator on personal phones may not be something the company can demand.
- what to do
- Decide this store by store with HR. Temporary Access Passes are one route, though whoever issues them needs the right admin role. A telephony provider is another if phones must stay. Write down who covers nights.
- the setup
- A grades 6-12 school uses security questions because not all its students have a phone, and personal email isn't an option either.
- what happens
- March 2027 takes that route away, and Microsoft's forum moderator says schools aren't getting an exception. A forgotten password now waits until an adult with the right role can deal with it.
- what to do
- Delegate pass issuing to a few trusted staff, tell parents early, and agree what happens during holidays. Review lockout and expiry settings, so students need resets less often.
- the setup
- A small IT team of Global Administrators reset with a phone and an email. Their two-gate policy asks for two pieces of data, and nobody can change that.
- what happens
- Active Global Admins keep Microsoft's SMS for sign-in until 1 July 2027, but anyone whose role is only eligible in PIM is on the 1 February date. One team's dates can sit months apart.
- what to do
- Register Authenticator or a token plus email for every admin now. Test each account's reset path, and keep your break-glass accounts documented and separately reviewed.
How Cohash helps
We read your tenant's policies and registration data, sort users into groups by the recovery route that will work for them, and test the result on real accounts before anyone gets a prompt. We also write the helpdesk check and the Temporary Access Pass process, and we plan this alongside the SMS retirement so your people register once. See our Microsoft Entra work, the engineers we place on Entra projects, or start with a free assessment. If your sync servers are part of the same plan, read our Entra Connect Sync and SMS MFA guide.
What to take from this
- 01
Entra's documentation says SSPR only accepts registered methods from February 2027, but the archived notice still says November, so check your own tenant today.
- 02
Register people on methods that survive April, usually an app or token plus email, and test that pair against your policy first. Microsoft's SMS and voice stop counting for SSPR too.
- 03
Passkeys don't satisfy SSPR. Allow password change after secure sign-in helps those users, but only if they can still sign in.
- 04
Two-method policies are getting tight, because Authenticator and OATH tokens count as one. Test your policy in a pilot.
- 05
Give students and frontline staff a named route with staff cover, and harden the helpdesk check before calls increase.
01When does Entra password reset stop taking the phone number in the directory?
Microsoft's documentation, updated 5 November 2026, says February 2027 without naming a day. The public archive copy of Message Center post MC1325414 still shows November 2026. Check the post in your own admin center and test one unregistered account, because the date has moved before.
02Will my users get locked out of their accounts?
Not on the day. People who know their password keep signing in. The trouble starts when someone with no registered method forgets their password, because the reset fails and they have to contact an administrator.
03How do I find out who's affected?
Microsoft points to User registration details under Authentication methods. Look for people enabled for SSPR but not registered, then check a sample by hand, because the notice doesn't say how the report treats unregistered directory values. Disabled accounts aren't listed, and data can lag by up to 36 hours.
04Should users register a phone number?
Only if you've got a plan for what follows. Microsoft-provided SMS and voice stop counting for SSPR 50 days after the sign-in retirement reaches your tenant. A phone number makes sense for recovery if you've set up a telephony provider. Otherwise, go with an app or token plus email, and test that against your policy. Users also can't add SMS or voice once the rollout reaches your tenant.
05We've moved to passkeys. Do they count for password reset?
No. Microsoft says passkeys alone don't satisfy SSPR. If those users need a password for older apps, look at Allow password change after secure sign-in, which needs Entra ID P1 or P2. It only helps people who can still sign in, and it applies to the whole tenant.
06Do admins get treated differently?
Yes. Admins get a fixed two-gate policy: two pieces of data, no security questions, and you can't change it. Microsoft's notice doesn't exempt them from this rule either. Active Global Admins stay on SMS and voice for longer: for SSPR, until 50 days after the July 2027 rollout.
07Can I just bulk-add the numbers I already have as authentication methods?
Admins can add methods, but Microsoft doesn't say outright that this meets the new rule, so test it on one account first. Even if it works, you'd be copying the same old HR data into the field meant to prove identity.
08Is there anything I need to buy?
Often not, if your plan already includes SSPR. Registering Authenticator and email shouldn't need anything else. Hardware tokens or a telephony provider cost money if you choose them, and the Usage and insights reports need Entra ID P1 or P2. Password writeback for synced users also needs the right plan.
Three questions, about a minute
Pick an answer and we'll tell you if it's right, and why it is or isn't. The score stays in this browser.
-
Q1Your users have mobile numbers synced from AD and never opened Security info. What happens when the rule is on and one forgets a password?
show the answer
B. They can't finish the reset, so someone in IT has to help The old mobile number doesn't count, so they can't finish the reset and someone in IT has to step in. Nobody's account gets disabled. They can keep signing in right up until they forget the password.
-
Q2You're planning a February push to get every mobile registered for texts. What goes wrong?
show the answer
D. People may not be able to add SMS by then, and it stops counting for SSPR anyway Once the rollout reaches your tenant, users can't add SMS or voice methods, and existing ones stop counting for SSPR after 50 days, unless you've set up a telephony provider. Register methods that survive.
-
Q3Someone has a passkey and Authenticator, and nothing else. Your SSPR policy needs two methods. Can they reset a forgotten password?
show the answer
C. No, passkeys aren't on the SSPR list, so they're one method short Passkeys don't satisfy SSPR, and Authenticator counts as one method with OATH tokens. They need something else, such as a registered email, or the password change setting for people who can still sign in.