Microsoft Entra passkeys: a practical plan for SMS and voice retirement

Microsoft Entra is changing the experience for organizations that still rely on text messages or voice calls. From 1 September 2026, users enabled for SMS or voice are automatically enabled for passkeys and can be prompted to register one during an eligible sign-in. This is not the date when telephone methods stop working. Microsoft-provided SMS and voice delivery ends in stages in 2027. The work is therefore broader than turning on a policy: identify affected people, prepare their devices, provide safe recovery, test real sign-in flows and document legitimate exceptions. The Microsoft retirement timeline separates the populations and deadlines.

Three dates that mean different things

September 2026 starts automatic passkey enablement and the registration nudge; it does not retire SMS. From 1 February 2027, Microsoft-provided telephone authentication is retired for most users, including internal guest users. Global Administrators and external users have the later date of 1 July 2027. After the applicable date, a person whose only available MFA method is SMS or voice must register a passkey before continuing to sign in; Microsoft describes this as a blocking prompt. A temporary opt-out from automatic enablement in the earlier phase does not remove the 2027 enforcement. Check the official timeline and retirement FAQ before setting internal deadlines.

The practical implication is to set your own completion date well before Microsoft's enforcement. Leave time for a pilot, help-desk training, support for unusual devices and a retry if a passkey profile blocks registration. Do not infer readiness from a policy that says enabled. The person must be able to register and then complete a subsequent sign-in to the applications they use. A representative test group should include office staff, frontline workers, privileged administrators and people who do not carry a company-managed smartphone.

Find the users who actually depend on the phone

Inventory accounts enabled for SMS or voice in the Authentication Methods Policy or legacy MFA settings. Then distinguish permission to use a method from observed usage: an account can retain a phone method while normally signing in with a stronger one. Microsoft provides a script and specifies the reading roles needed to find affected users in its migration guidance. Divide the result by device type, account class, support needs and critical application. Include frontline staff, shared workstations, internal guests, operational exceptions and highly privileged users. An enabled passkey policy is not evidence that an individual has finished registration, and a one-time registration does not prove that recovery works.

• Record the user, account type, enabled methods, observed phone use and responsible team
• Check devices, browser support, credential manager and access to a backup sign-in path
• Document any genuine regulatory or operational requirement for telephony with an owner
• Keep a recovery procedure and next review date for each exception

Choose a passkey type that fits the role

Passkeys use cryptographic keys and resist phishing, code forwarding, SIM swapping and replay more effectively than SMS. Microsoft Entra supports synced passkeys stored in a platform credential manager and device-bound passkeys such as Microsoft Authenticator, Entra passkeys on Windows and FIDO2 security keys. A physical key is not mandatory for every employee. In its passkey FAQ, Microsoft recommends device-bound passkeys for administrators and other highly privileged users, while synced passkeys are suitable for ordinary non-admin users. Choose with the organization's device model, recovery path and assurance requirement in mind. Test the combinations of operating system, browser and credential provider that staff actually use.

The method policy must allow registration

Before starting a registration campaign, enable Passkey (FIDO2) for the target group in Authentication Methods Policy and allow self-service setup when users should register their own credential. Passkey profiles control the types permitted for different groups. Changes to attestation or AAGUID restrictions require careful testing: a restrictive change can affect already registered credentials. The Microsoft enablement guide documents these controls. In the pilot, verify a new registration, a repeat sign-in and the experience after changing or replacing a device. Also check that staff know which passkey provider is approved by the organization rather than choosing one without guidance.

A registration campaign is a nudge, not completion

A registration campaign prompts eligible people after an interactive MFA sign-in. Microsoft's managed passkey setting allows unlimited snoozes by default, so a campaign can be active while a meaningful group still has no passkey. Measure successful registrations, SMS-only accounts, platform-specific failures and subsequent sign-ins without telephone MFA. You can scope the campaign to groups, but one campaign targets one authentication method at a time. The registration campaign documentation explains prerequisites and prompt behavior. Tell users why they see the prompt and where to get help if their device cannot create the requested credential. Avoid interpreting the number of sent emails as adoption.

1. 01

   Define affected populations

   Inventory SMS/voice users, separate administrators and guests, and check actual sign-in patterns

2. 02

   Enable suitable passkey profiles

   Set FIDO2 policy and self-service registration for a small pilot with varied devices

3. 03

   Launch the nudge and support path

   Prepare user guidance, campaign scope, help desk and a lost-device process

4. 04

   Verify access and coverage

   Test repeat sign-in, core applications, a second device and recovery before expanding

Recovery cannot depend on the lost phone

A migration is fragile if people can create a passkey but cannot safely recover after losing a device. Microsoft Entra offers Temporary Access Pass (TAP), a time-limited passcode used to bootstrap or recover passwordless methods. It can be restricted by lifetime and, according to policy, to a single use. Define who verifies the requester's identity, who issues TAP, how it is delivered and how completion is recorded. TAP is not a permanent replacement for a password. The Microsoft procedure also notes limitations for external guest accounts. Exercise scenarios such as a lost phone, a replaced work laptop and a new hire who has not yet registered another MFA method.

When telephony is still a legitimate requirement

Microsoft provides a path to use a customer-selected telephony provider through Microsoft Security Store for segments with documented business, technical or regulatory needs. This is not a reason to retain SMS as the default for everybody. The customer manages the provider relationship and must test delivery, support responsibilities and targeting. Microsoft says configuration begins on 30 October 2026; review the current provider guidance because implementation details may evolve. Include self-service password reset in the transition: the retirement FAQ says native SMS and voice retirement applies to SSPR too. Record which users need a telephony exception and when it will be reviewed again.

How to know the transition is complete

Completion is neither a policy switch nor a mail-merge campaign. For every population, confirm that people have a usable phishing-resistant method, can repeat sign-in on their normal platforms and have a tested recovery route. Run a separate privileged-account exercise because administrators have a different date and higher risk. Keep unresolved registrations, guests and exceptions in an owned register. Before tightening Conditional Access, check application and client dependencies; after rollout, review sign-in logs and support requests. Stable, verified access is the outcome to measure. If a failure requires a fallback, the team should know which approved recovery method is allowed and how to revoke a compromised credential.

1. Reduce users with telephone-only MFA to zero or a documented, supported exception
2. Test registration and later sign-in on devices used in real work
3. Practice recovery without the missing credential
4. Verify administrator, guest and SSPR scenarios separately

Frequently asked questions