Microsoft Entra

Entra SMS and voice MFA retirement: what to do

Plan for Microsoft Entra's staged SMS and voice MFA retirement: dates, passkeys, guest scope, recovery and a careful rollout checklist.

Published 13 November 2026

Sources checked: 13 November 2026. Microsoft documents a staged retirement of its SMS and voice delivery for Microsoft Entra MFA. The public schedule includes passkey enablement, a supported-provider setup date, and two retirement dates for different user groups. This Entra SMS and voice MFA retirement guide summarizes those public pages; it does not inspect a tenant or verify which users are affected. Microsoft Learn pages are living documents, so confirm the current wording before making a change. The private Message Center item MC1450133 was not checked.

Short answer

Do not switch off SMS or voice as the first step. Find the groups that rely on Microsoft-provided telephony, consider Microsoft Entra passkeys or another method by user and device, arrange recovery, pilot the relevant policies, and only then plan removal. Microsoft also documents a supported telephony-provider route for organizations that need to continue using SMS or voice. That route is separate from moving to a different authentication method.

The dates apply to Microsoft-provided delivery, not necessarily every provider. Most users are listed for 1 February 2027; Global Administrators and external users are listed for 1 July 2027. Internal guest users remain in the February group.

What changes, and when

Microsoft date	Publicly documented event	What to plan
1 September 2026	Users enabled for SMS or voice in the Authentication methods policy or legacy MFA settings are automatically enabled for passkeys. Microsoft describes a nudge after users next sign in and complete MFA; snoozes are unlimited by default.	Enablement is not completed registration. Campaign eligibility, policies and sign-in conditions matter; the nudge can be snoozed without a fixed limit.
30 October 2026	Organizations that need SMS or voice can begin configuring a supported telephony provider through Microsoft Security Store.	Decide whether a supported provider is part of the plan. The date does not mean a provider is configured.
1 February 2027	Microsoft-provided SMS and voice retirement applies to users other than Global Administrators and external users. Internal guest users remain in this group.	Most workforce users and internal guests need a tested alternative or a supported-provider plan.
1 July 2027	The later Microsoft-provided telephony retirement applies to Global Administrators and external users.	These groups have a later date, not a general exemption.

The dates describe different events rather than conflicting deadlines: passkey enablement, provider configuration availability, then telephony retirement. Microsoft's transition guidance is the main schedule; its FAQ clarifies group scope and provider exceptions. Microsoft says affected users whose only available MFA method is SMS or voice may encounter a blocking passkey-registration prompt after the applicable retirement date. Microsoft's FAQ says users who already use another phishing-resistant method, users who registered TOTP, and users migrated to a configured telephony provider before their date do not receive that blocking prompt. Microsoft also describes a temporary tenant opt-out, set through a beta Graph setting, from the automatic passkey enablement and registration campaign for the 1 September 2026 to 1 February 2027 changes. It does not apply from 1 February 2027, and Microsoft says there is no opt-out from the retirement enforcement itself. Do not use the blocking prompt or the opt-out as a migration strategy; prepare and validate beforehand.

Who needs a review

Start by sorting people by identity type, current method, device, sign-in need and recovery route. Do not assume a single answer for everyone.

Users with only SMS or voice available: confirm whether they have another registered method, what the Authentication methods policy permits, what Conditional Access requires, and how they recover access. A registration record alone does not prove that sign-in will succeed.
Global Administrators and external users: Microsoft's retirement schedule lists these for July. Internal guest users remain in the February group, so distinguish internal guests from external identities rather than treating all guests alike.
B2B collaboration guests: Microsoft's workforce-tenant FIDO2 guidance says registering passkeys is not supported for internal or external guest users, including B2B collaboration guests, in the resource tenant. A separate External ID customer-tenant guide documents a different product context. Microsoft's retirement FAQ, read on 13 November 2026, says passkey support for B2B and internal guest users is planned to be available by the end of calendar year 2026, without an exact date, so recheck both pages before planning guest rollout.
Shared and kiosk devices: Microsoft's deployment guide says Windows Hello for Business should not be used with a kiosk using one shared user account. It points shared-device users toward Entra passkey on Windows or portable credentials. The documented WHfB limit of up to 10 users per device is specific to WHfB, not a universal kiosk limit.
People without compatible devices, federated users, emergency-access accounts and service-like accounts: mark these for an owner-led review. The sources used here do not establish a universal method or exemption for them.

What phishing-resistant means

NIST defines phishing resistance by whether authentication secrets or valid outputs can be disclosed to an impostor verifier “without relying on the vigilance of the claimant” (NIST SP 800-63B-4). The current NIST guidance emphasizes cryptographic authentication and verifier or channel binding. This describes security properties; it does not certify that a method is correctly configured in a particular tenant. CISA's October 2022 fact sheet groups FIDO/WebAuthn and PKI-based MFA among phishing-resistant implementations. That is older general guidance, not an Entra-specific rollout statement.

Microsoft's built-in Conditional Access authentication-strength table lists method combinations as follows:

Method	Multifactor MFA	Passwordless MFA	Phishing-resistant MFA
FIDO2 security key	Yes	Yes	Yes
Windows Hello for Business or platform credential	Yes	Yes	Yes
Multifactor certificate-based authentication	Yes	Yes	Yes
Authenticator phone sign-in	Yes	Yes	No
Temporary Access Pass, one-time or multiple-use	Yes	No	No

This table summarizes Microsoft's authentication strengths documentation; it is not a judgment about your configuration. Microsoft says Conditional Access evaluates authentication strength after initial authentication and lists Entra ID P1 as a prerequisite. Verify current licensing and policy requirements before planning enforcement.

A documented rollout sequence

