Entra SSPR and Passkey Readiness for Microsoft-Provided SMS/Voice Delivery Retirement

Microsoft is advancing three related parts of the Entra authentication and recovery experience between now and next March:

1. On September 1, 2026, users enabled for SMS or voice begin moving into Microsoft-managed passkey registration.
2. SSPR is moving toward accepting only explicitly registered authentication methods. Microsoft has updated the rollout timing, and the currently published sources show different October and November sequences.
3. On February 1, 2027, Microsoft transitions away from providing SMS and voice delivery in public-cloud Entra ID. Security questions then retire for SSPR in March 2027.

There is a lot to like in this direction: broader passkey adoption, a clearer registration trust boundary, and less reliance on Microsoft-provided telecom. Because each improvement touches a different workflow, administrators should give sign-in and recovery their own readiness checks.

Passkeys meaningfully strengthen sign-in and MFA. Today, password reset still requires a separately supported SSPR method.

A user may be ready to sign in with a passkey while still needing a supported method for password reset. Similarly, a phone number or alternate email in the directory can provide useful profile data without yet representing a formally registered recovery method.

This post brings the timelines together, explains the evidence administrators need, and offers a practical way to prepare as Microsoft introduces the changes.

Source guidance last verified August 12, 2026. Future rollout behavior is Microsoft-documented rather than treated as a result already observed in the tenant.

A Clear Direction with One Schedule to Recheck

Microsoft revised tenant-private MC1325414 on August 4, moving its planned rollout from early September to early November. The June What’s New announcement retains the earlier July 6 / September 7 schedule. Other current sources reflect the transition at different stages: the security-updates post says October 5 and November 9; current Learn guidance and its GitHub source show November 9 prompting followed by October 5 enforcement; and MC1325414 uses October 5 for the campaign, November 7 in its rollout body, and November 9 elsewhere. The linked MC1325414 copy is a community archive of a tenant-private Message Center notice, not a Microsoft publication.

The implementation dates still warrant a fresh check, but the design direction is consistent across the sources: SSPR will rely on explicitly registered methods rather than unregistered directory contact data. I retain September 7 as a deliberately conservative internal readiness target, not as Microsoft’s current expected enforcement date.

Passkey Readiness and SSPR Readiness Are Different

Microsoft’s current authentication-method matrix helps clarify the two readiness tracks. It lists passkeys, synced passkeys, Windows Hello for Business, certificate-based authentication, and Temporary Access Pass as unavailable for SSPR.

Authenticator push, software OATH, hardware OATH tokens in preview, and email OTP can support SSPR when policy permits them. SMS and voice can support it only while a delivery path remains. Security questions remain a legacy end-user option until their March retirement.

That creates two separate questions:

• Sign-in and MFA: Can the user register and successfully use a durable replacement, preferably a passkey or another phishing-resistant method, without Microsoft-provided SMS or voice?
• SSPR continuity: Will the user still have enough explicitly registered, policy-allowed SSPR methods after telecom delivery and security questions are removed?

Microsoft Entra Account Recovery offers a valuable third lane for loss of all registered methods. It uses identity verification and Verified ID to issue a limited Temporary Access Pass for method re-enrollment. Because it is a distinct recovery workflow rather than another SSPR method, assess it alongside the sign-in and SSPR readiness tracks.

What the September 1 Change Enables

Microsoft’s SMS and voice retirement guidance describes a policy migration rather than an immediate passkey mandate:

1. Users enabled for SMS or voice through the Authentication Methods Policy or legacy MFA settings are enabled for passkeys.
2. Microsoft assigns those users an all-passkey-types profile.
3. Registration Campaign moves to Microsoft managed and targets passkeys.
4. Eligible users can then be prompted to register during a later sign-in.

The prompt begins the registration journey, and a successful experience still depends on AAGUID rules, attestation requirements, device and browser support, Conditional Access for Register security information, terms of use, and a valid MFA bootstrap. A tenant can target one method in Registration Campaign at a time, so plan the transition from an existing Authenticator campaign to a passkey campaign deliberately.

The September auto-enablement population is tied to SMS- or voice-enabled users. Separately, Microsoft says Microsoft-managed Registration Campaign targeting is gradually expanding from voice/text users to all MFA-capable users. Review campaign exclusions and the user experience beyond the initial SMS/voice cohort.

The temporary opt-out requires Policy.ReadWrite.AuthenticationMethod. Microsoft documents this beta Graph request:

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json

