Passkeys + device intelligence: layered account takeover defense

Passkeys are the most significant improvement to consumer authentication in a decade, and the industry framing around them is subtly misleading. The framing is that passkeys "solve" account takeover. They don't solve it — they eliminate one class of it, the largest and most automatable class, and in doing so they push attackers toward the parts of the account lifecycle that passkeys structurally can't protect.

This piece is for security architects and product security teams deploying passkeys who want a clear-eyed map of what passkeys cover, what they leave exposed, and where a device intelligence layer fits. The thesis: passkeys and device intelligence are complementary. Passkeys harden authentication; device intelligence secures everything around it.

What passkeys actually fix

Passkeys fix credential theft by removing the shared secret entirely. There is no password to phish, no password to reuse across sites, no password sitting in a breach dump waiting to be stuffed. That closes the single largest account takeover attack surface in one move.

Mechanically, a passkey is a public-private key pair created per site using the WebAuthn and FIDO2 standards. The private key never leaves the user's device (or their synced credential provider); the site stores only the public key. Authentication is a cryptographic challenge-response: the site sends a challenge, the device signs it with the private key, the site verifies with the public key. Nothing reusable crosses the wire.

Two properties follow, and they're the ones that matter for ATO:

Phishing resistance. The passkey is cryptographically bound to the site's origin. A user who lands on a look-alike phishing domain cannot present their passkey there — the browser won't offer it, because the origin doesn't match. This defeats the entire real-time phishing proxy category (Evilginx-style attacks) that renders one-time-code MFA useless. The credential simply cannot be relayed to the wrong destination.

No shared secret to steal in bulk. There is no database of hashed passwords to exfiltrate, no credential list to buy, no material for credential stuffing. The economics of automated password attacks depend on stolen credentials being cheap and reusable; passkeys make them nonexistent.

For the flows a passkey actually governs — a user signing in on a device that already holds their passkey — this is close to airtight. If your entire user base authenticated exclusively with passkeys on devices they already own, the classic ATO playbook would be dead.

That is not the world any real service operates in.

The attack surface passkeys don't cover

Passkeys secure the authentication event. Account takeover is not limited to the authentication event — it targets the entire account lifecycle, and most of that lifecycle sits outside what a passkey governs. Four gaps matter.

Account recovery. This is the big one. Every service needs a way for a user who lost their device to get back in. That recovery path — email link, SMS code, security questions, backup codes, help-desk verification — is by definition a way to authenticate without the passkey. An attacker who can't defeat the passkey attacks the recovery flow instead, and recovery flows are typically far weaker than the primary auth they bypass. A passkey deployment with a "reset via SMS code" fallback has a phishable, SIM-swappable back door regardless of how strong the front door is.

Device enrollment. Adding a new passkey to an account is an account-modification action, and if an attacker can enroll their own device's passkey, they now have permanent legitimate access. Enrollment is usually gated by an existing authenticated session — which means it inherits the weaknesses of whatever established that session, including the recovery flow above. Enroll-a-new-passkey is the modern equivalent of "add a forwarding rule": quiet, persistent, and easy to miss.

Session hijacking. Passkeys authenticate; they don't continuously reauthenticate. Once a user has signed in, the resulting session token is a bearer credential like any other. Steal it — via malware, a malicious extension, a compromised device, or a token-exfiltration attack — and you have the authenticated session without ever touching the passkey. The strength of the login says nothing about the security of the hour that follows it.

The unenrolled long tail. Passkey adoption is real but partial. A meaningful fraction of any consumer user base will not have a passkey: older devices, shared or corporate machines, users who dismissed the prompt, users who don't understand it. Every one of those accounts still has a password-based or code-based path, and attackers concentrate on exactly that path. A service is only as protected as its weakest available authentication method, and for the unenrolled tail, that method is the old one.

The pattern across all four: strong authentication doesn't remove the incentive to take over accounts, it relocates the attack. This is the consistent lesson of the 2026 ATO landscape — as each vector hardens, attackers flow to the next-weakest one. Passkeys move the fight from the login form to the recovery flow, the enrollment step, and the post-login session.

Why device intelligence covers the gaps

Device intelligence covers the passkey gaps because it operates on a different axis: passkeys ask "does this user hold the right key," device intelligence asks "is this the device and context we expect for this account, on every action." The second question is answerable even when there's no passkey in play — which is exactly the situation in recovery, enrollment, and the unenrolled tail.

