Passkeys and Account Abstraction: Where the Key Lives Now

The credential the site never sees

A passkey is a FIDO credential, defined by the FIDO Alliance as an authentication credential “based on FIDO standards, that can be stored on your phone or computer, or in a hardware security key,” used after the same gesture that unlocks the device: biometrics, a PIN or a pattern. In the underlying Web Authentication specification, a credential is created by an authenticator, bound to a relying party, and scoped so that only origins belonging to that party can use it.

Two properties matter for a wallet. First, the private key is expected never to leave the authenticator. The specification’s security considerations are explicit: it “defines no protocol for backing up credential private keys, or for sharing them between authenticators,” and “in general, it is expected that a credential private key never leaves the authenticator that created it.” Second, the authenticator is responsible for ensuring “no operation is performed without user consent,” which is why signing requires a gesture: a biometric check, a PIN or a touch.

That is the appeal. There is no phrase to photograph, no twelve words to type into a phishing page, no secret the wallet application can read. What the application receives is a signature over a challenge and the public key registered at creation.

From an assertion to a transaction

The passkey does not sign an Ethereum transaction. It signs a WebAuthn assertion: authenticator data and client data, signed with an algorithm the credential was created with. WebAuthn’s ES256 algorithm is defined over the P-256 curve. An Ethereum externally owned account is validated by the protocol’s own signature rule, not by WebAuthn, so the two are not interchangeable.

A contract account resolves that mismatch: it can verify any signature its code accepts. EIP-1271 defines the standard shape for this: a contract exposes a function that reports whether a signature is valid on its behalf, so the rest of the ecosystem can ask the account rather than recover a key. Safe’s implementation shows what the pieces look like. Its WebAuthn signer contracts “conform to both ERC-1271 and WebAuthn standards, enabling the verification of signatures for WebAuthn credentials that use the secp256r1 curve,” and verify those signatures through a verifier contract or a precompile where one is available.

So a passkey wallet is at least two things: the credential on your device, and the verifier on chain that recognizes its signatures. The verifier is code at an address, and what it accepts is as much a part of the wallet as the credential — none of it visible in the fingerprint prompt.

What ERC-4337 separates

ERC-4337 introduces a transaction-like object called a UserOperation. Users send these to a separate mempool; bundlers package several into one transaction and call a singleton EntryPoint contract; the EntryPoint calls validateUserOp on each account, and the account decides whether the operation is valid before execution. The account pays the fee, or has a paymaster pay it.

Validation is code inside the account, not a fixed protocol rule. EIP-4337 states it directly: abstracting validation “allows the contract to use different signature schemes, multisig configuration, custom recovery, and more.” A passkey signer is one instance of that. So is a multisig, or a recovery arrangement written as a module.

That is what separating signer from account means. The account has an address and holds the funds; the signer is an input the account checks. If its logic allows it, the signer can be replaced — a new phone, a different curve, an added co-signer — without moving the balance. That is a real improvement over an externally owned account, where the address is derived from the key, so a new key means a new address.

The qualifier is if the account’s logic allows it. A contract account that hard-codes one signer and has no replacement path is an EOA with extra gas. The flexibility lives in the code and in who may change it.

What is still a single point of failure

Account abstraction removes the seed phrase from the center. It does not remove single points of failure; it relocates them. Four are worth naming.

The sync account behind a multi-device passkey. WebAuthn calls a credential that may be copied to other devices a multi-device credential, listing mechanisms from “peer-to-peer sync, cloud sync, local network sync, and manual import/export.” When the sync runs through a platform account, recovering that account recovers the credential. The key is still not extractable, but the path to using it now runs through a provider’s account recovery.

A single registered credential. The same security section warns that losing an authenticator generally means losing its credentials, “which could lock the user out of an account if the user has only one credential registered with the Relying Party.” One passkey, one device, no second credential is a recovery plan with no margin.

The verifier and the account’s upgrade authority. A passkey is only as authoritative as the contract that checks it. Whoever can change the signer module, upgrade the account or add a module can change who signs — and the fingerprint prompt never shows who that is.

The recovery path itself. If a guardian set or a provider can rotate the signer under defined conditions, those parties can also rotate it under conditions you did not intend. Recovery is authority, and authority is custody.

The direction is what matters: syncing trades device-loss risk for provider-account risk, and neither column removes the need for a second credential.

Recovery is a choice about who can help

A passkey cannot be written on paper. That shapes every recovery design, because the usual fallback for a lost key — restore the backup — does not exist in the form most people expect. The WebAuthn specification’s answer is not a backup protocol but multiple credentials: register more than one, so losing one authenticator does not lose the account.

Four arrangements follow.

Platform sync. One credential, copied across devices by the operating system or password manager. Recovery means recovering the platform account: the smoothest option, and the one that most changes the trust model, because the platform becomes the party that restores access.

Two credentials you control. Register a second passkey on another device or a security key. If the account treats each credential as a signer, it has two, and the question becomes a threshold one: does either credential alone move funds, or must both agree? The first is survivable but means either device can spend; the second is stricter but adds coordination.

Mixed signers. A passkey plus a hardware wallet or an ordinary key, held as two signers on one account. This avoids depending on one vendor or one signature scheme, and resembles a conventional multisig with one modern key.

Delegated recovery. A module or guardian set that can replace the signer after a delay or a quorum. This is the only option that survives losing every credential you hold, and it is also the option that creates a new set of parties who can take the account. Safe’s documentation notes that recovery modules exist for exactly this case, and that modules in general are security-critical because they can execute transactions.

The trade is consistent: more recovery means more parties to trust, delay or coordinate. A passkey wallet does not escape it; it moves the decision from “where do I write the phrase” to “who can help me get back in.”

Reading a passkey wallet’s claims

The useful questions are about authority, not fingerprints.

• Can you register a second credential, and is it a second signer? A backup passkey that the account treats as an equal signer changes the security model; a second credential that cannot sign does not help.
• Is the passkey single-device or synced? Backup eligibility is fixed at creation, and wallet interfaces rarely surface it. Check the platform’s passkey list, which usually shows where it is stored.
• Who can change the signer? Look for an upgrade authority, an admin key, a module list, or a provider console. That answer, not the login screen, determines custody.
• Can the account address survive a signer change? If yes, recovery is a rotation. If no, recovery is a migration, with the old address left behind.
• What does recovery require, and from whom? A recovery flow a provider can trigger with an email is a different trust model from one that needs two of your devices.
• Does the wallet’s “non-custodial” claim survive all of the above? The test is the same one that separates custodial from non-custodial: who can move the funds without asking you.

Two limits remain. A passkey does not make the transaction legible; it authenticates the person signing, while what appears on screen depends on the wallet’s decoding, the subject of clear signing versus blind signing. And losing a credential is not like losing a phrase: there is no paper copy to find, so the plan has to exist before the device goes missing — the discipline in seed phrase handling, applied to a secret that cannot be written down.