The Outlier Lab

Passkeys and Phishing-Resistant Authentication

FIDO/WebAuthn credentials bound to your domain that can't be relayed or read aloud; strongest login defense, but recovery, enrollment and authorized scams remain open.

What it is

A passkey is a FIDO credential built on WebAuthn and CTAP. The service stores a public key. The private key stays in the authenticator: a phone, computer, password manager or hardware security key. Every login is a signature over a fresh challenge, and the signature is scoped to the website or app it was registered for. There is no code to send or read out and no password to reuse. A credential registered for the genuine domain does not respond to a look-alike domain, and that domain binding is what makes it phishing-resistant. The biometric is only the local check that releases the key on the device.

Two flavors matter to a fraud team.

Synced passkeysDevice-bound passkeys
Where the key livesA passkey provider's cloud, end-to-end encrypted and copied to the user's devicesOne device or security key; never leaves it
RecoverySurvives device loss if the provider account survivesLost device means rebinding through recovery
NIST 800-63B-4Allowed at AAL2; not allowed at AAL3 (key is exportable)Can meet AAL3 when hardware-backed
Fraud implicationTrust partly depends on the security of the provider accountStronger device binding; more recovery load

What it stops (and what it doesn't)

Stops or sharply reduces:

  • Credential phishing, including real-time relay pages, because the credential won't work on the attacker's domain.
  • Talking a customer into reading out a code ("read me the code we just sent"), because there is no code.
  • Password stuffing and spraying, once passwords are actually removed (see failure modes).
  • SIM-swap-driven takeover of accounts that no longer have SMS as an enabled factor.

Doesn't stop:

  • Recovery. If "lost my passkey" falls back to email or SMS, the account is only as strong as that fallback. Recovery is where attackers go next (Secure Account Recovery Design).
  • Session theft after login. A stolen session token is valid whatever produced it. Re-assert at the transaction (Risk-Based Authentication and Step-Up).
  • Authorized fraud. In Investment Scams (Pig Butchering), Impersonation Scams and other APP scams, the real customer signs in with their real passkey.
  • Enrollment by an attacker. If an attacker gets in through a weaker path and registers their own passkey, they now hold a strong credential to the victim's account.
  • Compromise of the provider account. A synced passkey inherits some risk from the cloud account that syncs it. Weigh this as a conceptual dependency; in practice it is an uncommon attack path.

Design considerations

  • Use passkeys for transactions as well as login. A WebAuthn assertion can be requested at withdrawal, payee add, payout change, outbound ACATS or large trades. That gives you a fresh, origin-bound proof for the action that causes the loss. In card payments, Secure Payment Confirmation (SPC) and passkey-based authentication are being built into EMV 3DS 2.3.1 (3-D Secure and Card Verification).
  • Treat registering a new passkey as a high-risk account change. Require an existing strong factor, notify all channels, and consider a cooling-off period on payouts after a new credential is added (Contact Change Cooling-Off Periods).
  • Plan to remove passwords and SMS. Adding a passkey while leaving the password and SMS in place gives customers another option and leaves every phishable path open. Track the share of value-holding accounts that have no phishable factor left.
  • Use the metadata. WebAuthn tells you whether a credential is backup-eligible (synced) and whether user verification happened. Optional attestation can identify the authenticator model. Use this to set policy: some actions may require device-bound or recently verified credentials.
  • Native apps. Use platform APIs, which carry the same domain binding. Avoid homegrown key storage that loses the guarantees.
  • Agentic and delegated access. As AI agents and aggregators act for customers, passkeys stay with the human. Design delegated authorization separately (Agentic Commerce Fraud).

Industry lens. Brokerage and neobanks get the most value, because phishing-driven ATO feeds Ramp-and-Dump via Account Takeover and RTP cash-out (see Case Study - Japan Brokerage Account Takeovers (2025)). Rewards apps face cheap-to-run account-takeover waves aimed at small balances, and passkeys raise the attacker's cost per account. Marketplaces should prioritize seller accounts that control payouts.

Implementation path

StageWhat it looks likePrerequisites
CrawlOffer passkeys as an optional login method alongside the password; prompt after a successful login; notify on registrationWebAuthn server support; device-coverage analysis; support scripts
WalkPasskey sign-in by default for enrolled users; fresh WebAuthn assertion required at payout change, withdrawal and new payee; SMS kept as a restricted fallback; recovery rebuilt so it doesn't reopen phishable pathsHooks at transaction endpoints; recovery redesign; metrics by factor
RunPassword-less accounts for most value-holders; device-bound credentials or recent verification required for top-risk actions; credential type and age used in Real-Time Transaction Risk Scoring; SPC / passkeys in card authentication where availableMature recovery with identity re-proofing; credential lifecycle management; policy engine

Customer friction and trade-offs

Logins get faster and fail less often. The FIDO Alliance's October 2025 Passkey Index reported a 93% sign-in success rate for passkeys (more than double other methods), 73% faster logins and up to 81% fewer login-related help-desk incidents. These are aggregate figures from participating providers, so measure your own. The friction moves to three places:

  • Enrollment. Prompt timing matters. Right after a successful high-value action converts better than a cold prompt.
  • Device changes and recovery. Recovery volume rises for device-bound credentials.
  • Mixed estates. Older devices, shared family devices and some enterprise-managed browsers fall back to other methods.

Measuring effectiveness

  • Phishing-attributed ATO per 1,000 accounts, split by "passkey only", "passkey plus legacy factors" and "legacy only".
  • Downgrade rate. The share of passkey-enrolled sessions where the customer still used a password or OTP.
  • Recovery-originated ATO. Expect this share of total ATO to rise as front-door ATO falls. That is the attack moving, not a failure of passkeys.
  • New-credential-then-payout. Count cases where a passkey was registered and a payout or payee change followed within a short window.
  • Adoption funnel. Prompt, then create, then first use, then share of logins. Industry context: the FIDO Alliance cites roughly 5 billion passkeys in use (State of Passkeys 2026). That figure is not reach within your own customer base.

Common failure modes

  • Passkeys are added on top of passwords. The password and SMS stay as live paths, so phishing still works through them.
  • Recovery is weak because it falls back to email OTP or support-agent knowledge questions.
  • Enrollment is silent: a new passkey is registered without notifying other channels or triggering any cooling-off.
  • Passkeys are used only at login. Assertions are not requested at money-moving actions, so stolen sessions still cash out.
  • The team over-trusts the credential and treats "signed in with passkey" as proof of intent, which blinds scam detection.
  • Enforcement is inconsistent. Legacy app versions or partner APIs that never got passkey support remain the soft path.

Regulatory and policy notes

  • NIST SP 800-63B-4 (final, August 2025).
    • Verifiers at AAL2 must offer at least one phishing-resistant option.
    • Syncable authenticators are expressly allowed at AAL2 but not at AAL3, because their keys are exportable.
    • Passwords, OTPs, look-up secrets and out-of-band methods are not phishing-resistant.
    • Federal agencies must require phishing-resistant authentication for their own staff.
  • FFIEC 2021 guidance. Expects MFA or controls of equivalent strength for higher-risk access within layered security. Phishing-resistant methods are the cleanest way to show that.
  • Card authentication. EMV 3DS 2.3.1 added data elements to support Secure Payment Confirmation, developed with FIDO and W3C. See 3-D Secure and Card Verification and Card Network Dispute Rules.
  • EU/UK SCA. Passkeys can satisfy two factors (possession plus inherence or knowledge). The dynamic-linking requirement for payments still applies, so the assertion must be bound to amount and payee.

Mechanisms addressed

Sources and further reading