The mechanism is a persistent device identity: a stable identifier built from browser, hardware, network, and behavioral signals that recognizes a returning device across sessions without relying on a stored credential. (How that identifier is constructed and why it survives cleared cookies is covered in how device fingerprinting works.) With that identity attached to an account's history, each of the four gaps gets a control passkeys can't provide.

Recovery bound to known devices. When a recovery attempt arrives, device intelligence answers a question the recovery flow otherwise can't: is this recovery being initiated from a device this account has ever used? Recovery from a brand-new device in a new country on a data-center IP is categorically riskier than recovery from the user's usual laptop. That signal lets you tier the recovery flow — light verification from a known device, heavy verification (or a hold) from an unknown one — instead of applying the same weak SMS check to everyone.

Enrollment gated by device trust. A request to enroll a new passkey can be scored against the device history. Enrolling a passkey from the user's established device is expected. Enrolling one from a device that appeared minutes ago, immediately after a recovery event, from a suspicious network, is the signature of an account being seized. Device intelligence makes that enrollment request legible instead of invisible.

Continuous, post-login session scoring. Because device identity is evaluated on every request, not just at login, a session that starts on one device and continues on another — the fingerprint of a stolen token being replayed elsewhere — is detectable. The mid-session device or network context shifting away from the authenticated device is a hijack signal that no amount of front-door authentication strength can catch. This is the zero-trust device verification principle: trust is continuously evaluated, not granted once at the door.

Coverage for the unenrolled. For the users who never adopted a passkey, device intelligence is the layer doing the work — recognizing their known device and letting legitimate logins through with low friction, while flagging the credential-stuffing and unknown-device attempts that target exactly this population. The users most exposed by partial passkey adoption are the ones device intelligence protects most directly.

The through-line: passkeys prove key possession at one moment; device intelligence establishes device and behavioral context across every moment. The gaps in the first are precisely the domain of the second.

How the two layers combine in practice

In a layered deployment, passkeys and device intelligence run in parallel, each authoritative for the decisions it's suited to, feeding a single risk picture.

At login, a passkey where present is the strong primary factor — phishing-resistant, no shared secret. Device intelligence runs alongside it, silently confirming the device is known and the context is normal. For a passkey login from a recognized device, this is invisible: the user signs in, nothing prompts. The device signal is only consulted when it disagrees with expectation.

At recovery and enrollment, where no passkey is being presented (that's the entire point of these flows), device intelligence becomes the primary risk input. The smart signals verdict — known device, network reputation, behavioral consistency — determines whether the flow proceeds lightly, escalates to stronger verification, or holds for review. This is where the passkey deployment's real back door gets a lock.

Post-login, device intelligence provides continuous evaluation. The passkey's job ended at authentication; the device layer watches the session for the context shifts that indicate token theft, and can force reauthentication when the device signal breaks mid-session.

For the unenrolled, device intelligence carries the primary load at login too, distinguishing the returning known device from the credential-stuffing attempt, until (and if) the user adopts a passkey.

The division of labor is clean because the two mechanisms answer genuinely different questions and fail in genuinely different ways. A passkey can't tell you whether the device requesting a password reset is trustworthy; device intelligence can't provide phishing-resistant cryptographic proof of key possession. Deploying one without the other leaves a predictable hole — passkeys alone leave the recovery and session flows soft; device intelligence alone lacks the cryptographic authentication strength at the front door.

The honest framing for a passkey rollout

If you're rolling out passkeys, the accurate internal message isn't "we've solved account takeover." It's "we've eliminated credential theft as an attack vector, and we now need to harden the flows attackers will move to." Those flows — recovery, enrollment, session, and the unenrolled tail — are where the next round of ATO attempts will concentrate precisely because the front door got strong. A passkey rollout that doesn't simultaneously harden recovery is moving the lock from the door to the window while leaving the window open.

That hardening is what a device intelligence layer provides, and it's why the strongest ATO postures pair the two. Passkeys make the authentication event nearly unbeatable. Device intelligence makes the rest of the account lifecycle — the parts an attacker turns to because the authentication event got unbeatable — observable and scoreable.

Tracio supplies the device intelligence half of that pairing: a persistent device identity that survives cleared cookies and fresh sessions, network and behavioral risk signals, and a verdict returned in under 50ms that plugs into recovery, enrollment, and continuous session checks. It runs quietly behind passkey logins from known devices and steps forward exactly where passkeys can't reach.

Want to see how device intelligence covers the flows your passkey deployment leaves open?

Start your free trial — 2,500 verifications free, no credit card required. Book a demo to map device intelligence against your authentication, recovery, and session architecture.