Microsoft Is Retiring SMS and Voice MFA: What Businesses Must Do Before February 2027

For years, organisations have been told that SMS one-time codes are better than no second factor — but weaker than modern phishing-resistant authentication. Most have made a note to address it eventually. Microsoft has now moved beyond that advisory and set a timetable.

Microsoft-provided SMS and voice authentication in Microsoft Entra ID will retire on 1 February 2027. The process begins earlier: from 1 September 2026, users enabled for these methods are due to receive passkey registration prompts. Businesses that do not act before that point will find Microsoft controlling the pace, messaging and experience of their users' migration.

What is actually retiring?

Microsoft is retiring Microsoft-provided telecom delivery for SMS and voice in Entra ID. This affects relevant use cases including MFA and self-service password reset, subject to current official scope.

Microsoft is not removing every possible telephony-based authentication option. Organisations with a genuine documented need may be able to use a supported customer-managed telecom provider through the Microsoft Security Store, under a separate provider agreement with separate pricing and service terms. However, customer-managed telecom does not necessarily preserve every historic SMS capability. In particular, SMS as a primary sign-in method has been reported as remaining unsupported after retirement. Verify current support, availability and limitations against official Microsoft documentation before assuming this path is viable.

Who is affected?

The change affects users who receive SMS codes for MFA, receive voice calls for MFA, use SMS or voice for self-service password reset, have these methods enabled as an available option, rely on older authentication-method settings, have no alternative registered method, use shared or basic mobile phones, cannot use Microsoft Authenticator, work in locations with limited smartphone access, or depend on temporary or legacy exceptions.

A business needs to distinguish between three things: method enabled (the tenant policy allows the method), method registered (the user has added a phone number or method), and method used (the user actively relies on the method to sign in). All three require investigation.

Users already relying on appropriate alternatives — passkeys, Windows Hello for Business, FIDO2 security keys, certificate-based authentication or other supported phishing-resistant methods — may require little or no change. Microsoft Authenticator push notifications remain available but are not always classified at the same phishing-resistant strength as passkeys or FIDO2. Not all MFA methods are equally resistant to phishing. The method used matters.

Why Microsoft is making the change

SMS and voice authentication can be compromised through phishing, adversary-in-the-middle attacks, SIM swapping, mobile-number takeover, call forwarding, message interception, recycled phone numbers, telecom outages and social engineering. The one-time code delivered by SMS can be replayed by a phishing site that receives it from the real service. The number a code is sent to may not remain under the same person's control. The telecom network delivering it sits outside the organisation's security perimeter.

Passkeys are designed to be phishing-resistant because they are tied to the genuine service origin, based on public-key cryptography, not transferable one-time codes and resistant to fake sign-in pages. A passkey does not give a phishing site a reusable code to steal.

What is a passkey?

A passkey is a sign-in credential based on cryptographic keys. The private key remains protected by the user's device or credential provider. The service receives cryptographic proof that the user possesses the correct key. A passkey may be protected by a device PIN, fingerprint, facial recognition, a physical security key or credential-provider controls.

Device-bound passkeys are stored on a specific device or security key and do not leave it. Synced passkeys are available through a supported credential provider across approved devices. FIDO2 security keys are physical devices that hold phishing-resistant credentials. Windows Hello for Business is a Windows-based phishing-resistant sign-in method tied to the user and device. Microsoft Authenticator can store or manage a passkey, subject to current availability and supported configurations.

Verify the current Microsoft terminology, supported passkey types and device requirements before deployment. Capabilities and policy options change as the platform develops.

What users will experience

Before September 2026, users may continue receiving SMS codes or calls. Administrators can move them through a controlled registration campaign with planned communications, tested devices and a known support route.

From September 2026, affected users may see prompts encouraging them to register a passkey after completing MFA. Users will need a compatible device, supported operating system, screen lock, biometrics or PIN, Microsoft Authenticator or another supported provider, permission to register the method and a route for support if registration fails.

From February 2027, users relying only on SMS or voice may face a blocking registration prompt before continuing. Businesses should not assume every user can complete this alone. Potential barriers include old devices, shared phones, no personal smartphone, unsupported operating systems, accessibility needs, contractors, frontline workers, remote staff, restricted mobile-app policies, lost devices, personal-device objections and users without suitable recovery methods.

What administrators should do

Step 1 — Identify affected users: Review the Authentication Methods Policy, authentication-method registration records, sign-in logs, legacy MFA settings, SSPR configuration, Conditional Access policies, guest users and emergency accounts. Use current Microsoft reports and Graph guidance. The goal is to know exactly which users are enabled for SMS or voice, which ones actually use them and which ones have no other method.

Step 2 — Choose the target methods: Passkeys, Windows Hello for Business and FIDO2 security keys are the strongest phishing-resistant options. Microsoft Authenticator remains available. Certificate-based authentication suits some managed environments. Match the method to the user population and device estate — do not assume one method works for everyone.

Step 3 — Enable and configure: Update the Authentication Methods Policy using current Microsoft guidance. Ensure Conditional Access policies are aligned and do not inadvertently block registration.

Step 4 — Pilot before full rollout: Include administrators, office staff, remote workers, mobile-only users, shared-device users, users with accessibility requirements, contractors, senior staff, frontline workers and users without corporate smartphones. A pilot that only tests straightforward cases will miss the problems that emerge in production.

Step 5 — Run a registration campaign: Prompt users before Microsoft's forced timeline. Users who register through a planned campaign receive help, communications and a support route. Users who register under pressure during a live sign-in receive none of those.

Step 6 — Communicate: Explain why the change is happening, what users must do, the deadline, which devices are supported, how to get help, what to do with a lost device and what happens if they ignore the prompt.

