Microsoft Entra ID Retires SMS and Voice Delivery in 2027

BleepingComputer reported Microsoft’s renewed reminder on September 21. Windows Report subsequently identified Microsoft 365 Message Center advisory MC1474104 as the latest notice; that identifier is not independently confirmed in the public Microsoft documentation available here. The underlying retirement, however, is documented by Microsoft, including a distinction that the broad “February 2027 deadline” misses: Global Administrators and external users have until July 1, 2027.

For administrators, this is a scheduled authentication change with consequences for registration, sign-in, password reset, and—in organizations retaining SMS or voice—procurement and support. Microsoft has already started the transition toward passkeys. There is still time to manage the user experience before registration becomes an interruption to accessing work.

Entra ID’s SMS retirement has two deadlines, not one​

Microsoft’s retirement guidance establishes separate stages for automatic passkey enablement and the withdrawal of Microsoft-provided telecom delivery. The September stage prepares users to move. The February and July stages enforce the change for different populations. Treating those stages as interchangeable risks both premature alarm and misplaced confidence.

Microsoft’s July announcement described September 1 as the beginning of a rollout: affected users are enabled for passkeys as the rollout reaches their organization. It did not establish that every tenant would finish transitioning on that date. Nor does automatically enabling a method create a credential on the user’s behalf.

At the applicable retirement date, users whose only available multifactor authentication method remains Microsoft-provided SMS or voice will encounter a blocking passkey-registration prompt. They must complete registration before continuing to sign in. Microsoft’s retirement FAQ describes this as a registration requirement rather than an automatic account lockout, but the practical consequence is still an interruption if someone reaches it unprepared.

Two population boundaries deserve particular attention. Internal guest users remain subject to February 1; administrators must not place every account described as a guest into the July group. Also, “external users” in the workforce retirement schedule does not mean that Microsoft Entra External ID customer identity tenants are covered by this announcement.

Microsoft’s FAQ limits the published timetable to public-cloud environments. Azure AD B2C is out of scope, and Microsoft Entra External ID customer identity scenarios will receive a separate announcement. Other cloud environments will follow a later schedule. These are Entra workforce authentication changes, not a universal instruction to change personal Microsoft-account recovery settings.

Automatic passkey enablement does not complete an Entra migration​

The September change operates through Entra’s authentication policies. Microsoft says users enabled for SMS or voice in the Authentication Methods Policy or legacy multifactor authentication settings will be automatically enabled for passkeys. Those users are placed into a passkey profile permitting all passkey types, and the registration campaign is set to Microsoft Managed and brought into scope for them.

When an affected user next signs in and completes multifactor authentication, the campaign prompts them to register a passkey. Before enforcement, the default behavior allows unlimited postponement of that prompt. A tenant can therefore have the new policy configuration while still containing users who depend entirely on the old method.

That creates three different states an administrator needs to distinguish: a user is allowed to register a passkey, a user has registered one, and a user can successfully use an approved replacement in their working environment. The first follows from policy enablement. The other two require user participation and a functioning sign-in experience. A policy change alone is not evidence of migration completion.

Microsoft describes passkeys as credentials that use cryptographic keys rather than shared secrets and are resistant to phishing, SIM-swapping, and replay attacks. Its retirement guidance identifies two supported categories:

• Synced passkeys are stored in a platform credential manager, such as iCloud Keychain or Google Password Manager, and synchronized across the user’s devices.
• Device-bound passkeys are created and stored on a particular device. Microsoft lists passkeys in Microsoft Authenticator, Entra Passkey on Windows, and FIDO2 hardware security keys as examples.

Those categories give organizations more than one deployment route. Someone already using an appropriate platform credential manager may have a different registration experience from someone issued a hardware security key. The practical planning question is which supported method the organization intends each group to use, rather than whether everyone must adopt a single Microsoft-branded implementation.

Users already signing in with passkeys, Windows Hello for Business, or another phishing-resistant method can continue using them. Microsoft nevertheless warns that users who remain enabled for SMS or voice may still receive passkey-registration prompts on eligible devices. Existing use of a stronger method does not automatically remove an account from the policy population affected by the rollout.

The broad passkey profile is also a reason to review the resulting policy against the organization’s intended deployment. Microsoft’s automatic change permits all passkey types for the affected users; that is a documented default, not evidence that every organization has already assessed every credential-storage option.

Entra administrators should inventory dependencies before driving registration​

Microsoft’s recommended starting point is discovery. Its retirement guidance provides a PowerShell script for identifying active SMS- or voice-enabled users, requiring one of three roles: Global Reader, Authentication Policy Administrator, or Security Reader. Microsoft’s FAQ says a nonzero result means the tenant has users in scope.

