The attacker skips your login and steals the cookie

Passkeys are WebAuthn credentials. Asymmetric keypairs, origin-bound, resistant to phishing at the moment of authentication. The private key never leaves the authenticator. The relying party stores only the public key. A signed assertion proves possession without transmitting a shared secret. That design ends credential phishing. It does not end session hijacking, and the industry keeps treating the two as the same win.

State the phishing resistance precisely, because it is real. WebAuthn binds every assertion to the relying party ID, the RP ID derived from the origin. When an authenticator signs the server’s challenge, the signature covers the origin the browser is actually talking to. A real-time phishing proxy sits on a lookalike domain. Its RP ID does not match the legitimate one. The assertion the authenticator would produce is scoped to the proxy’s origin, not the target’s, so the relay produces nothing usable. This is why passkeys defeat Evilginx, Modlishka, and EvilProxy, the adversary-in-the-middle kits mapped to MITRE T1557 and T1111 that harvest passwords and relay OTPs live. Against a passkey the proxy captures a signature that validates for the wrong domain.

So the attacker stops attacking the login and attacks everything downstream of it.

Authentication and authorization are separate events. The passkey governs the first. After the assertion validates, the relying party mints a session, a cookie, an OAuth access token, a SAML assertion, an ID token. That artifact carries state for the rest of the session. In almost every deployment it is a bearer token, trusted on possession alone, no proof required from the holder. The passkey is not re-presented on each request. It signed once, at the door.

Steal the token after issuance and the passkey stops mattering. This is MITRE T1539, steal web session cookie, and T1550.004, use of the stolen cookie as alternate authentication material. The token was minted for a phishing-resistant login. It replays identically from an attacker’s host, because the resource server validates the token, not the authenticator that produced it. Nothing in the WebAuthn ceremony reaches forward to bind the session that follows it.

Endpoint theft is the common path. Infostealers, Lumma, RedLine, Raccoon, StealC, read browser credential stores directly. On Windows the target is the Chrome cookie database at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies, decrypted with the DPAPI-protected key held in Local State. Chrome 127 introduced app-bound encryption to tie that key to the browser process. Stealers adapted, using local elevation or the browser’s own remote debugging interface to decrypt in place before exfiltration. The cookie leaves the box and gets replayed. The passkey enrolled on that machine never participates in the theft or the replay.

On the endpoint the theft leaves a signature even when the replay does not. Sysmon Event ID 1 records the stealer process spawning, often from a user-writable path with no signature and no parent lineage that fits the host. Event ID 11 records file creation and access against the browser’s Cookies and Login Data SQLite stores. Event ID 10 records cross-process access into the browser process, the handle request a stealer needs to decrypt app-bound cookies in place. For the elevation-plus-remote-debugging variant, the browser relaunches with a —remote-debugging-port argument visible in the process command line, a strong and cheap detection. These fire on the machine that gets robbed. Once the cookie is off the box, the resource server has no comparable signal, which is the split defenders keep underestimating.

Cookie replay produces no authentication event. The token was already issued during the legitimate login, so the identity provider logs one clean passkey sign-in and nothing after it. When the attacker replays the cookie, the resource server sees a valid session and serves it. Okta’s system log holds the original user.authentication.auth_via_mfa with no second challenge. Entra ID shows one interactive sign-in with authenticationMethod set to FIDO2, then silence. There is no login to flag because the attacker never logs in. The strongest authentication event in the tenant sits next to a session that any thief can wear.

Detection moves to session behavior. A new device fingerprint on an existing session. A user-agent string that changes mid-session. A source ASN shifting from a residential range to a hosting provider, the token used from a datacenter IP it was never issued to. Impossible travel between the issuance IP and the replay IP. These are behavioral signals, not authentication signals, and they fire in the resource layer or the CASB, not in the passkey ceremony. Token binding would close this by cryptographically pinning the token to the client that requested it, but browser token binding was deprecated and removed years ago. DPoP, RFC 9449, supplies proof-of-possession for OAuth tokens and stays thinly deployed. Absent one of those, every passkey-authenticated session terminates in a bearer token that travels as well as any stolen password ever did.