Step 7 — Monitor completion: Track who registered, who failed, who postponed, who lacks a compatible device, who still uses SMS and who needs an exception. Registration completion is not the same as the migration being finished.

Step 8 — Remove SMS and voice where appropriate: Once alternative methods are proven and registered, disable the retiring methods to reduce the available attack surface.

Step 9 — Test recovery: Verify the full recovery chain — lost phone, replacement device, forgotten PIN, security-key loss, emergency access, administrator recovery, new starter registration and leaver handling. A method that cannot be recovered cleanly creates a future lockout.

Self-service password reset

Microsoft's retirement also affects SMS and voice dependencies used for self-service password reset. A business that migrates MFA but ignores SSPR may find that users who forget their password or get locked out have no usable recovery route.

Review the SSPR authentication methods, combined registration flow, recovery options, administrator reset procedures, Temporary Access Pass availability, passwordless user handling, new starter onboarding and lost-device recovery. Passkeys alone do not solve every password-reset and account-recovery scenario — verify Microsoft's current support for password changes and recovery for passwordless users.

Temporary Access Pass

Temporary Access Pass is a time-limited passcode that an administrator can issue to a user. It can help onboard a new user, allow registration of passwordless methods, recover from a lost authentication device and bootstrap passkey registration. It should be time-limited, tightly controlled, issued only after identity verification, logged, protected from disclosure and expired or removed promptly. It is not an everyday authentication method and should not be used as a substitute for a planned recovery process.

Customer-managed telecom providers

Microsoft states that organisations with a genuine operational or regulatory need to retain SMS or voice may use supported customer-managed telecom providers through the Microsoft Security Store. This is an exception path, not the recommended route for most organisations.

Customer-managed telecom introduces a separate provider agreement, separate billing, separate monitoring responsibility and separate support. It does not necessarily restore every historic SMS capability. SMS as a primary sign-in method has been reported as remaining unsupported. Provider availability in the UK, supported regions, SMS and MFA support, SSPR support and configuration requirements should all be verified against current official documentation before committing to this path.

Administrator and emergency accounts

Global Administrators and other privileged roles should move to strong phishing-resistant methods first, not last. If an administrator's account is compromised using an SMS-based MFA bypass, the consequences extend across the entire tenant.

Emergency break-glass accounts require careful design: they must remain accessible when normal authentication is unavailable, must use strong authentication that does not depend on the retiring methods and must be actively monitored for unexpected use. Service accounts, shared administrator accounts, third-party support accounts and delegated partner access should all be reviewed.

Accessibility and device ownership

Not every employee has a smartphone, and not every employer should require a personal smartphone for work authentication. The migration plan must consider corporate-device availability, documented accessibility needs, reasonable adjustments, shared devices, hardware security keys, Windows Hello availability, credential-provider support, any union or employment considerations, data-separation requirements, reimbursement policy and lost-device procedures.

Business continuity risks of waiting

Organisations that wait for Microsoft's blocking prompt may face: blocked sign-ins, user lockouts, service-desk spikes, executives unable to access email, administrators unable to reach management portals, remote workers unable to work, failed self-service password reset, emergency-account problems, unmanaged workarounds, users enrolling unsuitable personal devices, rushed security-key purchases, inconsistent authentication methods and customer disruption.

Migration checklist

Discovery: Have we identified users enabled for SMS or voice? Have we identified users who actively use them? Have we reviewed SSPR? Have we reviewed legacy MFA settings?

Target method: Is passkey support enabled? Is Windows Hello available where appropriate? Are security keys available for users without smartphones? Are accessibility requirements covered?

Policy: Is the Authentication Methods Policy current? Are Conditional Access policies aligned and not blocking registration? Are administrators treated separately? Are emergency accounts protected?

Pilot: Have representative users tested registration? Have mobile and desktop journeys been tested? Has lost-device recovery been tested? Have support procedures been tested?

Communication: Have users received a deadline and instructions? Is support available? Are managers briefed?

Monitoring: Can we report on registration completion? Can we identify continued SMS use? Are failures reviewed? Are exceptions documented?

Closure: Have remaining SMS and voice dependencies been removed where appropriate? Are any customer-managed telecom exceptions formally approved? Is recovery proven for all user types? Is the next review scheduled?

Warning signs

• Nobody knows which users currently use SMS or voice
• Users have phone numbers registered but no other method
• Passkeys have not been tested with a representative user group
• Administrators still rely on SMS for their own accounts
• Break-glass accounts have not been reviewed
• Users are expected to use personal devices without any discussion or policy
• No security-key option exists for users without smartphones
• SSPR has not been reviewed for phone-method dependencies
• Registration instructions do not exist
• The service desk has not tested recovery procedures
• Conditional Access blocks passkey registration
• Incompatible devices remain in use without a plan
• Contractors are excluded from migration planning
• Exceptions exist but have no named owner or expiry
• The organisation's plan is to wait for Microsoft's blocking prompt

The IT Club view

Microsoft has moved beyond advice and set a timetable. That creates both a security improvement and a migration project. The security case for passkeys is strong. The work required to get there is not primarily technical — it is the harder task of finding every user, every device, every exception and every recovery dependency before the enforcement arrives.

IT Club recommends: identifying affected users now using sign-in logs and registration data; moving administrators and privileged accounts first; prioritising passkeys, Windows Hello for Business or FIDO2 security keys as the target methods; piloting with a representative group before mass rollout; planning carefully for accessibility requirements and device ownership; reviewing SSPR alongside MFA; testing every recovery scenario; communicating early with users; avoiding unnecessary customer-managed telecom exceptions; monitoring until SMS and voice use reaches zero or documented approved exceptions remain; and reviewing authentication arrangements through an Operational Heartbeat.

Do not wait for Microsoft to force users through registration during a live sign-in. Move them while the business still controls the timing, communication and support.