Passkeys Become the Default and the Attacks That Matter Don't Care
The announcement everyone's applauding. It fixes one thing and it isn't the thing that gets tenants owned.
Microsoft is retiring SMS and voice authentication on February 1, 2027, and making passkeys the default experience in Entra ID. The framing is bold: "the AI era demands stronger, phishing-resistant authentication." And to be fair, passkeys are a genuinely good technology. If your threat model is a fake login page harvesting a password and an SMS code, this change closes that door for good.
But here's the uncomfortable part for anyone who actually attacks these tenants for a living: the login page was never where the serious compromises happened. Passkeys make the front door incredibly strong while every window in the house stays exactly as open as it was yesterday. This is a real upgrade to one step of authentication being sold as a fix for phishing as a whole. It isn't.
Passkeys Fix the Credential, Not the Session
A passkey proves, cryptographically and un-phishably, that the right user is standing at the right origin at the moment they log in. That's the entire benefit and it's a narrow one. The reason tenants get taken over isn't that attackers can't beat a login prompt. It's that the valuable thing in Entra ID isn't the login it's the token you're holding afterward.
Once authentication succeeds by password, by SMS, or by the shiniest passkey the system hands out a bearer token: a portable credential that grants access simply by being presented. Nothing about it remembers that a passkey created it. Steal it, replay it from anywhere, and Entra ID happily trusts it. Passkeys guard the moment of login. The attacks that matter operate on everything that comes after it.
Device Code Phishing: Passkeys Actively Help the Attacker
This is the vector that best exposes the gap, because passkeys don't just fail to stop it they make the victim more confident while it happens.
In a device-code attack, the attacker never builds a fake page. They ask the real Microsoft to start a login, get a genuine code and a genuine Microsoft URL, and send those to the victim. The victim goes to the authentic Microsoft site and completes login and now they log in with a passkey, on the real origin, so every "phishing-resistant" check passes perfectly. The attacker, who initiated the flow, silently collects the resulting tokens.
There is no fake site to detect and no password to steal. The passkey ceremony succeeds exactly as designed, on Microsoft's own domain and hands the attacker a working session. "Phishing-resistant authentication" resisted nothing, because the human was never the weak link. The flow was.
Making passkeys the default does not touch this. If anything, the polish of a smooth passkey prompt removes the last bit of friction that used to make a wary user pause.
The Rest of the Kill Chain Rides on Legitimate Authentication
Here is the thread that ties the real attacks together, and it's exactly why passkeys can't help: these vectors don't defeat authentication they ride on top of authentication that succeeded legitimately. Making that legitimate authentication stronger does nothing to a technique that was already going to let the login succeed. Look at how tenants actually fall:
Device code phishing. As above the victim authenticates for real, on the real Microsoft, with their real passkey. The login is 100% legitimate. That's the whole point of the attack, and a stronger factor only makes the victim more confident.
Applications that don't enforce MFA. A passkey default is meaningless if the sign-in never demands a second factor in the first place. Legacy protocols, misconfigured Conditional Access, excluded apps, and break-glass paths still allow logins that never trigger a passkey prompt at all. Attackers hunt for exactly these gaps and "passkeys are the default" does not equal "passkeys are enforced everywhere."
Third-party and OAuth applications. Consent phishing needs no login, no MFA, and no passkey ever. The victim clicks "Accept" on a third-party app's permission screen; grant it Mail.Read and the attacker reads mail through the API indefinitely. The access is durable and rides entirely on a legitimate consent grant. The world's best passkey is never even invoked.
Token and session theft (adversary-in-the-middle). The attacker relays the real login and steals the session it produces. That session is a legitimately issued, replayable bearer token still the prize no matter how it was minted.
Refresh-token and PRT abuse. On a foothold machine, the token from an already-completed, fully legitimate login gets reused to mint fresh access with no prompt. The passkey did its job hours ago; the attacker lives off its leftovers.
Application and service-principal credentials. Machine identities don't do passkeys. Add a rogue secret or certificate to an over-privileged app registration and you have a legitimate login that never sees a human factor at all.
Every one of these survives February 1, 2027 completely intact. None of them fights the passkey they all depend on authentication being valid, which is the one thing a stronger factor guarantees them.
Why This Is Feature Removal Dressed as a Fix
The honest description of this change is: Microsoft removed its two weakest methods and upgraded the default to a strong one. That's good hygiene. But it's being marketed as an answer to phishing, and phishing in 2026 overwhelmingly means stealing or abusing the token, not fooling someone at the sign-in box.
You cannot deprecate your way out of a system whose entire prize is a portable, replayable credential. Retiring SMS and defaulting to passkeys changes how strongly the user proves who they are. It changes nothing about what the attacker walks away holding. That mismatch is the whole problem.
A Fix Worth Being Excited About: Make the Stolen Token Worthless
Here's the shift that would actually move the needle and it flips the model. Stop pouring all the effort into the authentication step and put it into the artifact that step produces. Make the token so tightly bound to the machine that earned it that stealing it accomplishes nothing.
- Bind the token to hardware (proof-of-possession). Replace bearer tokens with sender-constrained ones, each token cryptographically welded to a private key that lives in the device's secure hardware and never leaves it. Replay it from any other machine and it's instantly dead. Device-code phishing and token theft both collapse, because the thing you steal is inert off the origin device. This is what "phishing-resistant" should have meant: resistant at the token, not just at the prompt.
- Retire the Device Code flow for humans. There is almost no legitimate reason for a person in a corporate tenant to log in via device code. Lock it behind an explicit allowlist for genuine IoT/CLI cases instead of leaving it globally available for any attacker to trigger.
- Make trust continuous, not a one-time gate. Tie a session's validity to live signals such as device posture, key attestation, and impossible travel, and revoke in near-real-time the moment the binding breaks, rather than trusting a token until it expires on its own.
The winning move isn't "make the human prove themselves better." It's "make the thing they receive afterward useless to anyone but the machine that earned it." Bind the credential to hardware, and phishing the login stops paying out.
That is the difference between security theater and security. Deprecating SMS treats a symptom that was already fading. Sender-constrained, hardware-bound tokens attack the disease: the replayable bearer credential that every serious Entra ID intrusion ultimately depends on. Retire the bearer token, not the text message and watch the entire phishing economy around this platform lose its payout.