Skip to content
CloudRunbook logo
Start Here

Identity · Runbook

Entra SSPR registered methods change: check coverage

• 7 min read

MC1325414 says Entra SSPR will stop accepting some directory attributes. What it says, where Microsoft's dates disagree, and how to check registration coverage.

  • Rollback: Not confirmed

Applies to: Microsoft Entra

Identity Entra SSPR Authentication methods Change
On this page
  1. What changed
  2. The dates do not agree
  3. Who is affected
  4. Why it matters
  5. What Learn says about registration
  6. Runbook
  7. Checks
  8. Rollback
  9. Common pitfalls
TL;DR

Entra ID SSPR will require registered authentication methods. Per Message Center MC1325414, directory attributes such as mobilePhone, businessPhone and otherMails will not be valid for SSPR verification unless they are registered as authentication methods. Microsoft’s dates for this disagree. The MC post gives enforcement as on or around 9 November 2026, and also lists 7 and 6 November. It lists 5 October 2026 as the registration campaign start date, so check in your tenant’s Message Center and sign-in logs where the campaign stands and whether users are being prompted. Aim to finish your registration coverage and helpdesk readiness work before the earliest date the post lists, 6 November.

Source and what to verify

Checked on 2026-10-15. Sources:

Before you act:

  • Confirm the dates in your tenant’s Message Center. Microsoft’s wording is inconsistent within the MC post (see below).
  • Re-read the full MC post. The text I worked from was an extraction, not a verbatim copy, so wording and the portal path need checking against the original.
  • Check Learn for a dedicated page on this change. The pack I worked from does not say whether one exists, so I have not cited one.
  • Roles and licensing are not confirmed. MC1325414 names no roles and mentions no licensing. Check which admin role you need in your tenant.

What changed

MC1325414 is titled “Microsoft Entra ID SSPR will require registered authentication methods starting November 9, 2026”. The page is marked as updated on 4 August 2026. Per the MC post, directory attributes (such as mobilePhone, businessPhone, otherMails) will no longer be valid for SSPR verification unless they are registered as authentication methods.

The MC post tells admins to make sure every user, including admins, has at least one registered authentication method that satisfies your SSPR policy.

The dates do not agree

The MC post gives different dates in different places:

WhereWhat it says
MC1325414 titleStarting 9 November 2026
MC1325414 body”Action is required before November 9, 2026”
MC1325414 rollout section”November 7, 2026: Enforcement begins.”
MC1325414 metadata”Action required by” 2026-11-06
MC1325414 campaignLists 5 October 2026 as the registration campaign start

I am not picking a winner. Microsoft’s own wording is inconsistent. Confirm in your tenant’s Message Center.

For the campaign, the MC post gives only that start date. It does not say how the campaign is running in any given tenant, so check your tenant’s Message Center and sign-in logs to see whether it is prompting your users.

Other timing on the MC page: general availability is given as early to mid-November 2026, and the page notes this was previously early September.

Who is affected

Per the MC post (as extracted, so re-check it), the change applies to all users in tenants with SSPR enabled. It lists public cloud, GCC, GCC High and DoD.

You should look at this if:

  • SSPR is enabled and users have never registered methods.
  • Users rely on mobile phone, business phone or alternate email values that sit in the directory but were never registered. Per the MC post, those will not be valid for SSPR verification.
  • Admins rely on SSPR too. The MC post says to include them.

Three things are unconfirmed. The MC post names no specific roles and mentions no licensing, and I have not verified licence requirements for cloud-only versus writeback scenarios. Also, the SSPR deep dive (updated 2026-10-06) does not mention the change. It still describes SSPR using “authentication methods defined”, and its example scenario refers to office phone and alternate email fields being populated. I have not confirmed whether another Learn page covers the change, or exactly how the directory-attribute fallback is removed. Treat the MC post as the source for the change itself.

