Passkeys (WebAuthn/FIDO2)

What Are Passkeys?

A passkey is a passwordless authentication credential based on the FIDO2 standard. Instead of typing a password, the user authenticates with a biometric (fingerprint, face scan) or device PIN. Under the hood, the device performs a cryptographic challenge-response using a private key that never leaves the hardware. The website only stores the corresponding public key, so even a full server breach exposes nothing an attacker can reuse.

The FIDO Alliance formally introduced the "passkey" branding in 2022, unifying two existing standards: the W3C Web Authentication API (WebAuthn), which defines the browser-side JavaScript interface, and the FIDO Alliance's Client to Authenticator Protocol (CTAP2), which governs communication between the browser and external authenticators like hardware security keys. Together these form the FIDO2 specification.

As of 2026, over 15 billion online accounts support passkeys, and 48% of the top 100 websites have implemented them. Apple, Google, and Microsoft all ship native passkey support across their platforms, making passkeys the fastest-adopted authentication standard in history.

How Passkeys Work

Passkeys use asymmetric (public key) cryptography for both registration and authentication. The primary algorithm is ES256: ECDSA signatures over the P-256 (secp256r1) elliptic curve with SHA-256 hashing, providing approximately 128 bits of security.

Registration

When a user creates a passkey for a website:

1. The server (called the "relying party") generates a random challenge and sends it along with site information and supported algorithms
2. The browser calls the WebAuthn API, which prompts the user for biometric or PIN verification
3. The authenticator generates a unique key pair bound to the site's origin
4. The private key is stored in the device's secure element or trusted execution environment
5. The public key, credential ID, and signed attestation are returned to the server

// WebAuthn registration (simplified)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,
    rp: { name: "Example", id: "example.com" },
    user: { id: userId, name: "alice@example.com", displayName: "Alice" },
    pubKeyCredParams: [{ alg: -7, type: "public-key" }], // ES256
    authenticatorSelection: {
      residentKey: "required",
      userVerification: "required"
    }
  }
});
// credential.response contains the public key and attestation

Authentication

When the user signs in:

1. The server generates a fresh random challenge
2. The browser calls the WebAuthn API, which locates matching passkeys and prompts for biometric or PIN verification
3. The authenticator signs an assertion containing the challenge, the requesting origin, and a signature counter
4. The server verifies the signature against the stored public key, confirms the challenge matches, and checks the origin

// WebAuthn authentication (simplified)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: serverChallenge,
    rpId: "example.com",
    userVerification: "required"
  },
  mediation: "conditional" // enables autofill UI
});
// assertion.response.signature is verified server-side

The entire flow takes about 8.5 seconds on average, compared to 31.2 seconds for traditional multi-factor authentication. Login success rates reach 93% with passkeys versus 63% for password-based methods.

Synced vs. Device-Bound Passkeys

Passkeys come in two forms, each with different security and usability trade-offs:

Both types are classified as phishing-resistant by the FIDO Alliance. Synced passkeys use end-to-end encryption in transit and at rest, meaning even the cloud provider cannot read the private key material.

Passkeys in Crypto Wallets

Passkeys present a unique challenge for blockchain applications. WebAuthn uses the secp256r1 (P-256) curve, while Bitcoin and Ethereum use secp256k1. These curves are mathematically incompatible: a passkey cannot directly produce a valid Bitcoin or Ethereum transaction signature.

The ecosystem has developed several approaches to bridge this gap:

Account Abstraction (ERC-4337)

Smart contract wallets can implement custom signature verification. Instead of requiring secp256k1 signatures, the wallet's validation logic verifies P-256 signatures from passkeys directly on-chain. RIP-7212, the first accepted Rollup Improvement Proposal, adds a native secp256r1 precompile that reduces verification cost to 3,450 gas (roughly 100x cheaper than software verification). This precompile is deployed on major Layer 2 networks.

PRF Extension for Key Derivation