Use this as a planning checklist, not as a universal configuration recipe. Portal labels and supported paths can change. The linked Microsoft pages are the source for current product instructions.

Inventory dependencies. Review Authentication Methods Activity and Microsoft's Graph `userRegistrationDetails` report. The endpoint documents GET /reports/authenticationMethods/userRegistrationDetails and fields such as isMfaRegistered, methodsRegistered, isPasswordlessCapable and isSsprRegistered. Its permission table lists delegated AuditLog.Read.All; the application permission is unavailable for this endpoint. These data describe registration, not policy enforcement or successful sign-in. The report excludes disabled users; Microsoft's activity report notes explain that report data can lag. Cross-check Authentication methods, legacy MFA and SSPR policies using Microsoft's migration guide. Record only the information needed to plan.
Communicate by audience. Explain the date that applies, the registration experience, support route and recovery process. Keep separate guidance for employees, internal guests and external identities. Do not say that a nudge means registration is complete.
Choose methods and policy profiles. Microsoft documents passkey profiles in the Authentication methods policy. Review method eligibility, device support, target groups and profile settings in its FIDO2 passkey guidance. Authenticator passkeys have a separate enablement path and documented platform requirements; see Authenticator passkey guidance. Pilot with representative devices and identities.
Use registration campaigns carefully. Campaign states, targets and eligibility affect prompts. Microsoft's registration campaign guide describes nudges for Authenticator or passkeys and the conditions that apply. Do not promise a prompt at every next sign-in. Check the intended target group and policy before enabling a campaign.
Plan recovery before rollout. Microsoft's Temporary Access Pass guide documents time-limited, single-use and multiple-use TAP options and method-registration scenarios. It also says the described admin-center/Graph process cannot issue TAP to external guest accounts. Decide who verifies identity, issues recovery and supports lost devices; do not assume TAP fits every identity.
Pilot Conditional Access strength. Select a built-in strength that matches the documented methods and test a limited group, relevant apps, recovery and fallback. The source set does not verify an exact portal path for report-only deployment. Confirm Microsoft's current policy instructions and licensing before using that mode; review outcomes before considering broader enforcement.
Decide whether to use a supported telephony provider. If SMS or voice remains necessary, verify the provider and current Microsoft Security Store process against the transition page. Otherwise, complete the alternative-method and recovery plan. Provider setup availability is not evidence that setup is finished.
Remove legacy methods in stages. Microsoft's migration guide says to update the unified Authentication methods policy, then remove methods from legacy MFA and SSPR policies one by one. Validate registration, recovery, guest treatment and support readiness before each change. Check the current retirement schedule rather than relying on a copied date.

Edge cases and recovery

Guest identities: Microsoft places internal guest users in the February group and external users in the July group. Workforce-tenant FIDO2 registration guidance differs from Entra External ID customer passkeys. Check the identity model and collaboration flow before assigning a method.

Shared devices: Do not select Windows Hello for Business for a kiosk that uses one shared user account. Microsoft's deployment guidance points shared-device users to portable credentials or Entra passkey on Windows. Test the actual sign-in and sign-out design; the WHfB user limit is not a universal approval for a kiosk pattern.

No compatible device or smartphone: the sources list methods including FIDO2 keys, Windows Hello for Business, platform credentials and certificate-based authentication, but suitability depends on device, user and policy. Mark unsupported cases for review rather than assuming an exemption.

Emergency access and service-like accounts: the source set does not establish a definitive method or exemption. Check current Microsoft guidance and the organization's documented recovery design before changing these accounts.

Lost device: Microsoft recommends more than one registered authentication method in deployment guidance and documents TAP for some bootstrap flows. Decide who can verify identity and support recovery; a second method and TAP are not interchangeable.

Frequently asked questions

Does SMS stop for everyone on 1 February 2027?

No. Microsoft lists most users, including internal guest users, for February. Global Administrators and external users have the July date. The schedule concerns Microsoft-provided telephony; a supported-provider path is documented separately.

Are users moved to passkeys automatically on 1 September 2026?

Microsoft says users enabled for SMS or voice in the Authentication methods policy or legacy MFA settings are automatically enabled for passkeys. It describes a nudge after users next sign in and complete MFA. A nudge is not completed registration, and default snoozes are unlimited.

Does a registered passkey prove the account is phishing-resistant?

No. Microsoft's authentication-strength table lists method combinations, and policy must allow and require an appropriate strength. The table does not inspect a tenant's configuration or prove a particular sign-in path.

Can B2B guests register workforce passkeys?

The reviewed FIDO2 guidance says internal and external guest users, including B2B collaboration users, cannot register in the resource tenant. Entra External ID customer passkeys are a distinct context. Microsoft's retirement FAQ says passkey support for B2B and internal guest users is planned by the end of calendar year 2026, with no exact date given, so treat guest passkeys as not yet confirmed and recheck Microsoft's pages.

Is Microsoft Authenticator phone sign-in phishing-resistant?

Not in Microsoft's built-in strength table. It appears under Multifactor MFA and Passwordless MFA, but not Phishing-resistant MFA. Authenticator passkeys are a separate method and profile; check their policy and platform requirements.

Can TAP be the backup for every user?

No universal fit is documented. The TAP guide describes single-use and multiple-use options and says external guest accounts cannot be issued TAP through its described admin-center/Graph process. Check the identity type and recovery design.

Does the registration report show who can sign in successfully?

No. userRegistrationDetails reports registration properties. It does not prove Conditional Access enforcement, device compatibility or sign-in success, and disabled users are excluded from the report.

Should we remove SMS today?

This guide cannot decide that for a tenant. First verify users, policies, registration, recovery, device support and any supported-provider path. Remove methods only through a tested, owner-approved sequence consistent with Microsoft's current instructions.