Sometime before 1 February 2027, an email from Microsoft will land in your security queue: native SMS and voice authentication in Entra ID retires on that date, with no opt-out. On its own it reads as a login-factor change: phishable codes out, phishing-resistant passkeys in. It is the first visible symptom of the post-password shift in how account takeover works.
This article follows that shift in two stages: why phishable factors are being retired, then what still gets through after the strongest login.
What is Microsoft’s timeline for retiring SMS and voice authentication?
Microsoft retires its own SMS and voice delivery in Entra ID on 1 February 2027, with no opt-out, according to Microsoft’s official documentation. Passkeys become the default sign-in experience on 1 September 2026. SMS and voice users are then auto-enabled for passkeys and prompted to register at their next sign-in, per Microsoft’s security blog.
The Graph setting that delays auto-enablement can push back the September registration campaign, but it does not delay the 1 February 2027 retirement. After that date, SMS-or-voice-only users face a blocking passkey-registration screen.
Tenants with a regulatory or operational need can keep SMS and voice through a customer-managed telecom provider, listed in the Microsoft Security Store from 18 September 2026. For everyone else, Microsoft provides an SMS-and-voice usage analyser to help you discover affected users. The migration decision is covered in the Entra ID migration.
Why are SMS and voice authentication no longer secure MFA methods?
The dates matter because the factor underneath them was never sound. An SMS or voice code proves possession of a phone number, not cryptographic control of a device. The telecom channel was built to deliver calls and texts, not to act as a security layer.
The simplest failure is that the code is relayable. In an adversary-in-the-middle flow, the attacker proxies a live login and forwards the code as it arrives, so the real user completes the attacker’s session.
SIM swapping ports the number to an attacker’s SIM, and SS7 signalling exploitation intercepts calls and texts. Neither takes much to start: an SS7 interception needs a Linux machine and a downloadable SDK. Help-desk social engineering bypasses the factor altogether, and it is routine rather than rare. Scattered Spider’s 2025 vishing run against UK retailers is one recent example.
That is why regulators have moved on. CISA, NIST SP 800-63B and OMB M-22-09 deprecate SMS, voice and simple OTP push as phishing-resistant factors. A one-time code is not bound to the origin that requested it.
Why is Microsoft making passkeys the default authentication method in Entra ID?
Passkeys are phishing-resistant where SMS and voice are not. A passkey uses asymmetric cryptography bound to the relying party’s origin, so the private key never leaves the device and a fake domain cannot replay it.
From 1 September 2026, passkeys become the default sign-in experience in Entra ID. Microsoft reports 600 million identity attacks a day and says phishing-resistant MFA blocks more than 99% of identity attacks, calling the change “better for users and worse for cyberattackers”. This is a change of default behaviour rather than an instant cutover; most tenants will run a managed registration campaign.
That turns a recommendation into an obligation for the millions of tenants still on phishable factors. The mechanics of origin binding are covered in how passkeys actually work.
How does Kali365 bypass MFA by stealing OAuth tokens?
Kali365 is the clearest evidence that the problem is bigger than login factors. The FBI flagged it as a phishing-as-a-service platform that captures Microsoft 365 OAuth tokens, and the trick is simple: the victim completes a real login, MFA included, and the kit takes what follows.
The FBI’s public service announcement describes a chain of lure, authorisation, then token theft. The victim pastes an attacker-supplied device code into the legitimate Microsoft page and unknowingly authorises the attacker’s device, completing sign-in against the real identity provider. The second factor is satisfied, yet the attacker walks away with the OAuth access and refresh tokens rather than a password.
It runs as a multi-tenant service with reseller tiers, AI-generated lures and shared token dashboards. The device-code flow defeats even passkeys, because the abuse happens at the authorisation layer after login, as Push Security explains. More on that in how AI is changing identity fraud.
The password never changes hands, so resetting it and re-enrolling MFA does not stop the attacker.
Why does token theft still defeat MFA even with passkeys?
MFA authenticates the user at login. It does not bind the session that follows. That gap is where token theft lives.
After login, the identity provider issues a session cookie or an OAuth token. It is a bearer credential: whoever holds it inherits the authenticated session without re-authenticating. Obsidian Security describes a token as granting “access until expiration or revocation”, with no second factor required. Steal and replay that token, and the earlier authentication is defeated.
Passkeys make the login moment phishing-resistant, but they do not bind the session issued afterwards, the gap covered in the broader identity stack. The emerging fix is Device Bound Session Credentials, or DBSC. Google’s proposal binds the session to the device cryptographically so an exfiltrated cookie cannot be replayed elsewhere. Continuous Access Evaluation revokes access in near real time when risk changes.
MFA still closes the most common entry point, credential phishing at login.
What emerging threat-actor tactics target passkeys?
Attackers target the authorisation and session layers around the passkey, where a legitimate login still issues a stealable token.
Device code phishing is the clearest example, and Kali365 showed how it works: the login completes, and the attacker collects the OAuth tokens issued afterwards. The passkey is never exercised, because the attack sits at the authorisation layer. Push Security measured a 37.5x rise in device code phishing pages by April 2026, and Huntress tracked a 1,380% jump in detections, as compiled in Stingrai’s 2026 statistics.
AiTM reverse-proxy phishing does the same job with a live relay, harvesting the session cookie in transit. Kits like Kali365, Tycoon 2FA and the open-source Evilginx framework industrialise both flows, as WorkOS documents. Tycoon 2FA ships JavaScript that steers users away from passkey prompts, so the passkey stays intact while the attack routes around it.
The response sits at the same layer. Block or scope the device code flow with Conditional Access, restrict OAuth consent, and pair DBSC with Continuous Access Evaluation to blunt token reuse. See also non-human identities and OAuth governance.
The SMS retirement marks the point where the threat moves. Passkeys close the phishing door at login, but because MFA never binds the session that follows, token theft still defeats it, and the fight shifts to the session and token layer.
That changes the question you ask. Instead of “how strong is my login?”, ask “what happens to the session after login?”. Retiring SMS and voice is a dated, no-opt-out obligation worth planning now, but the migration is the start, not the end. Block device code phishing, adopt DBSC as it matures, and lean on Continuous Access Evaluation. The login factor is only one of the two surfaces that now need defending, and only part of the full identity picture.
Frequently Asked Questions
Is MFA pointless if token theft still defeats it?
No. MFA is not pointless; it still closes the most common entry point, which is credential phishing at the login step. Token theft is a separate risk that targets the session after MFA has already succeeded. Passkeys and other phishing-resistant factors block the overwhelming majority of identity attacks, but the authenticated session is a bearer credential that must be protected in its own right with measures like Device Bound Session Credentials and Continuous Access Evaluation.
Do I have to stop using SMS for MFA straight away?
No. There is no need to switch off SMS today, because Microsoft’s native Entra ID retirement does not take effect until 1 February 2027. You should act now, though. Passkeys become the default sign-in experience on 1 September 2026, and migration needs planning. Start by running the SMS and voice usage analyser to find affected users, then phase the move and prepare help desk support before the deadline.
What happens if our tenant misses the 1 February 2027 deadline?
Native SMS and voice authentication is retired with no opt-out, so users who still rely on it after 1 February 2027 can be left without a working factor and may need help desk intervention to regain access. That is why discovery and migration should happen well before the deadline. Organisations with a genuine regulatory need can continue through a customer-managed telecom provider configured in the Microsoft Security Store.
Does the SMS and voice retirement affect personal Microsoft accounts?
No. The announced retirement applies to native SMS and voice authentication in Microsoft Entra ID, which is the platform behind work, school, and business sign-ins. Personal Microsoft accounts are managed separately and are not part of this February 2027 deadline. Even so, the underlying risk is the same wherever SMS codes are used, so a personal account still benefits from moving to passkeys or an authenticator app.
Can I keep using Microsoft Authenticator instead of moving to passkeys?
You can keep using Microsoft Authenticator in the short term, and its number-matching approval is a significant step up from SMS because it is not a simple relayable code. However, push-based approval is not classified as phishing-resistant the way passkeys are. The September 2026 passkey default makes passkeys the recommended long-term path, so treat the authenticator as a bridge rather than the destination.
Are passkeys really impossible to phish?
At the login step, yes. A passkey is bound to the relying party’s origin, so the private key never leaves the device and a fake domain cannot replay it the way an SMS code or password can. The important caveat is that passkeys protect only the login moment. After login, the session cookie or OAuth token is still a bearer credential that attackers can steal, which is why token theft can still defeat the account.
What is a session cookie or OAuth token in plain terms?
Think of it as the wristband you get after passing the ID check. Once you authenticate, the identity provider issues a session cookie or OAuth token that proves you are logged in. Whoever holds that credential inherits your authenticated session without needing your password or passkey. Because it works like a bearer instrument, stealing and replaying it defeats the earlier login, which is exactly how token theft bypasses MFA.
Do passkeys still work if I lose my phone?
Yes, provided you plan for recovery. Most passkeys sync through your Apple, Google, or Microsoft account, so a lost phone does not mean a lost credential, and many people keep a second passkey on a hardware security key as a backup. The key point is to set up a recovery method before you need it. Passkeys remain usable as long as you can authenticate to the syncing account or have another registered device.
What is Device Bound Session Credentials (DBSC) and is it available yet?
Device Bound Session Credentials, or DBSC, is an emerging standard that cryptographically ties your session cookie to the device that logged in. That means a cookie stolen from that device cannot be replayed from an attacker’s machine. It is still in development and early adoption rather than a default you can switch on today. Until it matures, treat it as the direction of travel and pair it with Continuous Access Evaluation to shrink the stolen-token window.
What should I do if I receive an MFA prompt I did not request?
Do not approve it. An unexpected prompt usually means someone already has your password and is trying to complete a login, so approving it hands them the session. Deny the request, reset your password, review recent sign-in activity, and report it to your security or IT team. If your organisation uses number matching, only enter a code that appears on the screen you are actually logging in to.
Is Face ID or a fingerprint the same as a passkey?
No. Face ID and fingerprints are a local unlock. They prove to your own device that you are you, and then the device uses the passkey’s private key to authenticate to the website. The biometric data never leaves the device and is never sent to the relying party. A passkey can also be stored on a security key with no biometrics at all, so the two ideas are related but not the same thing.
