When Passkeys Beat Phishing but Lose to a Stolen Token

An infostealer infection now yields an attacker roughly 44 passwords and 1,861 browser cookies, according to password and passkey usage research published in mid-2026. That's 42 cookies for every password. The ratio says more about where value sits in a modern account takeover than any vendor deck, and it explains why organizations that bought multi-factor authentication years ago are still writing incident reports.

The supporting numbers line up. SpyCloud recaptured 8.6 billion stolen session cookies and session artifacts in 2025, and an analysis of infostealer logs from June 2025 to June 2026 counted 52.4 billion browser cookies in circulation. Proofpoint found that 59% of the accounts attackers successfully took over had MFA enabled at the time, and Obsidian Security reported that MFA failed to prevent the attack in 84% of the incident responses its team handled.

The standard answer has converged on FIDO2 and WebAuthn, delivered as a synced passkey or a hardware key. The FIDO Alliance counted 5 billion passkeys in active use by World Passkey Day in May 2026, with 87% of organizations somewhere in a rollout, and Palo Alto Networks' 2026 Unit 42 Global Incident Response Report ranks phishing-resistant MFA as a priority for high-value roles. Both recommendations are sound. They also describe a control that closes one attack class almost completely while barely touching another.

How a Session Token Survives the MFA Check

When you sign in to Microsoft 365, Google Workspace or Salesforce, the service hands your browser a session token, a string presented on every later request so you don't re-enter a password and a code on every click. Most SaaS applications implement it as a bearer token, which means the server validates the token and never asks who is carrying it. A hotel keycard is the right physical comparison, because the lock reads the card and never looks at the face.

Adversary-in-the-middle phishing exploits precisely that. The victim lands on a lookalike domain that proxies the genuine sign-in page in real time, credentials and the one-time code go into the proxy, and the proxy relays them upstream. The real session cookie comes back through the proxy to the attacker. Nothing is cracked, and from the identity provider's side a legitimate browser completed a legitimate login, often from an IP that matches the victim because the proxy sits in the same region.

