Entra Passkey Defaults Put SMS Retirement On The Clock

Microsoft has set two public-cloud deadlines for Entra ID. On September 1, 2026, users enabled for SMS or voice authentication will be automatically enabled for passkeys and brought into a Microsoft-managed registration campaign. On February 1, 2027, Microsoft-provided SMS and voice delivery will end. A customer-managed telecom provider will remain an option for organizations with a documented need.

This is not an automatic credential migration. The September change enables policy and prompts eligible users after they complete MFA, but the default nudge can be snoozed. The February change is the enforcement point: users left with only Microsoft-provided SMS or voice will face a blocking passkey registration step. Administrators need to identify the affected population, choose appropriate passkey types, test enrollment and recovery, protect emergency access, and separate legitimate telecom exceptions from simple rollout delay.

Microsoft's new guidance applies first to public-cloud Entra ID tenants. On September 1, users who are enabled for SMS or voice in the Authentication Methods Policy or legacy MFA settings will be enabled for passkeys in the Authentication Methods Policy. Microsoft says those users will be placed in a passkey profile that allows all passkey types, and the registration campaign will move to a Microsoft-managed state that targets passkeys.

The next eligible sign-in does not immediately disable the old method. After a user completes MFA, the registration campaign can prompt that user to create a passkey. Microsoft says the default campaign allows unlimited snoozes. That detail matters: an administrator can see the policy change land while a substantial part of the user population remains dependent on SMS or voice. Policy state is therefore not a reliable completion metric.

The hard deadline is February 1, 2027. Microsoft-provided telecom delivery for SMS and voice will be retired. Users whose only available MFA method is one of those channels will receive a blocking passkey-registration prompt before they can continue. Microsoft describes customer-managed telecom providers in the Microsoft Security Store as the continuing route for approved SMS or voice use. Other Entra cloud environments will follow on a later schedule, so administrators should confirm their tenant boundary before applying the public-cloud timeline everywhere.

The first control task is to find people who still use or are enabled for SMS and voice. Microsoft's retirement page includes a PowerShell method and calls out both the modern Authentication Methods Policy and legacy configuration. Inventory should include employees, administrators, service desk staff, contractors, guests where relevant, shared operational identities, and users who depend on self-service password reset. A nonzero result is a migration population, not a failure by itself.

Separate enabled methods from observed use. Some users may have a passkey, Windows Hello for Business, certificate-based authentication, or a security key but still keep a phone method registered. Others may appear ready because passkeys are enabled for their group but have never completed enrollment on a usable device. Track at least three states: policy eligibility, registered methods, and successful phishing-resistant sign-ins. Review recent sign-in and audit data rather than relying only on the configuration screen.

Microsoft says API support for a temporary opt-out from the September changes will be available from August 1. That can create room for a controlled rollout, but it should have an owner and exit date. The temporary choice does not change the February deadline. A tenant that uses it without a deployment plan converts a manageable registration campaign into a blocking event during ordinary sign-in.

Entra supports synced and device-bound passkeys. Synced credentials can follow a user through a supported platform credential manager, reducing device-replacement and help-desk friction. Device-bound credentials stay on a particular authenticator, including supported hardware security keys and platform implementations. Microsoft recommends synced passkeys for many ordinary users and tighter device-bound options for elevated or highly regulated populations.

The September Microsoft-managed profile allows all passkey types for the affected users. Organizations with stricter requirements should review passkey profiles, attestation, allowed authenticators, and group targeting before that default arrives. A blanket requirement for device-bound credentials can create procurement and recovery work. A blanket allowance for any synced provider can be too broad for administrators who control identity policy, production systems, finance, or sensitive investigations.

Conditional Access authentication strengths are how a tenant can require phishing-resistant methods for selected resources or roles. Roll out the credential before enforcing the strength. A policy that demands a passkey from a user who cannot register one safely is an outage, not a security improvement. Use report-only evaluation and pilot groups to find unsupported clients, shared-device workflows, remote enrollment problems, and cross-tenant scenarios before broad enforcement.

A passkey must be registered from an already trusted state. Microsoft documents ordinary self-registration after MFA and also supports Temporary Access Pass for bootstrap. A TAP is powerful because it can let a user establish a new phishing-resistant credential. Issue it only after a defined identity-proofing step, keep its lifetime and use count narrow, deliver it through an appropriate channel, and review the resulting enrollment event.

Device loss is the other half of the rollout. General users need a supported recovery path that does not quietly return to email or phone-only proof. Privileged users need at least two independent authenticators, documented replacement steps, and a help-desk process that cannot be overridden by urgency or executive impersonation. Microsoft notes that passkeys do not automatically expire, so stale credentials and departed devices need lifecycle review.

Self-service password reset also changes when Microsoft-provided SMS and voice retire. Teams that use a phone method for both MFA and SSPR should test the full recovery journey, not just an interactive Microsoft 365 sign-in. Confirm what happens for a new phone, a wiped authenticator, an inaccessible platform credential manager, a locked Windows device, and a user who has no second enrolled credential.

Microsoft is not removing the possibility of SMS and voice from every tenant. Its current plan moves delivery to customer-managed telecom providers obtained through the Microsoft Security Store. Provider information is scheduled for September 18, 2026, with configuration beginning October 30. Microsoft says pricing will vary by provider and region. Those details remain future deliverables and should be rechecked before procurement.

An exception may be justified by a regulation, a workforce without compatible devices, a constrained field environment, or another documented operational requirement. It should not become the default escape route for every difficult user. Name the population, reason, owner, provider, regions, data and logging expectations, support process, cost, and review date. Where the exception exists, keep phishing-resistant methods available for higher-risk access and administrators.

Telecom dependence also creates availability and social-engineering risks. A carrier outage, number reassignment, SIM swap, roaming failure, or fraudulent support interaction can affect authentication. Moving the carrier contract does not make the channel phishing-resistant. Treat customer-managed SMS or voice as a constrained compatibility mechanism and measure how much of the tenant still depends on it after the main migration.

Identity migrations can lock out the same administrators needed to fix them. Microsoft recommends at least two cloud-only emergency access accounts, phishing-resistant credentials that do not share the normal administrator dependency, monitoring for every use, and regular validation. Its current guidance recommends passkeys or certificate-based authentication for those accounts and describes FIDO2 security keys as a useful independent option.

Test emergency access before changing the registration campaign, passkey profiles, authentication strengths, or telecom settings. Store credentials in separate controlled locations, confirm the accounts are excluded from Conditional Access rules that could defeat their purpose, and alert on sign-in. A successful test should prove both authentication and the ability to perform the small set of administrative actions needed to recover the tenant.

The migration is complete when people can sign in and recover without Microsoft-provided SMS or voice, privileged roles use the intended authenticator class, legacy methods are no longer the quiet fallback, and the help desk can handle loss without weakening proof. Track these outcomes through the February deadline. The announcement is a calendar event; the security improvement depends on the tenant's execution.