Why it matters

  • Failure mode: Learn says a user who has not registered the minimum number of methods sees an error page when they try SSPR, and must ask an administrator to reset their password. That lands on your helpdesk.
  • Hidden dependency: a user with a populated phone attribute may look fine in the directory and still have no registered method.
  • Method counting: Learn says Authenticator, software OATH tokens and hardware OATH tokens count as one method for SSPR. A user cannot combine them to meet a two-method requirement.
  • Admins: the MC post says to cover admins as well as standard users.

What Learn says about registration

Learn is the reference for how SSPR registration works. The deep dive says:

  • When a user is enabled for SSPR, they must register at least one authentication method. Microsoft recommends two or more.
  • Learn lists the SSPR methods as Microsoft Authenticator push notifications, hardware OATH tokens (preview), software OATH tokens, SMS, voice call and Email OTP.
  • Users can only reset with a method the administrator has enabled.
  • Learn documents a Require users to register when signing in option. Users can also self-register at https://aka.ms/ssprsetup.

Runbook

  1. Read the original post

    Open MC1325414 in your tenant’s Message Center. Note which dates it shows you and record any difference from the dates above in your change record. Check Learn for any dedicated page on the change.

  2. Work out what your SSPR policy accepts

    In the Entra admin center, review which authentication methods are enabled for SSPR and how many methods your policy requires. Learn says users can only reset with a method you have enabled. I have not confirmed exact portal paths or roles for this, so check them in your tenant.

  3. Measure registration coverage

    The MC post points admins to Authentication methods > User registration details in the Entra admin center. The path comes from an extraction of the page, so confirm it exists as written. Look for users who have no registered method that satisfies your SSPR policy. Include admins and break-glass or service-style accounts that use SSPR.

  4. Mind the method counting

    If your policy requires two methods, check that users are not relying on Authenticator plus an OATH token. Learn says those count as one.

  5. Check the registration campaign

    The MC post covers allowing the registration campaign and lists 5 October 2026 as the campaign start date. Check your tenant’s Message Center and sign-in logs to see where things stand and whether it is prompting your users. Learn documents a Require users to register when signing in option, but I have not confirmed how it relates to the campaign or where the setting lives in the portal, so confirm that in the portal and the MC post. Do not rely on the campaign alone to get users registered.

  6. Tell users how to register

    Point users to My Security Info, as the MC post suggests. Learn also gives https://aka.ms/ssprsetup for self-registration. Send reminders to the users from step 3 who are still unregistered.

  7. Plan helpdesk-assisted fallback

    The MC post covers planning a helpdesk-assisted fallback. Learn says unregistered users must ask an administrator to reset their password, so brief the helpdesk and agree how they verify identity.

  8. Re-measure

    Re-run the registration coverage check after the reminders go out. Chase the remainder, starting with admins.

Checks

  • You have read MC1325414 in your own tenant and recorded which dates it shows.

  • Every user, including admins, has at least one registered method that satisfies your SSPR policy.

  • No user relies on Authenticator plus an OATH token to meet a two-method requirement.

  • Users who only had phone or alternate email values in the directory have registered those as authentication methods.

  • You know whether the registration campaign described in MC1325414 is prompting users in your tenant.

  • Helpdesk know the fallback for unregistered users.

  • A test user can complete SSPR using a registered method.

Rollback

Microsoft has not said, in anything I could check, whether this change can be reversed or opted out of. Do not plan on a back-out. Confirm in your tenant’s Message Center.

If you changed any SSPR or registration setting while preparing, record the previous value first so you can put it back.

Common pitfalls

  • Picking one date. The MC post gives 9 November, 7 November and 6 November in different places, plus 5 October 2026 as the campaign start date. Plan against the earliest, 6 November, and confirm in Message Center.
  • Trusting populated attributes. A phone or alternate email value in the directory does not count unless it is registered as an authentication method.
  • Forgetting admins. The MC post says to include them.
  • Counting Authenticator and OATH as two. Learn says they count as one for SSPR.
  • Reading only the SSPR deep dive. It does not mention the change, so it may read as if directory attributes still work. Read the MC post as well, and check Learn for any dedicated page.
  • Quoting the 86% figure. The MC post cites a statistic about SSPR verifications using registered methods. I could not verify it, so do not rely on it in your own comms.