Loading Diagram...(Hard refresh if it doesn't appear)

A one-time code, a push approval or an SMS message is a transferable secret typed into whatever interface is in front of the user, and a proxy is just another interface. The second factor proves the victim is present. It says nothing about whether the destination is legitimate.

What Origin Binding Actually Stops

A WebAuthn credential works on different terms. At registration the authenticator generates a key pair and pins the public half to a relying party identifier, which in practice is the site's registrable domain. At login the server sends a random challenge, the browser assembles a client data object naming the exact origin of the page making the request, and the authenticator signs both with a private key that never leaves the secure element, whether that's a YubiKey's chip, a phone's secure enclave or a laptop's TPM.

The origin string is what ends the phishing problem. A lookalike domain can't ask the browser for a credential scoped to login.microsoft.com, because the browser enforces that scoping before the authenticator is touched. Build a proxy to get around it and the signed assertion still names the attacker's origin, which the real server rejects. A one-time code is a password spoken out loud that anyone listening can repeat. A WebAuthn assertion is a key cut for one lock, in a shape that observation can't copy.

A hardware key adds two properties software credentials can't fully match. The private key is generated on the device and marked non-exportable, so malware on the host can't lift it, and the touch gesture requires a human present on the actual device, which removes the remote automation that makes push bombing cheap. That's why NIST SP 800-63-4 and CISA define phishing-resistant authentication around FIDO2/WebAuthn, hardware keys and PKI smart cards, and why SMS, voice and push never qualify. None of it changes the token. A passkey makes the login close to unphishable and still hands you a bearer cookie sitting in a browser profile that an infostealer can read.

Choosing Between Synced Passkeys and Hardware Keys

Two credential classes dominate real deployments, and they fail in different places. A synced passkey lives in a cloud keychain replicated across devices and recoverable through the account that holds it. A device-bound credential such as a security key, or Windows Hello with no sync, can't be exported, so losing the device means falling back to a backup.

Cost and logistics decide most of these calls. A hardware key is a physical object with a shipping address, a breakage rate and a replacement cycle, and every privileged user needs at least two. Synced passkeys cost almost nothing to issue and travel with the user, which is why they spread through consumer and mid-market identity faster than keys ever managed. The tradeoff is that trust moves into the cloud account, and that account becomes the recovery path an attacker targets instead.

Deployment rates track device management more than regulation, so workforces on managed laptops move first and contractor-heavy or mobile-first workforces trail. Mature programs compose both classes, with hardware keys and PINs for administrators and payment approvers, and synced passkeys for everyone else.

Device Code Phishing Uses the Login Page as Designed

The OAuth 2.0 device authorization grant in RFC 8628 exists for hardware that can't take a password comfortably. A smart TV, a printer or a conference room panel displays a short code, the user completes sign-in on a phone or laptop, and the resulting token returns to the device that started the request. That last clause is the whole vulnerability.

A device code campaign starts the flow on the attacker's machine. The attacker gets a code and sends it to a target, dressed up as a shared document or a device enrollment step. The victim opens the genuine microsoft.com/devicelogin page, types the code and completes a real MFA challenge on real infrastructure, possibly with a real passkey. The token lands on the attacker's device. No lookalike domain is involved, so no origin check ever fires, and the victim's own logs record a successful authentication.

The criminal economics caught up quickly. Push Security documented a 37.5x surge in device code phishing pages by early April 2026, attributed largely to EvilTokens, a phishing-as-a-service kit that appeared on Telegram in mid-February 2026 and flattened the skill requirement. Mimecast counted more than 50,000 malicious campaigns exploiting the flow since March 2026. On September 22, Microsoft's Digital Crimes Unit announced it had disrupted EvilTokens, which the company tracks as Storm-2992 and ties to more than 12,000 compromised inboxes across over 10,000 organizations. The fix is a policy setting, not a cryptographic upgrade: block the device flow in Conditional Access except for groups that genuinely need it, and alert on the DeviceCodeFlow events that land in sign-in logs. An organization that ships YubiKeys to every employee and leaves that flow open has spent a large budget hardening a door the attacker walks around.

The Arithmetic of a Fourteen Percent Rollout

Okta's Secure Sign-in Trends data put phishing-resistant authenticator adoption at 14.0% of users in 2025, up from 8.6% a year earlier, a 63% increase. That's solid growth from a low base, and 86% of users stayed on phishable factors in the year session hijacking became the dominant identity attack. I'd argue the 14% line tells you more about near-term risk than the five billion passkey milestone does, because announcements count credentials while incidents count coverage.

Compound it forward and the picture gets awkward. A sustained 63% annual increase takes 14% past half of a user population in roughly two and a half years, which is late in the decade, and identity growth rates rarely hold that slope. The remaining population is contractors, shared workstations, field staff on personal phones and on-premises applications that speak LDAP and nothing else. The last fifth of an authentication migration is the part that eats the budget.

A second ratio makes the prioritization argument for you. Microsoft's 12,000-plus compromised inboxes across more than 10,000 organizations works out to about 1.2 mailboxes per tenant, the profile of a volume business that spreads wide and shallow rather than a campaign aimed at one company. An attacker operating at that ratio is hunting for the tenant where the mailbox belongs to someone who can approve a payment, which is why concentrating phishing-resistant MFA on high-value roles first is a sequencing decision and not a compromise.

Where Recovery Quietly Undoes the Design

The seam in the passkey story is recovery, and 2026 research has been working it. DEF CON 33 presentations and follow-up work in August 2026 showed that synced private keys can be recovered and that some phishing-resistant flows can be bypassed under specific conditions, generally after a device or cloud account holding the key material is compromised. Device-bound keys close that gap and make the backup credential mandatory rather than optional.

The help desk remains the cheapest bypass in the building. An attacker who talks a service desk into re-enrolling a credential never has to phish anything, and no WebAuthn cryptography reaches that conversation. Identity teams that hardened the front door are finding the side entrance staffed by a contractor with a script and a tight handle time target.

What nobody has solved is the token. Token binding standards such as DPoP exist for OAuth APIs, and device-bound token protection works inside single ecosystems like Entra ID, but no widely deployed mechanism binds a browser session to a hardware key across arbitrary third-party SaaS applications. A cookie copied out of a browser profile still opens the account that a passkey just protected, and the credential's guarantee expires the moment the login completes.