{
  "optOutSettings": {
    "passkeyDynamicMigration": true
  }
}

The property name deserves a careful read: true means opt out of the automatic September migration. This setting applies to the September automation; the February retirement remains on its own schedule.

Two population details deserve separate planning:

• The retirement timeline currently applies to public-cloud tenants. MC1325414 says the SSPR registered-method change applies to Public, GCC, GCC High, and DoD, so confirm scope for each announcement independently.
• B2B and internal guests are included in the telecom retirement, but current Registration Campaign guidance says guests are not nudged for passkeys. Microsoft says guest passkey support is planned by the end of 2026.

A later tenant-private Message Center notice, MC1450133 as preserved by a community archive, announces a mid-October-to-mid-November phase in which eligible password-only users can register supported passkeys as their first MFA method. While public guidance is being completed, retain a controlled bootstrap path and validate the experience with representative users under the tenant’s actual policy.

Profile Data and Registered Methods Serve Different Purposes

The portal can show the same phone number in more than one context, so it helps to distinguish profile contact data from authentication-method registration.

Microsoft currently documents a helpful bridge in which a prepopulated mobile phone or alternate email can be used before the user completes registration. The announced design makes explicit registration the authoritative path for future SSPR eligibility.

Include Office phone in the transition review. On-premises telephoneNumber synchronizes to businessPhones, which appears as Office phone, and Office phone supports voice calls only. Even where office numbers are broadly populated, teams still need to account for the move to explicit registration and the later retirement of Microsoft-provided voice delivery.

Updating the /users/{id} profile property mobilePhone with Graph, or populating it through synchronization, remains profile maintenance rather than authentication-method registration. Complete the transition through a supported user or administrator registration experience.

The registration report exposes three related but different flags:

• isSsprEnabled: policy permits SSPR for the user;
• isSsprRegistered: the user has registered the required number of methods; and
• isSsprCapable: the user currently has enough registered, allowed methods to use SSPR.

isSsprCapable is the best current SSPR signal. For retirement planning, supplement it with a future-state count of the methods that will remain available.

Start with the Microsoft Analyzer, Then Add User Evidence

Microsoft’s open-source Entra SMS/Voice Policy Scanner (microsoft/entra-sms-voice-usage-analyzer, implemented as Get-SmsVoicePolicyUsers.ps1) gives administrators a useful, repeatable first view of Registration Campaign state and SMS/voice policy targets.

As of August 12, the scanner README and output refer to January 28, 2027, while current Microsoft Learn retirement guidance says February 1, 2027. Align planning to the current Learn date and use the scanner for its intended policy-scope role.

The scanner focuses on policy configuration. Complete the readiness view by adding effective group membership, residual legacy MFA and SSPR settings, per-user registration, recent method use, and separate passkey and SSPR validation.

A practical inventory uses at least three evidence layers:

1. Policy: Who is effectively targeted through modern and residual legacy settings?
2. Registration: Which methods does each user have, and is the user currently SSPR-capable?
3. Observed use: Which methods appear in recent Authentication Methods Activity and sign-in Authentication Details?

For population-level SSPR review, start with two Graph reads:

GET /v1.0/users?$select=id,accountEnabled,userType,mobilePhone,businessPhones,otherMails
GET /v1.0/reports/authenticationMethods/userRegistrationDetails

Join them by the Entra user object ID (id) returned by both datasets and reduce phone and email values to presence signals before saving output. Keep in mind that Authentication Methods Activity can lag, so treat a missing recent event as inconclusive rather than evidence of non-use.

Follow every returned @odata.nextLink for both collections; /users returns 100 objects by default. Plan a separate classification for disabled and soft-deleted users because the userRegistrationDetails list API does not support disabled users and the portal omits both populations. Treat a missing registration-report row as an unknown state rather than “unregistered.”

What the Controlled Tenant Showed

The live review was read-only by design. Future rollout behavior and the directory-only reset path remain clearly labeled for validation after the change reaches the tenant.

Our audit classified the August 5 registration snapshot of 23 users as 3 Ready, 2 AtRisk, and 18 NotInScope. Those are audit-defined states, not native Microsoft report values; they were derived from fields such as isSsprEnabled, isSsprRegistered, and isSsprCapable. We used a conservative 48-hour freshness gate because Microsoft says most registration-report rows update within 36 hours, while occasional rows can take longer. When the same collection was evaluated again on August 8, 22 stale rows were classified as Unknown to preserve that freshness standard; the one current row remained AtRisk with no registered method. A follow-up read-only run on August 9 found the same 22 rows still awaiting refresh, so they appropriately remained Unknown.