The correlation that catches replay is not a single rule. It joins the issuance context of a token, device, ASN, geo, client fingerprint, to every later use of that same token and alerts on divergence. Few SIEM deployments retain issuance context long enough to make the join. That gap is a configuration choice, not a platform limit, and it is where passkey-authenticated sessions quietly become replayable without a single failed sign-in.

Session-token theft bypassing strong authentication is not theoretical. In the October 2023 Okta support-system breach, an actor accessed customer support cases and extracted session tokens embedded in uploaded HAR files, then replayed those tokens against downstream customer tenants. The MFA on those accounts, passkey or otherwise, did nothing, because the token was already authenticated and the attacker never touched the login. Infostealer logs feeding markets such as Russian Market sell exactly this material, valid session cookies priced by target, sold specifically so a buyer can skip authentication entirely. AiTM phishing tracked as Storm-1167 industrialized the same outcome against password-plus-OTP accounts. The passkey removes that specific relay. The cookie economy that sits behind it stays open for business.

The sharper move is enrolling a new passkey. An attacker with a live session, from cookie theft, from a token replay, from a coerced OAuth consent grant, opens account settings and registers their own authenticator. Now the attacker holds a first-class credential bound to a device they control. A password reset does not evict it. Revoking the stolen cookie does not evict it. This is MITRE T1098.005, device registration, alongside T1556-class modification of the authentication process. The victim’s own phishing-resistant factor now guards the attacker’s access, and it does so with the full trust the relying party assigns to a passkey.

Treat enrollment as the high-signal event. Okta emits user.mfa.factor.activate on registration. Entra ID writes a security-info-registered entry to the audit log. A new WebAuthn credential added shortly after a sign-in from an unusual context is a persistence indicator, not a routine settings change. Most detection programs watch the login and ignore the enrollment. That priority is inverted.

A passkey raises the floor only when nothing weaker sits beside it. Most accounts keep fallbacks, SMS OTP, an email magic link, a retained password, KBA-driven support recovery. The attacker ignores the passkey and triggers account recovery to land on the fallback. SIM swap against the SMS path, MITRE T1111 again. Help-desk social engineering against manual recovery, the vector Scattered Spider used against MGM and Caesars, where human verification at the support desk, not cryptography, was the control that failed. The passkey is bypassed, not broken. A phishing-resistant factor next to an SMS reset is an SMS account with extra steps.

FIDO split passkeys into device-bound and syncable. Syncable passkeys, the default consumer experience, replicate the private key through a platform vendor’s cloud, iCloud Keychain or Google Password Manager. That buys painless recovery, but the key material now rests inside a cloud account. The security of the passkey collapses into the security of that account and its recovery flow. Compromise the Apple or Google account and the synced passkeys come with it. The authenticator is no longer discrete hardware holding a non-exportable key. It is a record in a synced vault, and the vault carries its own phishing surface and its own recovery weaknesses. Device-bound passkeys on a hardware security key or a platform TPM do not sync and do not inherit this exposure. Deployment decisions rarely draw the distinction.

Cross-device authentication narrows one window without closing the risk. The hybrid transport, formerly caBLE, lets a phone authenticate a desktop session over BLE plus a QR handshake. The BLE proximity requirement blocks remote relay of the assertion, so an attacker cannot complete the ceremony from another continent. The QR handshake is still social-engineerable at registration time, and the added channel has to be reasoned about rather than assumed clean.

Passkeys are a real improvement at the authentication step. They remove the shared secret, they defeat real-time credential relay, and they cut the largest single category of account takeover. Deploying them is correct. The error is treating the ceremony as the whole control. The session token issued after a passkey login is a bearer token unless proof-of-possession is enforced. The recovery path is only as strong as the weakest enrolled factor. A stolen live session can register a fresh passkey and convert a phishing-resistant design into an attacker’s persistence mechanism. The vulnerability moved from the credential to the session and the lifecycle around it. Detection has to move with it, into session-layer anomaly correlation, factor-enrollment monitoring, and removal of weak recovery fallbacks. The login got harder to phish. Everything after the login stayed exactly as soft as it always was.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.