Why Passkey-Only Wallets Will Fail (And What to Do Instead in 2026)
Passkeys are the best authentication primitive the web has ever produced. Using them as the actual key controlling onchain assets is a category error with at least seven documented failure modes.
Passkeys are the best authentication primitive the web has ever produced. Using them as the actual key controlling onchain assets is a category error with at least seven documented failure modes.
Key Takeaways
- Passkeys are excellent for authentication but dangerous as wallet primitives. The crypto industry conflated "login credential" with "asset custody," introducing cross-platform lock-in, curve mismatches, domain binding, and recovery failures that hybrid MPC architectures avoid entirely.
- Passkeys cannot sign without human biometric interaction. Server-side signing, AI agent operations, and scheduled transactions are structurally impossible with passkey-only architecture.
- The industry has converged on MPC and TEE hybrids, not passkey-as-signer. Para and other proivders all use passkeys as one authentication layer. Coinbase Smart Wallet is the notable exception, and it has the most documented failure modes.
What Is a Passkey-Only Wallet?
A passkey-only wallet uses a WebAuthn credential (passkey) as the cryptographic key that directly controls on-chain assets. No seed phrase. No MPC key shares. The passkey is the walllet.
This sounds elegant. In practice, it means the security and availability of your wallet depends entirely on the passkey ecosystem: your browser, your operating system, your cloud sync provider, and the specific domain that created the credential.
The alternative is using passkeys as one authentication layer in a multi-party architecture. The passkey proves you are you. A separate system (MPC, TEE, or both) manages the actual signing keys. This distinction between authentication and custody is the core of this article.
What Are the Six Failure Modes of Passkey-Only Wallets?
1. Cross-Platform Lock-In
iCloud Keychain passkeys do not sync to Android. Google Password Manager passkeys do not work on iOS. Chrome passkeys bind to specific user profiles. There is no cross-ecosystem transfer mechanism in production today.
The FIDO Alliance published the Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) specifications to address this. As of February 2026, CXP is a Working Draft and CXF is in Review Draft. Apple, Google, and Microsoft are contributing, but nothing is finalized or shipping.
Real failure: Splits.org documented a user who created a Coinbase Smart Wallet on macOS, then could not access it on their iPhone. The passkey was locked to one device ecosystem. In a passkey-only wallet, this means the user's funds are locked too.
2. Curve Mismatch and Gas Cost Penalty
Passkeys use the secp256r1 (P-256) curve. Ethereum and Bitcoin use secp256k1. Solana uses Ed25519. These curves are mathematically incompatible.
Verifying a P-256 signature on-chain without a precompile costs 330,000 to 400,000 gas. At 30 gwei on Ethereum L1, that is approximately $25 per signature verification. The RIP-7212 precompile reduces this to 3,450 gas, but deployment is fragmented.
| Chain | RIP-7212 Deployed | P-256 Verification Cost |
|---|---|---|
| Base | Yes | ~3,450 gas ($0.001) |
| Optimism | Yes | ~3,450 gas ($0.001) |
| Arbitrum | Yes | ~3,450 gas ($0.001) |
| Polygon | Yes | ~3,450 gas ($0.001) |
| zkSync | Yes | ~3,450 gas ($0.001) |
| Ethereum L1 | No | ~330,000-400,000 gas (~$25) |
| Most alt-L1s | No | ~330,000-400,000 gas (varies) |
| Solana | N/A (non-EVM) | Not natively supported |
An MPC wallet produces native secp256k1 or Ed25519 signatures. No precompile required. No smart contract wrapper. Standard verification costs on every chain.
3. Domain Binding Kills Portability
WebAuthn passkeys are bound to the Relying Party ID (rpID). A passkey created by keys.coinbase.com can only be used by keys.coinbase.com. A passkey created by wallet.example.com can only be used by wallet.example.com.
This is by design. Domain binding prevents phishing attacks on web authentication. But for wallet infrastructure, it means users cannot take their wallet with them. Unlike a seed phrase (universal via BIP-39) or an MPC key share (portable across providers), a passkey wallet locks users to the domain that created it.
If the provider shuts down, changes domains, or gets acquired, the passkey becomes useless. The wallet is stranded.
4. Recovery Delegates Custody to Apple and Google
Synced passkeys store the credential in iCloud Keychain (Apple) or Google Password Manager (Google). This means the security of the wallet ultimately depends on the user's Apple ID or Google account password.
If someone compromises your Apple ID, they get your passkeys. If Apple's sync service has an outage, you lose access. If you lose your Apple ID entirely, you lose your wallet.
This is not a theoretical concern. William Brown, the author of "Passkeys: A Shattered Dream," reports passkeys wiped from Apple Keychain on four separate occasions. macOS Catalina spontaneously deleted web passwords. macOS Sonoma silently enabled iCloud Keychain syncing without user consent, sending credentials to Apple's servers unexpectedly.
For wallets holding real money, delegating custody to a cloud sync service is a risk profile most developers would reject if they understood it clearly.
5. No Agent or Server-Side Signing
Passkeys require human biometric interaction by design. Every signing operation needs a fingerprint scan, face scan, or PIN entry. This is a feature for web login. It is a fatal limitation for wallet infrastructure.
Three categories of operations become impossible:
- AI agent wallets: Autonomous agents cannot present biometrics. The agentic wallet use case, which is growing rapidly in 2026, is structurally incompatible with passkey-only signing.
- Scheduled transactions: Recurring payments, automated yield harvesting, and time-based operations all require signing without the user present.
- Backend batch processing: Payroll disbursements, reward distributions, and multi-recipient airdrops need server-side signing capability.
6. The Recovery Paradox
Coinbase Smart Wallet markets itself as a "no seed phrase" wallet. Its recovery mechanism requires users to back up a "recovery phrase" that generates a new on-chain signer. This recovery phrase must be created while the user still has passkey access.
This is a seed phrase by another name. The wallet that promised to eliminate seed phrases reintroduced them as the recovery backstop. The paradox: every passkey-only wallet eventually needs a non-passkey recovery method, which undermines the entire value proposition.
How Bad Is the Adoption Data?
The headline number is impressive: over 1 billion passkeys "activated" globally. The details are less encouraging.
Roblox shared data at Authenticate 2025 showing that 21% of passkey users still instinctively reach for the password box, even when passkeys are available and working. For a passkey-only wallet with no fallback, one in five users would be stuck at the authentication screen.
Corbado, a passkey infrastructure company, documents 15+ implementation pitfalls, 40+ browser and OS combinations that need testing, and continuous specification changes. A specific example: macOS 13.6.5 breaks passkey authentication entirely.
For web login, these failures cause friction. For wallets holding money, they cause fund lockout.
What Architecture Actually Works?
The embedded wallet industry has converged on a clear pattern: passkeys as one authentication method in a multi-party signing architecture.
The pattern is consistent. Every provider with significant wallet volume uses MPC or TEE-based key management. Passkeys serve as one of several authentication methods, not the signing key.
How Does the Authentication-Custody Separation Work?
In Para's architecture, the passkey grants access to the user's MPC key share but is NOT the key itself. The flow works like this:
- User authenticates with a passkey (or email, social login, phone, or any other method)
- The MPC protocol runs between the 2-of-2 setup
- A native signature is produced (secp256k1 for Ethereum, Ed25519 for Solana) without the full private key ever existing in one place
Frequently Asked Questions
Are passkey wallets safe?
Passkeys provide strong authentication security through public-key cryptography tied to biometrics. The concern is not with passkeys themselves but with using them as the sole key controlling on-chain assets. Platform lock-in, cloud sync dependencies, the recovery paradox, and curve mismatch costs create risks that do not exist when passkeys serve as one authentication layer in an MPC architecture.
What is the difference between a passkey wallet and an MPC wallet?
A passkey wallet uses the WebAuthn credential as the signing key. The passkey IS the wallet. An MPC wallet distributes key generation across multiple parties (typically user and server). Neither party holds the full key. Passkeys can be used as the authentication method to access an MPC key share, combining passkey UX with MPC security.
Can I move my passkey wallet to another provider?
No. WebAuthn passkeys are bound to the Relying Party ID (the domain that created them). A passkey created by one provider cannot be used by another. The FIDO Alliance's Credential Exchange Protocol (CXP) may eventually enable cross-ecosystem transfer, but it is not finalized or shipping as of February 2026. MPC-based wallets like Para are cross-app portable because the key shares are not domain-bound.
Can passkey wallets support AI agent signing?
No. Passkeys require human biometric interaction for every signature. AI agents, automated bots, scheduled transactions, and server-side batch operations cannot present biometrics. This is a fundamental design constraint of WebAuthn. MPC architectures with server-side signing capability (like Para's server SDK) can authorize agent operations by co-signing with the server key share when policy conditions are met.