The portal showed SSPR enabled for a dedicated four-member validation group with one end-user method required. Registration Campaign was Microsoft managed and still targeted Microsoft Authenticator. SMS, voice, and passkeys were disabled in the current Authentication Methods Policy. A separately completed SSPR transaction by an administrator account later appeared in event history as successful with Authenticator push, confirming that the earlier activity snapshot had reporting latency. The audit did not capture notification delivery or a post-reset sign-in.

The four controlled states separated directory contact from registration:

This evidence demonstrates the distinction between profile data, registered methods, and current report state. Its scope is intentionally limited; future enforcement behavior, actual SMS/voice dependency, passkey usability, hybrid writeback, notification delivery, and Account Recovery completion remain separate validation tasks.

A Practical Two-Track Plan

Track 1: Guide sign-in and MFA toward durable methods

1. Map effective scope. Review SMS and voice targets in the Authentication Methods Policy, effective group membership, and residual legacy MFA settings. Keep policy targeting and observed user activity as separate evidence.
2. Separate registration from use. Combine per-user registration with recent method-level sign-in evidence where available. Treat “SMS/voice only” as a conclusion that requires both a complete method inventory and the absence of a usable alternative.
3. Pilot passkeys end to end. Validate profile assignment, registration, representative devices and browsers, Conditional Access, and a real sign-in. Keep Temporary Access Pass or another controlled identity-proofing path for bootstrap until MC1450133 behavior is available and tested.
4. Design for exceptions. Give guests, emergency accounts, service accounts, unsupported devices, and infrequent users clear workstreams. Evaluate a customer-managed telecom provider when published details, coverage, and costs fit the requirement.

Track 2: Maintain SSPR continuity

1. Model the future method count. Remove Microsoft-provided SMS and voice from the February scenario and security questions from the March scenario. Count only explicitly registered methods that remain supported and allowed for SSPR.
2. Complete supported SSPR registration. Treat directory properties, passkeys, Windows Hello, CBA, TAP, and Account Recovery according to their documented roles, and make sure each user has a supported SSPR method.
3. Review special recovery paths. Administrators, hybrid password writeback, federated users, and total-loss Account Recovery each need representative testing outside the normal end-user flow.
4. Allow for reporting latency and rerun. A completed registration is not current registration-report evidence until the reporting plane catches up; the transaction itself can still be separate operational evidence. Rerun after each rollout reaches the tenant instead of projecting today’s result into February or March.

Use Separate Readiness Signals

At minimum, report these decisions separately:

• Passkey/sign-in ready: a durable method is registered and successfully used under the intended device and Conditional Access conditions.
• SSPR report-capable: a current registration-report row says the user is enabled, registered, and capable.
• SSPR operationally validated: a representative reset succeeds end to end, including post-reset sign-in, writeback where applicable, and expected notification behavior.
• SSPR projected capable after retirement: enough explicitly registered, allowed SSPR methods remain after telecom delivery and security questions are removed.
• Exception assigned: any remaining telecom, guest, hybrid, administrator, or total-loss recovery requirement has an owner and a tested path.

Microsoft’s passkey expansion advances phishing-resistant authentication, while explicit registration strengthens confidence in SSPR data. The telecom and security-question retirements also provide a natural point to modernize recovery paths. Because these improvements affect different controls, the clearest readiness view keeps their outcomes separate.

Use the policy scanner as the first layer, add registration and use evidence, pilot passkeys, and maintain an independent supported SSPR method. Completing these checks early gives users a smoother transition and gives the help desk clear options for both sign-in and password recovery.

Jerrad Dahlager, CISSP, CCSP

Cloud Security Architect · Adjunct Instructor

Marine Corps veteran and firm believer that the best security survives contact with reality.

Have thoughts on this post? I'd love to hear from you.

LinkedIn Email Me

You might also like

Identity Security

March–June 2026 Entra ID Changes: Passkey Profiles and Conditional Access Enforcement

Audit Entra passkey-profile migration and the June 2026 Conditional Access …

10 min read

Identity Security

Just-In-Time Access for AI Agents: Building a ZSP Gateway in Azure

Build an Azure gateway that grants service principals and managed identities …

15 min read

Cloud Security

From Authorization to Action: Operationalizing CISA's Microsoft Cloud Logs Playbook in Sentinel

Map CISA's Microsoft cloud logging guidance to Entra, Purview, Microsoft 365, …

12 min read