Hello everyone!
Microsoft is retiring Microsoft-provided SMS and voice authentication delivery in Microsoft Entra ID. For administrators, preparation should begin with understanding user dependencies—not immediately disabling those methods.
This guide highlights three areas to review: authentication methods, passkey registration, and password recovery.
About this walkthrough: Screenshots come from a dedicated non-production tenant containing synthetic test accounts and lab data only. Tenant and account identifiers have been cropped out. No internal Microsoft, customer, or production content is included. No settings were changed during capture.
What changes—and when?
Microsoft’s published public-cloud timeline separates the migration experience from retirement:
| Date | What changes |
|---|---|
| 1 September 2026 | Automatic passkey enablement and registration nudges begin for users enabled for SMS or voice. |
| 1 February 2027 | Microsoft-provided SMS/voice retire for users other than Global Administrators and external users. Internal guests are included in February. |
| 1 July 2027 | Retirement applies to Global Administrators and external users. |
Microsoft also documents a customer-managed telecom continuation path for organizations with justified requirements. See the retirement guidance and FAQ.
Do not confuse the different requirements
| Requirement | What it controls |
|---|---|
| Mandatory MFA | Whether access to a particular service or operation requires MFA. |
| Authentication strength | Which authentication methods satisfy the access policy. |
| Registration campaign | Prompts eligible users to register another method. |
| SMS/voice retirement | Ends Microsoft’s native telecom delivery for the applicable population. |
These controls can apply together. Requiring MFA is not automatically the same as requiring phishing-resistant MFA—or retiring SMS.
References: Azure mandatory MFA and authentication strengths.
1. Find who depends on SMS or voice
Open: Entra ID → Authentication methods → Policies.

Review SMS and Voice call targeting. Then inspect Activity → Registration, Activity → Usage, and User registration details.
Identify users who depend on telecom methods and do not have a usable alternative.
Enabled does not mean registered. Registered does not prove successful use. Reporting can also lag, so zero recent SMS activity does not prove zero dependency.
SMS and voice were already disabled in this lab. Do not copy those settings as your first migration step.
Sources: Method policies and registration and usage reporting.
2. Prepare passkeys before prompting users
Open: Authentication methods → Policies → Passkey (FIDO2).
Review targeting, Allow self-service set-up, and passkey profiles. Plan a representative pilot rather than copying the lab’s broad scope.
Next, open Registration campaign.

Here, Microsoft managed targets passkeys. “Limited number of snoozes: Disabled” means unlimited campaign snoozes—not a disabled campaign.
Unlimited snoozes do not extend the applicable retirement deadline.
Before expanding, confirm that pilot users can register and sign in with the intended method. Explain the expected prompt to users before changing campaign behavior.
Sources: Passkey configuration and registration campaigns.
3. Prepare password recovery separately
Open: Entra ID → Password reset → Properties / Authentication methods.

Check who is enabled for self-service password reset, how many verification methods are required, and which supported methods users have registered.
Passkeys are not an SSPR verification method. Successful passkey sign-in does not prove password recovery is ready.
The screenshot’s None scope is a lab value, not a recommendation. Administrator recovery has separate policy considerations.
Sources: SSPR requirements and authentication-method limitations.
Final takeaway
Before removing an existing authentication method, make sure you can answer four questions:
- Who depends on it, and which deadline applies?
- Can those users register and use an appropriate replacement?
- Can they recover access without the retiring dependency?
- Have exceptions and user communications been addressed?
Inventory first, establish a working alternative, prepare recovery, and then expand the migration.
Information current as of 21 September 2026. Microsoft’s documentation and rollout details may change; consult the linked public sources before implementing changes.