That result identifies work to investigate; it does not establish that every returned user will lose their only authentication method. An account enabled for SMS may also have a working passkey. Conversely, an organization that has broadly enabled passkeys may still have users who never registered one. The useful inventory separates policy exposure from actual dependency.

Administrators should also distinguish SMS used for multifactor authentication from SMS used as the first factor—the primary way a user begins authentication. The replacement options are different because a customer-managed telecom provider cannot preserve SMS primary sign-in. Combining both populations into a generic “move SMS to another provider” project would leave part of the migration unfinished.

Configure the documented passkey registration campaign​

Microsoft documents the following administrative procedure for proactively encouraging registration:

1. Enable Passkey (FIDO2) as an authentication method.
2. Ensure that the affected SMS- and voice-dependent users are included in a passkey-enabled authentication-method policy.
3. Sign in to the Microsoft Entra admin center as an Authentication Policy Administrator.
4. Open Entra ID > Authentication methods > Registration campaign.
5. Set the campaign state to Microsoft Managed and target the security group containing the affected users.

The expected behavior is a passkey-registration prompt after the targeted user signs in and completes multifactor authentication. Because the September rollout can already make these policy changes automatically, administrators should first establish the tenant’s current state rather than assume they are configuring an untouched environment.

The procedure is an enrollment campaign, not a promise that enrollment has succeeded. Before enforcement, users can postpone the prompt by default. A practical completion criterion is that affected users have registered their intended replacement and can use it, rather than merely appearing in the target group.

Microsoft also recommends communicating in phases: announce the retirement and replacement method, provide registration instructions appropriate to the user’s device, and remind people who have not yet registered. Windows, iOS, Android, and hardware-key experiences should not be collapsed into an invented universal sequence. The retirement guidance establishes the administrative campaign settings, but it does not provide one end-user click path that applies to every supported passkey type.

Include password reset and guests in the migration plan​

The change extends beyond the routine sign-in prompt. Microsoft’s retirement FAQ says native SMS and voice retirement also applies to self-service password reset. An organization that has migrated normal sign-in therefore still needs to establish whether password-reset workflows depend on the retiring delivery service.

Microsoft says it plans to introduce support for changing passwords after passwordless sign-in, but that is a planned capability, not an already documented substitute for every reset workflow. Administrators should not count an announced future feature as a completed recovery plan.

Guest deployment also has a timing dependency. Microsoft’s FAQ says passkey support for B2B users and internal guests is planned by the end of calendar year 2026. Internal guests nevertheless retain the February 1, 2027 retirement date. That makes availability of the promised guest support a concrete planning milestone, rather than a reason to assume those users have the same migration window and capabilities as other accounts today.

External MFA methods are not themselves being retired by this announcement. Microsoft says users of those methods enter the automatic passkey migration scope if they are also enabled for SMS or voice. This is another reason to inspect the actual policy configuration rather than infer exposure from the organization’s preferred authentication product.

Customer-managed telephony preserves some Entra workflows, not SMS primary sign-in​

For organizations with a business, regulatory, or technical requirement to keep a telecom channel, Microsoft provides a separate route: contract with a supported provider through the Microsoft Security Store. This retains an option for applicable SMS and voice scenarios while moving delivery away from Microsoft’s native service. It does not give every existing SMS deployment an unchanged future.

The most important limitation is explicit in Microsoft’s telephony-provider FAQ: Choose Your Own Telephony Provider does not support SMS as a primary authentication method. Organizations using SMS first-factor sign-in must move those users to supported alternatives. Microsoft lists passkeys, QR code authentication, FIDO2 security keys, and other supported Entra methods; that list should not be read as a blanket assertion that every option has identical phishing-resistance properties.

Windows Report also reports that SMS first-factor sign-in was removed for Entra ID Free tenants in August 2026. That specific historical date is not independently established by the public Microsoft retirement records available here. The forward migration decision is clearer: Microsoft’s provider FAQ directly confirms that changing telecom suppliers will not retain SMS primary sign-in.

The Entra provider configuration experience is still scheduled for October​

As of September 22, provider information is available, but Microsoft schedules the configuration experience to become available starting October 30, 2026. Its September 21 telephony FAQ names Soprano and Telesign as the initial private-preview providers and says more providers will be available by general availability. Planning and commercial evaluation can begin now; the published schedule does not support describing the configuration experience as generally available today.

Microsoft’s documented migration sequence is to select a supported provider and establish an account, deploy a routing function in an Azure subscription, select the users or groups that will use SMS, voice, or both, evaluate the integration, and then enable production traffic gradually. One provider can be configured for SMS and one for voice. An existing supplier can be retained only if it is among the supported providers.

