Updated October 29, 2026
SSPR stops accepting directory-sourced contact info on November 7
MC1325414: SSPR stops accepting directory-sourced phone numbers and emails on November 7, 2026. Authenticator + OATH count as one method, FIDO2 doesn't count at all, SMS/voice is retiring in 2027.
SSPR stops accepting directory-sourced phone numbers and emails on November 7, 2026. Only methods a user explicitly registered under Security info will count from that point.
Key Takeaways
- Directory-sourced contact info (
mobilePhone,businessPhone,otherMails) stops counting for SSPR on November 7, 2026. Registration campaign running since October 5- Microsoft Authenticator + software/hardware OATH tokens count as one single method, not two, for a “require 2 methods” policy
- FIDO2 and Windows Hello for Business cannot be used for SSPR at all, under any policy
- SMS and voice call on one mobile number share one slot, not two. Microsoft is retiring its own delivery for both: Feb 1, 2027 (most users), Jul 1, 2027 (Global Admins, external users)
- Public sources disagree on the exact date (Nov 7 vs. Nov 9 vs. Oct 5). Confirm MC1325414 in your own Message Center
Method coverage at a glance
| Method | Usable for SSPR? | Counts toward “2 required”? |
|---|---|---|
| Microsoft Authenticator / software / hardware OATH | Yes | One shared slot |
| Mobile phone (SMS or voice) | Yes, today | One slot (Microsoft delivery retires Feb 1, 2027) |
| Office phone (voice only) | Yes, today | Separate slot (same retirement) |
| Email OTP | Yes | Own slot |
| Security questions | Yes, non-admin only | Own slot (retiring for SSPR March 2027) |
| FIDO2 / passkey | No | Not usable for SSPR |
| Windows Hello for Business | No | Not usable for SSPR |
The trap: Authenticator + a software OATH token looks like two methods in the portal. It’s one. A FIDO2-only user has zero SSPR methods, not one. A tenant can show 100% SSPR “registered” by headcount and still have users who can’t actually reset a password.
Microsoft’s own documentation confirms the Authenticator/OATH grouping directly: “A user can’t use a combination of these methods to satisfy a requirement for two authentication methods.” A separate note about enabling at least two non-Authenticator methods in the policy configuration is often misread as a per-user rule, it isn’t; a user with Authenticator + one other distinct method is fine.
Check this before November 7
- Confirm the real date for your tenant: search MC1325414 in the Microsoft 365 admin center
- Find directory-fallback users (synced
mobilePhone/otherMails, never registered) and confirm “Require users to register when signing in” is on - Audit your “2 methods required” policy against the table above, not a raw registered-method count
- Identify FIDO2-only users: they have no SSPR path today, independent of this deadline
- Treat SMS/voice registrations as a bridge to clear the two-method bar now, not an endpoint
Check it automatically
Get-SSPRMethodCoverageReport.ps1 reads Microsoft’s own isSsprCapable per user and explains the likely cause (FIDO2-only, single category, nothing registered), plus a separate SMS/voice durability-watch list. Portal alternative: Entra admin center → Authentication methods → Activity → Registration (Entra ID P1/P2 required) shows the same raw data without the cause-explanation or durability check.
Frequently asked questions
Does this affect MFA sign-in, or only password reset? Only SSPR. Authenticator, FIDO2, and every other sign-in method work exactly as before.
A user has Authenticator + a FIDO2 key. Covered for a two-method policy? No better than Authenticator alone. FIDO2 contributes nothing to the SSPR count; they still need two SSPR-eligible methods outside the key.