A wallet app says "sign in with a passkey" and your funds appear after a single fingerprint touch. No password, no seed phrase to write down, nothing to lose. It feels like the upgrade self-custody has been waiting for. The hard question hides one layer down: if that one touch is all it takes, what exactly is protecting the money when the phone is gone, the account is hijacked, or the cloud that syncs the passkey decides to lock you out?
Passkeys are one of the best authentication tools to reach mainstream computing in years. They are also widely misunderstood in crypto, where the difference between a passkey as a factor and a passkey as the sole key is the difference between a hardened wallet and a single point of failure.
What a passkey actually is
A passkey is a credential built on FIDO2/WebAuthn, the modern standard for passwordless login. FIDO2 is the umbrella; WebAuthn is the browser/web API and CTAP is the protocol that talks to external authenticators. In practice, a passkey is a public/private keypair created on your device.
The private key is generated inside, and never leaves, a secure element: the Secure Enclave or TPM in your phone, or a dedicated hardware security key. The service you log into (the "relying party") only ever stores your public key. When you authenticate, the secure element signs a challenge; the private key itself stays put.
Two properties make this powerful. First, the private key is non-exportable hardware-bound material, not a password sitting in a database. Second, each passkey is bound to a relying-party ID, meaning a specific domain (origin). A passkey created for example.com will simply not be offered on examp1e.com. That origin binding is what makes passkeys phishing-resistant by design.
Why passkeys are a genuine security win
Most people who lose crypto do not lose it to exotic cryptography breaks. They lose it to the boring attacks that scale: phishing pages, reused passwords, credential-stuffing from old breaches, and server-side password leaks. These are the bulk of the crypto attack surface, and passkeys defeat all of them at once.
There is no shared secret to phish, because the private key never travels. There is no password to reuse, leak, or stuff. A relying party can also require user verification, so a stolen, already-unlocked device still needs your biometric or PIN before the passkey will sign. Compared to a typed password or a seed phrase a user might paste into a fake "wallet validation" form, that is a large, real improvement.
This is why the framing matters so much. The problem is never the passkey doing its job. The problem is asking a single passkey to be the wallet.
The crypto-specific wrinkle: the wrong curve
Here is the detail that trips up newcomers. WebAuthn commonly uses ES256, which is ECDSA over the NIST P-256 curve (also called secp256r1 or prime256v1). But Bitcoin and Ethereum's execution layer verify signatures over secp256k1, a different curve entirely.
That mismatch means a passkey usually cannot be a native on-chain signer. Historically, verifying a P-256 signature inside an EVM contract was possible but extremely expensive in gas. So a raw passkey could not cheaply control a normal account.
Two developments change this. One is RIP-7212, a specification for a precompiled contract that verifies secp256r1 (P-256) signatures cheaply on EVM chains and L2s that adopt it. The other is ERC-4337 account abstraction, where the account is itself a smart contract that can verify P-256 signatures and enforce custom rules. Together they let a passkey authorize on-chain actions without being the raw spending key.
How passkeys really show up in crypto
Because of the curve problem, passkeys in crypto almost always appear through smart accounts or MPC systems rather than as a direct private key.
In a smart-account design, the passkey authorizes an action and a contract enforces policy: spending limits, allowlists, time delays, or a requirement that more than one signer approve. In an MPC design, the passkey gates access to one share of a key that is split across parties. Either way, the passkey is a gatekeeper, not the vault door itself.
Mental model: a passkey is a great way to prove "this is me, right now, on a real site." It is a poor choice as the only thing that proves "this money is mine forever."
That distinction is the whole argument of this article, and it is the through-line of the Beyond the Seed Phrase series: every recovery model trades one failure mode for another, and you have to know which trade you are making.
The trap: passkey as the only key
The dangerous pattern is the "sign in with a passkey" wallet where the passkey, or the cloud that syncs it, is effectively the only thing between an attacker and the funds. When that happens, your threat model quietly collapses into two things: the security of your cloud account, and the provider's recovery process. You may believe you hold the key. In reality, your iCloud or Google account holds it.
To see why that is risky, you have to separate the two flavors of passkey.
Synced passkeys (iCloud Keychain, Google Password Manager, 1Password) replicate across your devices through a provider cloud. This is convenient and survives a lost phone. But the sync provider becomes both a dependency and a target:
- Account takeover of the cloud, often via a SIM-swap-assisted password reset or support-desk social engineering, can pull the passkey along with everything else.
- The provider can suspend or lock the account, taking your only signer with it.
- Cross-ecosystem portability between providers is still immature, so you can end up locked into one vendor.
Device-bound passkeys (hardware security keys, some Secure Enclave configurations) never leave one device. They sidestep the cloud entirely, which is excellent for resisting remote attacks. But they introduce the opposite danger: lose the device and the key is gone, unless you registered a backup. A single hardware key with no second registration is the classic "one and done" failure, the same trap as owning exactly one hardware wallet with no recovery plan.
Recovery is the real key
This is the crux. A passkey has no seed phrase you can stamp on a steel plate and lock in a drawer. Unlike a seed phrase, there is no portable secret to back up by hand. Recovery is whatever the wallet or app defines.
That recovery path might be: re-deriving the credential from the sync cloud, authenticating with a second registered passkey, walking through a smart-account social-recovery flow, or re-sharing an MPC key. Each is legitimate. But each is your real key, regardless of what the login screen looks like.
The test to apply to any passkey wallet is blunt: finish this sentence honestly. "If I lose my phone, I get my funds back by ______." If the only answer is "just my iCloud," then iCloud is your wallet, and your security is exactly as strong as that one account.
Designing it right: passkey as a factor
Used as one factor among several, passkeys are excellent. Good patterns share a theme: never let a single passkey or a single cloud be the whole story.
- Register multiple passkeys as separate signers for the same account, for example one on your phone and one device-bound hardware key, so losing either one does not lock you out.
- Make the passkey one signer in a quorum such as a 2-of-3 smart account or an MPC threshold, so no single credential can move funds alone.
- Pair passkey authorization with a policy contract that enforces spending limits or time delays, turning a stolen factor into a contained incident rather than a total loss.
- Keep an independent recovery path that does not depend solely on the sync cloud, whether that is a second hardware signer, designated recovery contacts, or a backup credential held offline.
The mainstream example of this done well is Coinbase Smart Wallet, which uses a passkey as the signer over an ERC-4337 smart account, with a contract enforcing the rules. Its recovery model is the subject of Part 4 on social recovery. The lesson it embodies is exactly the one here: the passkey is the convenient front door, while the contract and the recovery design are what actually keep the funds safe.
Key takeaways
- A passkey is a phishing-resistant FIDO2/WebAuthn credential whose private key never leaves a secure element, which makes it an excellent authentication factor.
- It defeats the attacks that drain most users: phishing, password reuse, credential stuffing, and server-side leaks.
- Passkeys use the P-256 (secp256r1) curve, not Bitcoin/Ethereum's secp256k1, so in crypto they work through smart accounts (ERC-4337, RIP-7212) or MPC rather than as a raw spending key.
- The danger is a single passkey, or the single cloud that syncs it, being the only thing guarding your funds; then your real security is just your cloud account plus the provider's recovery process.
- Treat the passkey as one factor: register multiple signers, put it inside a quorum or policy contract, and keep a recovery path that does not depend on the sync cloud alone.
