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 the Microsoft-managed passkey Registration Campaign.
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 still displays the superseded July 6 / September 7 sequence. The current security-updates post uses October 5 prompting and November 9 enforcement. Current Learn guidance and its public GitHub source place the registration campaign on November 9 but explicit-method enforcement on October 5. MC1325414 places the campaign on October 5, enforcement in its rollout body on November 7, and November 9 in its title, summary, and action language. The linked MC1325414 copy is a community archive of a tenant-private Message Center notice, not a Microsoft publication.

The implementation sequence still warrants 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. For conservative planning, complete explicit-method readiness by October 5, the earliest enforcement date in current updated public guidance, and confirm the final sequence before rollout.

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, generally available since May 2026, offers a separate total-loss path when a user loses every registered authentication method. It uses a third-party identity-verification provider, Verified ID, and Face Check; after successful verification, the user receives a limited-validity Temporary Access Pass to re-enroll methods. It is not an SSPR method. Production planning should account for Entra ID P1 licensing and configuration prerequisites, provider pricing through Microsoft Security Store, and privacy, data-retention, and regional-compliance review for government-ID and biometric processing.

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. Microsoft sets the passkey Registration Campaign to Microsoft managed.
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 passkey 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. Tenant-private MC1325414, as reproduced by the community archive, says the SSPR registered-method change applies to Public, GCC, GCC High, and DoD. Confirm the notice and rollout details in your own tenant’s Message Center, and verify 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 strongest single registration-report field for current SSPR policy capability. It does not prove that an end-to-end reset succeeded, and it cannot predict which methods will remain after SMS, voice, or security questions retire.

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 script 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?

Authentication Methods Activity and the related Usage and insights APIs require Microsoft Entra ID P1 or P2.

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 unresolved rather than “unregistered.”

What the Controlled Tenant Showed

The following aggregates describe retained private tenant evidence. The collection scripts and detailed evidence are not publicly published, so readers cannot independently reproduce these historical counts from a linked source bundle. They illustrate the method/registration distinction and do not certify any reader’s tenant or a completed future rollout.

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.

On August 12, a fresh read-only collection returned all 23 rows with an August 10 report timestamp at about 02:22 UTC. That dated snapshot retained the same distribution: 3 Ready, 2 AtRisk, and 18 NotInScope. Microsoft says most registration-report rows update within 36 hours, while occasional rows can take longer. Because the report snapshot was about 64.7 hours old when collected, our conservative 48-hour gate withheld a current readiness verdict. The cohort below publishes the known August 10 snapshot states and labels them as dated evidence rather than presenting them as current tenant status.

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. The event was absent from the earlier activity snapshot and present in the later one. 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 …

13 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 …

21 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