Microsoft has recently announced a timeline for the retirement of Microsoft-provided SMS and voice-based multifactor authentication (MFA) methods in Entra ID, a change which has left many organizations to figure out how they'll be impacted and what migration looks like for them.
One standout detail is the push for passkeys as the new default authentication mechanism for account sign-ins, due to them being phishing-resistant. For many users reading Microsoft's announcement, this then raises the question:
Weren't all those other MFA methods already meant to prevent phishing?
In today's post we'll be discussing some of the typical MFA methods you've probably encountered before, where they help, where they don't help, and how they stand up against a form of phishing that many simply aren't hearing about enough yet.
But first, let's briefly cover the details of Microsoft's upcoming changes.
What's Changing, and When
What IS changing
- At the end of the transition timeline detailed below, Microsoft-provided SMS and voice calls will no longer be an available MFA option for Entra users.
- Passkey authentication will be treated as the default sign-in method for users.
- Self-service password resets (SSPR) are additionally affected by these changes, and will be unavailable if SMS and voice are a user's only verification method.
- Microsoft will begin allowing customers who require SMS and voice capabilities to configure an alternative telecom provider from the Microsoft Security Store.
- Registration Campaign settings will be updated to a Microsoft-managed state where required to bring users into scope.
What is NOT changing
- SMS and voice-based MFA and SSPR not provided by Microsoft will be unaffected.
- Other MFA options your organization may be using, like Microsoft Authenticator or third-party MFA providers, will still be available.
Timeline
September 1, 2026: Passkeys enabled by default, SMS/voice users begin to get nudged
The first change, slated for September 1st, is to automatically enable passkey authentication for any users with SMS or voice-based MFA and start nudging them to enroll. This won't change any existing MFA enrollments for those users, they can snooze the reminders an unlimited number of times, and you can temporarily opt out your whole Entra tenant if you need to.
February 1, 2027: SMS/voice retires
On February 1st, the full transition will take place. Microsoft-provided SMS and voice will no longer be available to use as an MFA method for any Entra users. Any users who only had those methods available will be required to register a passkey to complete sign-in.
Entra Administrators take note: There is no opt-out. You will want to have a plan to make sure your migration goes smoothly and be prepared for a short-term increase in help desk activity if users encounter friction.
Isn't All MFA Supposed to Stop Phishing?
Surprisingly, no!
Multifactor authentication (MFA) exists as a layered defense primarily to prevent attackers from making use of a victim's password that had previously been stolen or otherwise exposed. The goal is to prevent attacks like credential stuffing and password spraying from allowing an attacker in using these weak or compromised credentials.
Phishing campaigns are related here, but "phishing" refers to how credentials are harvested while MFA governs how they're used.
When a credential stolen via phishing is used later to access a victim's account, MFA can be a strong layer of defense depending on the attacker's motivation and resources. This is often enough to discourage further action on the part of an opportunist looking for low-hanging fruit (which tends to be the threat model for most individuals), thus leading many to the conclusion of "MFA prevented the phishing attack".
In truth, though, MFA didn't prevent the phishing scam from being successful. The attacker is still in possession of a valid username and password combination, they just can't use it on the specific system in question without additional effort. There's also every chance they'll take those stolen credentials and try to use them on other sites and services where MFA may not be enforced.
For an attacker who knows what they're doing and has the motivation to work for it, there are plenty of ways to try navigating around MFA on an account (some of which we'll touch on in this post). At the end of the day, tricking people has never been the hard part of cybercrime.
What's driving this push for phishing-resistant MFA?
The attack that changed the game: adversary-in-the-middle phishing or AiTM.
Originally a typical phishing campaign would collect credentials from users over time, store them centrally in a text file or database, and make use of them (or sell them in bulk) after the fact.
The "after the fact" nature of how those stolen credentials are used is a big deal, as it's what makes one-time codes an effective second layer of defense. Even if the attacker captured a TOTP code on their phishing page, for example, that code ceases to be useful moments after it was provided.
Things got a lot trickier to defend against when attackers started building automation into the phishing process to act immediately when a victim is captured.
Instead of passively logging credentials received by a bogus webpage, AiTM phishing makes use of web proxies (either home-grown or using readily available tooling like Evilginx) that can relay their victims' connections directly to the services they think they're logging into and harvest what they need out of the connection live.
They trick victims into visiting a site they control, using convincing emails or fake documents shared through legitimate emails via services like SharePoint or DocuSign, but that site shows the exact content they would expect in their usual login process. The only distinguishing factors a typical user could notice would be the unexpected email and a bogus URL in their address bar.
Since the attacker is intercepting and relaying traffic back and forth between the victim and the service being impersonated, they don't just get to intercept usernames and passwords. Their scope now includes any MFA codes passed through the victim's browser, and ultimately the actual session token being sent back from the server meant for the user's newly validated login session.
This changes the entire objective of the phishing campaign:
Passwords are just a means to an end and they're probably going to get rotated anyway. Hijack a legitimate session token, use it as long as possible, and try to establish a means of generating new ones.
Thus, "phishing-resistant MFA" needs to ensure that this attack chain is impossible.
How We're Grading These
To show how today's MFA methods measure up, we'll be looking at what kinds of attacks they help against and which they don't. Then we'll assign letter grades from A to F, representing how they hold up against the modern threat landscape.
An A grade represents the best of what's available to end-users in typical enterprise environments. There is no A+, as nothing is perfectly secure and this is a relative scale.
A grade of F, on the other hand, represents plain "username and password" authentication with no additional MFA layers on top. Every method we're discussing today is a huge improvement over "nothing", even the SMS and voice methods specifically being retired.
The grades between those extremes depend on factors like where the trust boundary falls for each method, what sensitive information passes that boundary, and critically whether a given method is bound to the site it was registered for.
The Methods
SMS and Voice Codes | Grade: D
How it works: Once the site verifies your username and password, it texts or calls your phone number with a code. If the user submits the matching code on the sign-in page, then authentication is allowed to complete.
What it protects against: It will keep opportunists from gaining access to your account with only your username and password, such as in a credential stuffing attack or if you're caught in a low-sophistication phishing scam. The good news is that this is still enough to handle a wide majority of the bulk low-effort credential stuffing traffic most users will see, but anything more advanced will be a threat.
Where it breaks: SMS/voice MFA fails against most of the same bypass techniques we'll discuss later, but the most notable attack specific to this method is called SIM swapping. It's a fraud technique where an attacker attempts to convince your phone provider's technical support that they are you (or represent you), claim your phone was lost or destroyed, and request that your phone number be transferred to a new device. The same result can also be accomplished via bribery. When your registered phone number now directs messages and calls to the attacker's device instead of your own, they can receive your MFA codes there.
Can it prevent AiTM phishing? No.
The user knows they're logging in to their account, they just don't realize there's a bad URL on the sign-in page. If they've already provided their username and password to trigger the code to send, there's nothing suspicious about the fully legitimate code they receive to tip them off further. They enter the code and hand it off to the attacker's proxy site, which relays it straight to the legitimate site where they receive a session token.
Authenticator App Codes (TOTP) | Grade: C
How it works: When you first register a site in your authenticator app, the site generates a secret key that it shares with you. The authenticator then uses that secret key to generate codes based on the current time on your device. When you try to sign in, the site asks you to provide a code from your authenticator. Since the server also knows your secret key, and knows what time it is, it can verify that your code is a match. Anyone without that shared key won't be able to generate valid codes, and each code is only valid for a short time in the event that one gets intercepted.
What it protects against: Credential stuffing and basic phishing become far less threatening, and it has none of the telecom drawbacks of SMS and voice. It also makes social engineering schemes that take place over asynchronous channels like email harder to pull off successfully.
Where it breaks: While the time-based codes make it more challenging, it can still be possible to trick users into providing a valid code through social engineering. Phone-based tech support scams are common, and less security-conscious users are likely to give up a code to someone claiming they're verifying the user.
Can it prevent AiTM phishing? No.
For the same reason as SMS and voice, an AiTM victim who reaches the point of needing to provide an MFA code is probably not going to choose that moment to get suspicious if they hadn't already. The user sends the code straight to the attacker who relays it with zero delay, so the time-based verification makes no difference.
Tap-to-approve Push Notifications | Grade: C-
How it works: Instead of requesting a code, the site sends a push notification to an application on your phone (frequently through a third party provider, which the next diagrams will detail). To approve the login, you just click the button. To deny it, you can press a different button or just ignore the request.
What it protects against: This is one case where an MFA method was introduced to be more convenient than its predecessor, not necessarily more secure. It generally provides protection against the same suite of attacks as TOTP. While it's not a common vector, it's also technically secure against having a shared secret exposed during registration (for example if someone caught a photo of the QR code you were given when registering a TOTP key).
Where it breaks: Tap-to-approve suffers from a unique and readily exploitable flaw, MFA fatigue, targeted by an attack known as push bombing. In the event that an attacker gets their hands on your username and password, they can automate login attempts easily. This results in a series of approval requests blowing up your phone, at any time of day, for hours on end. The expectation is straightforward: Eventually, you'll hit "Allow". Maybe you just hit the wrong button, maybe you think it's your phone trying to do something legitimate in the background, maybe you just get frustrated enough to not care, but eventually it'll happen. This is exactly how Uber got hacked in 2022.
Can it prevent AiTM phishing? No.
Changing the approval process doesn't change the dynamic in an AiTM scenario. The attacker still sends a legitimate request to the legitimate site, which sends a legitimate verification to your phone. The only difference is who ends up receiving the session token.
Push Approval with Number Matching | Grade: B
How it works: After you sign in with your username and password, the sign-in page shows a two-digit number. Behind the scenes, the MFA provider sends a prompt to your phone that asks you to type the number you see on the screen. If the numbers match, the sign-in is approved.
What it protects against: This method was purpose-built to solve the MFA fatigue problem seen with "tap to approve" push notifications. Since the user needs to know the right number to type to approve a request, there's no way for them to approve a login they aren't somehow participating in.
Where it breaks: Not counting AiTM, number matching holds up against pretty much everything short of a social engineering scheme where someone is fraudulently asking a user to enter a number in real time (which is effectively just AiTM with a human in the middle instead of a proxy server).
Can it prevent AiTM phishing? No.
Since the attacker's proxy site is showing you the exact same content the real site is trying to send you, they'll have no issues presenting you with the number to match on your phone. And since the attacker is sending your credentials to the legitimate site, the service fires off a legitimate approval prompt.
Passkeys (FIDO2) | Grade: A
How it works: Instead of adding a layer to the existing username and password authentication process, passkeys (and similar technologies like Windows Hello for Business) replace the entire sign-in experience with a cryptographic challenge-and-response scheme built specifically to only allow pre-approved keys to authenticate you, and only work for the exact site that it was keyed to in the first place.
As shown in the diagram above, when your browser or device tries to sign in to your account, the site itself ultimately just sends a "question" that's mathematically keyed to your registered passkey and the site you're connected to. Your browser or device will then ask you to verify yourself (usually with a locally configured PIN or a biometric like Face ID or fingerprint) so it can unlock the passkey, which can then be used to answer the "question" sent by the server.
What it protects against: This is where AiTM phishing finally meets its match: Passkeys are origin-bound. It doesn't matter if you don't notice the attacker's bogus URL in your address bar, you won't have a passkey registered for that address so there's nothing for your browser or device to even attempt to send. Past that, even if the attacker tricks you into registering a passkey for their site, it only works for challenges generated by that site. A challenge proxied from the real domain can't be solved with a key meant for a fake one.
Where it breaks: You're only as secure as your least secure authentication method available. If users are able to fall back to weaker authentication methods (which is extremely common during migrations like these), then you need to expect that phishers will present them with the weaker method and the passkey will be ignored entirely.
A note on passkey types: There's a distinction between two different implementations of passkeys: synced and device-bound. Most users will expect to register synced passkeys, where the passkey itself is stored within a password manager, or with a provider like Apple iCloud Keychain or Google Password Manager. Device-bound passkeys are tied directly to a single dedicated physical device that created them, like a YubiKey.
Synced passkeys are convenient to have when users get new devices and much less likely to be unrecoverably lost, but they're reliant on the trust held in the third party hosting the keys. Device-bound passkeys are capable of attesting "I am in possession of the one physical instance of this key that exists on Earth," which is desirable in high-security situations, but there's a cost associated with purchasing the devices and when they're lost, they're lost.
To be clear though: Both types provide identical protection against phishing.
Can it prevent AiTM phishing? Yes!
Like we discussed above, the AiTM proxy can try all it wants to pass along an authentication challenge for passkey-based sign-in. It simply won't work. Your browser knows it's not on the real sign-in page regardless of how convinced a human might be, and even if it tried to use the real site's key the attacker wouldn't walk away with anything of use to them.
Method Recap
| Method | Grade | Stops AiTM | Notes |
|---|---|---|---|
| Username and password only | F | No | Offers no additional protection. |
| SMS and voice codes | D | No | Better than nothing, worse than everything else. |
| Authenticator app codes (TOTP) | C | No | Decent at its job and easy to implement. |
| Tap-to-approve push notifications | C- | No | Very convenient for the user, until they get push bombed. |
| Push approval with number matching | B | No | Relatively convenient and not susceptible to push bombing. |
| Passkeys (FIDO2) | A | Yes | The new best practice. Actively prevents AiTM. |
So Was Your Authenticator App Rollout a Waste?
Definitely not! Every method that gets developed and becomes a standard was built in response to what came before it. That doesn't mean "what came before it" was pointless.
If you just finished a campaign to move all of your users onto TOTP off of SMS and called it a security win: You were right! You made a concrete improvement to your organization's security posture, and that's no waste.
Microsoft's push for passkeys as a default isn't about establishing everything else as a wasted effort. A better way to look at it is like they're saying:
We're retiring something you probably use right now. If you're going to be migrating anyway, why not migrate to the most secure option?
We highly recommend setting your users up for passkey authentication by default (AiTM phishing is a growing problem and passkeys are the solution), but credential stuffing and asynchronous phishing are still attacks that take place every second of every day. Any MFA method you can implement to nip those in the bud is absolutely going to be worth the effort to set up and manage.
What to Do Between Now and February
Early on, make a plan. Take inventory of what methods your users are actually registered for (both MFA and SSPR). Decide if you want to opt out of the September 1st changes before they drop, but remember the full set of changes in February are coming either way. You may already have SMS and voice methods disabled and passkeys enabled if your org has been proactive there, in which case very little will change for you.
If you or your team can handle this transition yourselves, Microsoft's documentation includes an official guideline on how to prepare. If you've got any questions or need a hand, we're here to help!
Schedule a consultation or email us at [email protected], and we'll walk your tenant with you. Let's fill the gap.