Your SSPR Is About To Stop Working — Jonathan Edwards
WATCH IT.
Named dated change, a control you can audit in your tenants today, with a five-minute Entra demo showing exactly where to look.
Topics covered
- SSPR registered-methods-only — a real, dated Entra change, but the exact date is contested even in Microsoft's own docs. ! Video says enforcement is 9 Nov 2026; the live Microsoft Learn page and a third-party MC mirror give three different day numbers for the same change (see Verification).
- Root cause — "name tag" vs "registered" method. A phone number synced into
mobilePhone/businessPhone/otherMailsfrom on-prem AD (or typed in once) looks identical to a verified authentication method in the portal, but SSPR has been accepting both. After enforcement it accepts only the verified one. - 86% of SSPR verifications already use registered methods — confirmed by Microsoft's own Message Center post; the other 14% is your at-risk population.
- Pairs with the SMS/voice MFA retirement (1 Feb 2027) — fixing an unregistered phone number by re-registering the same phone number just re-solves for a method that's also being retired in three months. Register a passkey instead to fix both in one pass.
- Demo: Entra admin center → Identity → Authentication methods → User registration details → filter by "SSPR capable" and by method type (e.g. passkey) to find who's exposed, tenant by tenant.
- Registration campaign nudges start 5 Oct 2026 per Microsoft — the one date every source agrees on.
Worth your time if / skip if
Worth your time if: you run MSP tenants and want the exact admin-center path to find at-risk users before the deadline, whichever day it lands on. Skip if: you already have a registration-campaign policy live and passkey-only rollout in progress — the demo tells you nothing new.
Bottom line
A real Entra Secure Future Initiative change is landing on your tenants in October/November 2026: SSPR will stop trusting an unregistered phone number sitting on a profile and will only accept methods a user has actually proven they control. The mechanism and the audit path are solid and worth five minutes. The specific enforcement date in the video should not be trusted without a fresh check closer to the time — see below.
What it actually says
| Time | Content |
|---|---|
| 0:00 | Cold open — Charles can't do SSPR because his "registered" phone was never actually registered |
| 1:27 | The name-tag vs registered-method distinction explained |
| 2:25 | What's changing: SSPR stops accepting unregistered directory data |
| 2:43 | Ties to SMS/voice MFA retirement — register a passkey to solve both at once; 86% stat |
| 4:12 | Demo — Entra admin center, User registration details, filtering by SSPR-capable and by method |
Verification
| Claim | Verdict | Source |
|---|---|---|
| SSPR will stop accepting unregistered directory-sourced contact info (mobilePhone/businessPhone/otherMails) | Confirmed — the mechanism is real | Microsoft Learn: Prepopulate Contact Information for SSPR |
| Enforcement date is 9 Nov 2026 | Unconfirmed / contradicted. Three sources give three different pictures: an early MC1325414 archive gives campaign 6 Jul 2026 → enforcement 7 Sep 2026 (already superseded — that date is tomorrow relative to today and clearly didn't happen); a mirror of an updated MC1325414 gives campaign 5 Oct 2026 → enforcement 7 Nov 2026; the live Microsoft Learn page (updated 4 Aug 2026) states campaign nudges from 9 Nov 2026 and enforcement from 5 Oct 2026 — the opposite order, which reads like a documentation error since a nudge campaign following enforcement makes no operational sense. The one date all current sources agree on is 5 Oct 2026 appearing somewhere in the sequence. | mc.merill.net MC1325414, Microsoft Learn (live, updated 2026-08-04), m365admin.handsontek.net archive of original MC1325414 |
| 86% of SSPR verifications already use registered methods | Confirmed | Same MC1325414 sources above |
| SMS/voice MFA retirement is 1 Feb 2027, passkeys become default from 1 Sep 2026 | Confirmed | Microsoft Learn: Passkeys by default and retirement of SMS/voice |
| Registration campaign nudges affected users from 5 Oct 2026 | Confirmed as a date that appears in the sequence — but see above, it's not clear whether this is the nudge date or the enforcement date | as above |
What it left out or got wrong
The video states a single, confident enforcement date (9 Nov 2026) with no hedge. That confidence isn't earned — Microsoft's own current documentation contradicts itself on the order of the two dates, and an earlier version of the same MC post had entirely different (already-passed) dates, meaning this has already been revised at least once. Anyone actioning this from the video alone risks working to the wrong deadline. The video also doesn't mention that new tenants created after 5 Jan 2026 have no legacy directory-sourced SSPR path to lose in the first place — this change matters most for older tenants.
Quontiant angle
A tenant-wide "SSPR capable + method type" scan is exactly a Graph-queryable, read-only check (authenticationMethods via /users/{id}/authentication/methods, AuditLog.Read.All/UserAuthenticationMethod.Read.All scope per Learn's permissions table). CIPP already surfaces authentication-method coverage in its standards reports, so this is not a moat — it's a real, actionable check but a commodity one. Worth queuing as a candidate anyway since the deadline gives it urgency; see check-candidates.md.
For you
Before you act on the November date, re-check the live MC1325414 message in your own tenant's Message Center — do not schedule client comms off this video or off this brief. The audit path (Entra admin center → Authentication methods → User registration details, filter SSPR-capable) is safe to run today regardless of the date confusion, and registering a passkey instead of a phone number is the correct fix either way.
Coverage and confidence
Read the full transcript (909 words, clean auto-captions, no wpm warning) and the author's chapters — they agree with the narration, nothing extra found there. Did not open any frames or run screenread (talking-head cold-open plus a live portal demo described but not screen-read this run — worth a screenread pass if this gets escalated). Verified against Microsoft Learn, a Message Center archive site, and a second independent MC mirror. Confidence the underlying mechanism is real: 0.9. Confidence in the specific date named in the video: 0.3 — genuinely unresolved even at the source.