The routing function connects Entra authentication requests to the chosen provider. That adds an Azure component to a service relationship the organization must manage. Microsoft says provider charges vary with pricing and usage, while standard Azure consumption charges apply to the routing function. There is no universal price in the retirement guidance from which to calculate a dependable per-user migration cost.

Microsoft also documents an evaluation mode. It validates that authentication requests are routed successfully to the provider without changing users’ authentication experience; users continue receiving messages through the currently active delivery method while administrators review results. Successful routing evaluation is the documented checkpoint before enabling the provider for production and expanding the rollout.

Retaining SMS changes the support relationship​

Microsoft remains responsible for the Entra platform, authentication workflows, provider configuration experience, and routing between Entra and the selected provider. The organization manages the provider relationship, including account configuration, service availability, and message-delivery issues. Telecom delivery problems therefore introduce a support path to the selected provider rather than staying entirely within Microsoft.

For eligible scenarios, Microsoft’s retirement FAQ says users migrated to a configured customer-managed provider before their applicable deadline will not receive the retirement-related blocking passkey-registration prompt. Merely choosing a provider is insufficient: the integration must be configured and the affected users migrated.

This route preserves an operational requirement, but it does not change Microsoft’s stated security comparison between telecom authentication and passkeys. It also introduces contracts, usage charges, an Azure routing component, and shared support responsibilities. Those are concrete trade-offs to evaluate for the specific users who need the exception—not reasons to move an entire tenant to another SMS supplier by default.

Entra’s temporary opt-out delays automatic changes, not retirement​

Microsoft offers a temporary opt-out for the automatic passkey enablement and registration-campaign changes during the transition period from September 1, 2026, through February 1, 2027. Its stated purpose is to give organizations time to migrate to another authentication method or configure customer-managed telecom delivery. It does not preserve Microsoft-provided SMS or voice beyond the applicable retirement date.

This is an authentication-policy change and should be treated as such. Microsoft requires the Microsoft Graph permission Policy.ReadWrite.AuthenticationMethod. The documented operation is a PATCH request to the Graph beta resource /policies/authenticationmethodspolicy, with JSON content:

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

The property’s placement matters: setting passkeyDynamicMigration to true inside optOutSettings opts the tenant out of the automatic migration changes during the specified period. The name should not be interpreted in isolation as a switch that turns the migration on.

Microsoft describes the result as exclusion from automatic passkey enablement and registration-campaign rollout during that window. Its guidance does not describe this operation as deleting passkeys users already registered or as a rollback of every change already made in a tenant. It should not be used with those expectations.

For the February population, standard enforcement begins on February 1 regardless of the setting. Global Administrators and external users retain their July 1 deadline; internal guests do not acquire that extension. A temporary opt-out changes how an organization manages the transition, not whether the retirement applies.

The useful decision is therefore whether the automatic campaign fits a migration already being executed. Suppressing prompts can make sense while a documented alternative is being prepared. Suppressing them without completing an alternative simply moves the remaining registration work closer to the enforcement date.

What this means for Entra administrators now​

Start with dependency discovery and user registration now; wait for the scheduled October configuration release only where a genuine telecom requirement makes the provider route necessary. Most of the immediate work—identifying affected users, separating primary sign-in from MFA, communicating the change, and driving passkey enrollment—does not depend on that release.

A migration plan should account for user populations and workflows separately. A February deadline for ordinary workforce accounts, a July deadline for Global Administrators and external users, and a planned year-end guest capability are different scheduling inputs. Applying a single tenant-wide date obscures the work rather than simplifying it.

The most useful checkpoints are concrete:

• Identify SMS- and voice-enabled users using Microsoft’s discovery script with Global Reader, Authentication Policy Administrator, or Security Reader access, then distinguish those merely enabled from those still dependent on the methods.
• Treat February 1, 2027, as the retirement date for most public-cloud workforce users, including internal guests, and July 1, 2027, as the date for Global Administrators and external users.
• Confirm that targeted users have registered and can use their intended replacement; automatic passkey enablement and a postponable registration prompt are not proof of completion.
• Separate SMS primary sign-in from SMS MFA, because customer-managed telephony cannot preserve the primary sign-in scenario.
• Include self-service password reset and guest accounts in the assessment, and keep planned capabilities separate from features already available for deployment.
• If telecom authentication must remain, evaluate supported providers now and plan for configuration, routing evaluation, user migration, cost, and support ownership before the applicable deadline.

Microsoft’s renewed warning gives administrators a chance to finish this as a managed enrollment project rather than a sign-in interruption. September’s rollout supplies the policy and prompting mechanism; it does not finish the user migration. The next concrete milestone is October 30 for organizations retaining telecom delivery, while everyone else can use the current transition window to put working replacement credentials in users’ hands before enforcement begins.