The WebAuthn Level 3 PRF (Pseudo-Random Function) extension allows deterministic derivation of cryptographic keys from a passkey authentication. The authenticator evaluates a PRF using its internal secret and a relying-party-provided salt to produce a 32-byte output. This output can seed wallet key derivation, potentially eliminating the need for seed phrase storage entirely.

Wallet Implementations

Several production wallet systems use passkeys today:

• Coinbase Smart Wallet: uses a passkey as the primary signer for an ERC-4337 smart account on Base, with P-256 verification via the RIP-7212 precompile
• Safe Passkey Module: an official signer module that allows any Safe smart account to add a passkey as a co-owner or sole owner
• Turnkey: generates keys in hardware-isolated enclaves and uses passkeys to gate access, supporting multi-chain deployments
• Breez SDK (Bitcoin/Lightning): uses the PRF extension to deterministically derive wallet keys from biometric authentication, removing seed phrase storage from the user experience

These approaches represent a shift in how self-custody can work: users authenticate with biometrics while maintaining non-custodial key control. For a deeper comparison of wallet architectures, see the self-custodial vs. custodial wallets research article and the embedded wallets deep dive.

Use Cases

Consumer Authentication

The most widespread use case: replacing passwords for website and app login. Major exchanges including Coinbase, Gemini, Binance, and Kraken support passkeys for account authentication. Gemini began requiring all users to create passkeys in May 2025, resulting in a 269% increase in passkey authentications and a measurable reduction in account takeover incidents.

Wallet Access and Transaction Signing

Passkeys can serve as the primary authentication factor for hot wallets and embedded wallet experiences. Through account abstraction, the same biometric that unlocks the wallet can authorize on-chain transactions. This eliminates the traditional trade-off between security and convenience that has defined crypto UX: users no longer need to choose between a custodial wallet with easy login and a signing device with complex key management.

Replacing Seed Phrases

The PRF extension opens the possibility of passkey-derived wallet keys. Instead of writing down a 12 or 24-word recovery phrase, the user's biometric becomes the root of key derivation. When combined with synced passkeys, this provides cross-device wallet access without any written backup. Breez SDK has implemented this pattern for Bitcoin and Lightning wallets.

Multi-Factor Wallet Security

Passkeys can complement existing wallet security as one factor in a multi-signature or threshold scheme. A multisig wallet might require a passkey plus a hardware signing device for high-value transactions, combining biometric convenience with cold storage security.

Risks and Considerations

Curve Incompatibility

WebAuthn's secp256r1 is not natively supported by most blockchains. On-chain verification requires either a precompile (RIP-7212, available only on select L2s) or expensive software verification. Bitcoin's Script language has no built-in support for P-256 at all, limiting passkey integration to off-chain or hybrid architectures.

Relying Party Binding

A passkey is cryptographically bound to a specific domain (the relying party ID). A passkey created by one wallet provider cannot be used by another. If a wallet service shuts down, users cannot port their passkey-based credentials to a competitor. This domain binding is a security feature for authentication but creates vendor lock-in risk for wallet applications.

Cloud Account Dependency

Synced passkeys inherit the security of the underlying cloud account. If an attacker compromises a user's Apple ID or Google Account, they gain access to all synced passkeys. For crypto wallets, where passkeys may control significant value, this shifts the threat model from phishing resistance to cloud account security. SIM swap attacks targeting account recovery remain a concern.

Recovery Complexity

Device-bound passkeys have no cloud backup. If the device is lost or damaged, the passkey is gone. Wallet applications using device-bound passkeys must implement independent recovery mechanisms. Even synced passkeys depend on cloud account access: losing access to the cloud account means losing all synced credentials.

Portability Limitations

As of 2026, there is no finalized standard for transferring passkeys between providers. The FIDO Alliance is developing the Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) to address this, but the specifications remain in active development. Users who switch ecosystems (Apple to Android, for example) may face friction moving their credentials.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.