Microsoft phases out SMS MFA: three Entra deadlines every IT admin must know now

For years, a text message with a six-digit code was good enough as a second factor. Cheap, familiar, and widely accepted. But in 2026, Microsoft is definitively pulling the plug. SMS and voice verification codes via Entra ID are being phased out, with a hard end date of February 1, 2027. For IT administrators who do nothing, that is not a date on the calendar but an incident in the making.

The reason is clear. SMS authentication is not phishing-resistant. Attackers have been intercepting codes for years via SIM-swapping, SS7 weaknesses, and real-time proxy techniques that trick a user into entering a one-time password on a spoofed login page. With the rise of AI-driven phishing campaigns, attack execution time has dropped from minutes to seconds. Microsoft has had enough.

Three deadlines that matter now

The phase-out runs in three steps, each with its own impact. The first date is September 1, 2026. From that day, passkeys become the default sign-in method in Microsoft Entra ID. Users who have SMS or voice enabled as an MFA method are automatically also enabled for passkeys and receive a nudge at their next sign-in to register a passkey. That nudge can be dismissed; there is no blockage yet.

The second date is October 30, 2026. From that moment, tenant administrators can connect a third-party telecom provider via the Microsoft Security Store if they want to keep offering SMS or voice verification. This is a paid option with additional configuration. Microsoft no longer delivers this itself but enables it through certified partners. Organizations that want to take this route need to start early, as onboarding with a telecom provider takes time.

The third and most critical date is February 1, 2027. On that day, the nudge becomes a blocking requirement. Users for whom SMS or voice is the only available MFA method cannot sign in until they have registered a passkey. There is no opt-out, no administrator exception, and no extension. Microsoft has explicitly stated that this applies to all tenants without exception.

Who is concretely at risk in your tenant?

Not everyone in your organization is equally vulnerable. The risk lies with users who, during their MFA registration, chose only SMS or voice, and have not added an alternative method since. Think of employees who skipped the Microsoft Authenticator app, external or part-time staff who quickly set something up during onboarding, and B2B guests who have access to your Microsoft 365 environment but never completed a full Authenticator registration.

The easiest way to quickly map this out is the Authentication methods activity report in the Entra ID portal. Under Identity, then Monitoring and health, and then Authentication methods activity, you can see per method how many users are registered for it. Export the data and filter on users with only SMS or voice as their registered method. Those are your at-risk cases.

What do you do before September 1?

Five steps you can take in the coming weeks to prepare your tenant. First, run the audit described above. Know how many users have only SMS or voice. Make a list.

Second, enable passkeys via the Authentication methods policy in Entra. Go to Entra ID, then Protection, Authentication methods, and enable Passkeys (FIDO2) for the relevant user groups. You can do this more broadly than just the at-risk group; passkeys are an improvement for all users.

Third, make sure the Microsoft Authenticator app is available and recommended for all users as an interim solution. Anyone who cannot or does not want to register a passkey has Authenticator with notifications as a strong MFA alternative. It is also more phishing-resistant than SMS, though not as strong as a passkey.

Fourth, communicate proactively to the at-risk group. Send a clear message: what is changing, when, and what the employee needs to do concretely. Provide instructions for registering a passkey via Windows Hello, the Authenticator app, or a FIDO2 key. Users caught off guard by a blockage on February 1, 2027 do not represent a Microsoft failure — they represent insufficient preparation.

Fifth, document exceptions. Are there devices or roles for which a passkey or Authenticator is technically not feasible? Think of shared accounts, kiosk devices, or employees with a phone that does not support apps. For these cases, you need to make a decision before October 30, 2026 about the third-party telecom provider route, or configure an alternative sign-in method.

Does your organization want to keep SMS?

For most organizations the answer is no, but sometimes there is an operational reason. Employees without a smartphone, shared work phones, or specific business processes built on SMS messages can justify keeping SMS as an option. That is possible, but only through a third-party telecom provider connected via the Microsoft Security Store.

This brings additional costs — typically a monthly rate per message sent or per user, plus the management burden of configuring and maintaining the connection. Microsoft no longer provides the infrastructure itself. If retaining SMS is a deliberate and well-founded choice for your organization, start evaluating providers now and calculate what it will cost.

Why SMS was never truly secure

The phase-out is logical for anyone who knows the background. SMS as a second factor has two fundamental weaknesses. The first is SIM-swapping: an attacker convinces a telecom provider to transfer a phone number to a new SIM card. The attacker then receives all SMS messages intended for that number, including MFA codes. This succeeds regularly, even with major providers.

The second weakness is the SS7 protocol, the technical standard on which the global telephone network runs. SS7 dates from the 1980s and has serious security problems. State actors and advanced criminal groups are able to reroute and intercept SMS messages via SS7. For most organizations this is a remote scenario, but for targets with a higher risk profile it is real.

With the rise of Adversary-in-the-Middle phishing kits that fully automatically intercept and relay MFA codes, the protection SMS offers is now marginal. Passkeys and app-based authentication are fundamentally different: the cryptographic key never leaves the device, making interception and forwarding structurally impossible.

What is the conclusion for IT teams?

The three deadlines are not something to wait for. The window between now and September 1, 2026 is the time to run the audit, enable passkeys, and have communications ready. The window between September and February is the time to actively guide users and follow up on the persistent cases. After February 1, 2027, there is no recovery option without users being blocked.

Want help with auditing your MFA registration status, setting up a passkey policy, or guiding users through the migration? Contact Zarioh for a concrete approach that fits your organization and timeline.