Security Considerations for Passkey-Based Web3 Wallets

Since 2022, Apple, Google, and Microsoft have made WebAuthn-based authentication, branded as Passkeys, a primary way to sign in. Web3 is now applying the same model to wallets, in place of seed-phrase key management. These Passkey Wallets let users authorize on-chain transactions with a device authenticator instead of guarding a mnemonic or a hardware wallet.

The transition from a seed-phrase model to a Passkey model changes the security architecture of self-custody. A seed-phrase wallet concentrates all asset-control authority into a single derivable secret that the user alone must safeguard. A Passkey Wallet distributes that authority across many components: the device authenticator, the wallet application, the WebAuthn challenge protocol, account-abstraction infrastructure such as bundlers, on-chain validator contracts, and the cloud-sync and recovery surfaces behind them. Each is its own security boundary, and each has to be audited as one.

This article analyzes that security model across the full asset-control lifecycle. It traces a single transaction through Clave's open-source implementation, surveys past vulnerabilities in WebAuthn, FIDO2, and CTAP, maps them onto the lifecycle of a typical Passkey Wallet, and ends with implementation checks for teams building one.

Given that Passkey behavior is platform-specific, we use iOS as the concrete lens for analysis throughout.

A few terms from account abstraction recur throughout. For readers new to them:

• Account abstraction / ERC-4337: a design where the user's wallet is a smart-contract account rather than a plain key, so custom rules (for example, "a valid Passkey signature authorizes this action") can govern who may move assets.
• UserOperation: the account-abstraction equivalent of a transaction; the user's intended action before it is executed on-chain.
• Bundler: an off-chain service that collects UserOperations and submits them to the chain.
• EntryPoint: the standard contract that receives bundled operations and asks each account to validate and execute them.
• Validator: the part of a smart account that checks the signature on an operation; for a Passkey Wallet, the component that verifies the P-256 signature.
• Paymaster: an optional contract that pays gas fees on the user's behalf.
• P-256 / RIP-7212: P-256 (secp256r1) is the elliptic curve Passkeys sign with; RIP-7212 is an on-chain precompile that verifies such signatures cheaply.

Background: The Passkey Authentication Model

Authentication Flow

A Passkey is a WebAuthn / FIDO2 credential made up of a public key and a private key. The public key is registered with a relying party, which will later check the signature. In Web2 that is typically a server. In Web3 it is the user's on-chain account itself: the public key is stored in the smart contract that guards the user's assets, in the slot that records who is allowed to authorize transactions (in ERC-4337 or native account-abstraction terms, the account's owner or validator). The private key is retained by a device authenticator and is invoked only after the user completes a local verification gesture.

Across platforms, local verification is exposed to users under different labels (Face ID or Touch ID on iOS, or a hardware security key on desktop), but the underlying protocol stack is uniform. WebAuthn defines the credential and challenge-response model. FIDO2 defines the client-authenticator interaction. CTAP defines the transport between the client and the authenticator.

Storage Models

Where the private key physically lives depends on the storage model. Two are common.

Device-bound credentials keep the private key inside a hardware authenticator with no documented plaintext export path. Examples include external security keys such as YubiKey, and platform credentials created in a non-syncable mode, such as TPM-backed credentials created through the WebAuthn residentKey / authenticatorAttachment options.

Apple's Secure Enclave documentation describes the non-extractable property for keys created via SecKey with kSecAttrTokenIDSecureEnclave, which is the model used by hardware security keys. Non-extractability is a design property, not an absolute guarantee, as the side-channel research surveyed in the historical vulnerabilities section demonstrates.

Synced Passkeys are the default storage model on iOS. Credentials are stored in iCloud Keychain, and the underlying key material is exported in end-to-end-encrypted form so that the credential can synchronize across the user's devices. The security boundary extends from the local device to the cloud account behind the sync, so if that account is taken over, the credential is too.

Tracing a Transaction Through a Passkey Wallet

In Web2, the signed assertion from the authenticator is checked by a server. In a Web3 Passkey Wallet, the same assertion goes to a smart contract, which treats it as approval for an on-chain action: a transfer, an approval, a module installation, or a change of ownership. Between the user's intent and the on-chain execution, any step that lets the signature be misread, swapped, replayed, or downgraded leads straight to assets moving without permission.

To examine these boundaries concretely, we traced a single token transfer through Clave's open-source implementation.

To the user, the flow is simple: tap "Send", confirm with a biometric, and wait for the success screen. Underneath, that one action travels through a full Passkey Wallet stack: a mobile application, a Passkey-backed signer, an account-abstraction transaction path, a bundler, an on-chain Passkey validator contract, and a chain-native P-256 precompile. The trace below breaks that one action into five steps.

Step 1: Build the Operation

Before any signature is requested, the wallet application assembles the transfer into a candidate operation. The operation specifies the source account, the recipient, the amount, the target chain, and the fees, with values like the nonce and gas filled in by querying an RPC endpoint (the wallet's gateway to the chain) and the bundler. The security concern at this boundary is whether the payload the application submits matches what the user sees on the device.

Step 2: Hash the Operation into a Fingerprint

The wallet application takes the whole operation, with all of its fields, and runs it through a hash function to get one short, fixed-length value called the userOpHash. This hash works as a fingerprint of that exact operation: change any single field, whether the recipient, the amount, the source account, the chain identifier (chainId), the nonce, or the gas fields, and the resulting hash comes out completely different.

Step 3: Sign the Fingerprint with the Passkey

The wallet application passes the userOpHash into the system Passkey flow as the WebAuthn challenge. After the user completes local verification, the authenticator returns a signed assertion.

What the authenticator actually signs, though, is not the challenge on its own, and that matters for the on-chain check later. The app does not build the JSON around the challenge; it only supplies the challenge and the request options. That JSON is built by the WebAuthn client, which is the browser on the web or the OS on mobile, such as ASAuthorizationPlatformPublicKeyCredentialProvider on iOS. The client assembles clientDataJSON from the challenge, the origin, and the operation type, hashes it, and passes the hash to the authenticator, which adds its own authenticatorData and signs the two together:

// computed by the client

clientDataHash = SHA-256(clientDataJSON)
// produced by the authenticator signature = sign( authenticatorData || clientDataHash )

So the signature covers two things at once: authenticatorData, built by the authenticator, which carries flags such as UP (user presence) and UV (user verification) and the rpIdHash (a hash of the relying party's identifier); and the whole clientDataJSON, built by the WebAuthn client, which carries the challenge. To check the signature on-chain, the validator has to rebuild both parts and confirm that the challenge inside clientDataJSON matches the transaction fingerprint. That is why the assertion is sent on-chain as several separate fields, not as a bare (r, s) pair.

Because clientDataJSON is built by the client and not the app, who counts as "the client" matters for threat modeling, and it changes with the surface:

• In a browser-based dApp, the client is the browser process and any code that can inject script into it.
• In a mobile native wallet calling the OS WebAuthn API, the client is the platform itself.
• In an in-app or hybrid WebView, the client is whatever JavaScript runtime loaded the page.

Step 4: Encode the Signed Proof for the Chain

The signed assertion, which is the wallet's proof of authorization, cannot stay on the device; it has to travel on-chain. So the wallet app packs it into the transaction it submits, giving the on-chain validator what it needs to re-check three things: that the assertion came from the registered Passkey, that it matches the transaction being run, and that the user-confirmation flags meet what the contract requires.

Many ERC-4337 Passkey wallets, including Clave and Coinbase's open-source webauthn-sol library, have converged on a similar encoding of these fields, though the names and the exact slicing of clientDataJSON vary (the challengeIndex and typeIndex offsets, for instance, come from webauthn-sol and are not part of the WebAuthn standard). Whatever the layout, its purpose is the same: to let the on-chain contract confirm that the fingerprint the authenticator signed is the fingerprint of the transaction it is now processing.

Step 5: Validate the Proof On-Chain and Execute

The transaction is submitted through account-abstraction infrastructure to the chain. The user's smart account then routes the call to its Passkey validator.

The smart account uses part of the operation's nonce to route the call to the correct validator, so each operation is checked by the validator that owns it. (Concretely, Clave-style accounts encode the validator's address inside the operation's nonce, so the account can tell which validator to invoke.) The transaction proceeds to execution only after the validator confirms that the device assertion matches the current transaction.

The on-chain validator is responsible for the following checks:

• Decoding the assertion returned by the authenticator
• Verifying that the user-presence flag (UP) is set in authenticatorData, and, where the wallet's policy requires it, the user-verification flag (UV)
• Verifying that the assertion is for a transaction authorization rather than a login or registration ceremony, by checking that the type field in clientDataJSON is webauthn.get
• Extracting the fingerprint embedded in the signed data
• Confirming that the extracted fingerprint matches the fingerprint of the transaction currently being executed
• Verifying that the P-256 signature is mathematically valid Only after all of these checks pass does the smart account proceed to execution and fee settlement.

Historical Vulnerabilities Relevant to Passkey Wallets

With the transaction lifecycle laid out, the natural question is where past Passkey failures fall on it. Looking back at the public record, most of them never touched the cryptographic core; they hit the boundaries around it.

1. Signature-Verification Implementation Bugs

CVE-2022-21449, "Psychic Signatures", disclosed in 2022, is a representative example. Java's ECDSA verification path failed to enforce that the signature components r and s lie in [1, n-1], with the consequence that an all-zero signature (r=0, s=0) was accepted as valid. The vulnerability extended beyond WebAuthn to any system relying on the affected Java ECDSA implementation, including JWT, SAML, and TLS.

Applied to Passkey Wallets, the lesson is that a sound primitive does not mean a sound verification path. The on-chain P-256 verifier, the RIP-7212 call, low-S enforcement, public-key validity checks, and failure handling are all part of the asset-security surface. The same class of bug that costs a Web2 site an unauthorized login costs a wallet an unauthorized transfer.

2. Hardware Side-Channel Attacks

CVE-2024-45678, EUCLEAK, disclosed in 2024, demonstrated that YubiKey 5-series authenticators and other devices using the Infineon cryptographic library leak information through electromagnetic side-channels during ECDSA operations. Yubico's response is documented in YSA-2024-03. The earlier Titan Key side-channel research, CVE-2021-3011, established that hardware security keys can be analyzed and attacked under sufficiently capable adversarial conditions.

Applied to Passkey Wallets, the point is not the side-channel itself. These attacks need physical access and specialized equipment, so they are not the front-line threat to a consumer Web3 product. What they show is that a hardware authenticator is a strong boundary, not an infallible one. A wallet that puts all asset-control authority in a single Passkey, with no recovery, key rotation, or revocation, has nowhere to turn when that boundary fails, and on-chain assets have no support desk to freeze them.

3. Browser and WebAuthn API Compromise

SquareX Labs' Passkeys Pwned research showed how malicious browser extensions or injected scripts can hijack the WebAuthn API, intercepting navigator.credentials.create() and navigator.credentials.get() to manipulate registration and authentication flows.

The 2025 Springer paper, Defeating FIDO2/CTAP2/WebAuthn using browser in the middle and reflected cross site scripting, showed that once an attacker can run scripts under the target origin, WebAuthn's rpId / origin binding no longer protects the flow, because the malicious call comes from the correct domain.

CVE-2024-9956, reported by Tobia Righi, showed that on mobile a remote web page could auto-launch the CTAP 2.2 Hybrid Transport flow through a FIDO:/ URI, skipping the QR-scan step where the user normally consents to pairing; the victim's phone then acts as the legitimate authenticator while it authorizes the attacker's session.

Applied to Passkey Wallets, the frontend is part of the authorization path, not just a display layer. Wallet SDKs, dApp iframes, white-labeled domains, in-app WebViews, deep-link handlers, and injected analytics can all shape the context a WebAuthn call is built in. A native mobile wallet is not exempt: any dApp browser, recovery WebView, or system-browser redirect carries the same risk. An audit has to cover not just the on-chain verifier but the conditions under which the signature was produced.

4. Challenge Binding Failures

A WebAuthn assertion is just a signature over a challenge. If that challenge is poorly designed, held only client-side or not consumed exactly once, the assertion behaves like a transferable, replayable credential instead of a single-use authorization.

Two verifier-side cases show this. In duo-labs/webauthn.io Issue #28, a challenge stored only client-side, or not consumed exactly once on the server, could be replayed within its validity window. CVE-2025-26788, a Passkey bypass in StrongKey FIDO Server, also tracked by NVD, is the same kind of flow-level confusion at the verifier.

Applied to Passkey Wallets, challenge binding matters even more. A random nonce only proves that some Passkey signed something; a challenge equal to the userOpHash proves the user authorized one specific operation. In ERC-4337 the userOpHash commits to the whole operation: sender, nonce, callData, gas fields, paymaster data, the factory call that first deploys the account, the EntryPoint, and chainId (v0.7 repacks these but binds the same surface). That coverage is what makes a tampered paymaster blob, or even the account's first deployment where the validator and owner are first set, detectable downstream.

The WebAuthn type field (webauthn.get) lives inside clientDataJSON and must be checked too, even though it is not part of the userOpHash. In short, challenge-binding design is the line between a login signature and a transaction signature.

5. Missing User-Presence and User-Verification Checks

The authenticatorData blob carries flags including UP (user presence) and UV (user verification). UP indicates that the user performed a presence gesture; UV indicates that local user verification (biometric, PIN, or equivalent) was completed.

After the launch of Coinbase Smart Wallet, Corbado analyzed its Passkey design and the trade-offs around userVerification configuration and the UV flag: Corbado: Smart Wallets & Passkeys.

Applied to Passkey Wallets, UV failures usually come from three layers drifting apart:

1. The relying party's request. The wallet's WebAuthn call passes userVerification: required | preferred | discouraged. Only required instructs the OS to refuse the assertion if UV is not performed.
2. The authenticator's behavior. The authenticator decides whether to perform UV and sets the UV bit in authenticatorData accordingly. With preferred, an authenticator that lacks UV capability can still return a UP-only assertion.
3. The on-chain validator's enforcement. The smart contract decides whether to require UV == 1. A contract that only checks UP accepts any assertion the OS produces, regardless of what the wallet requested or what the authenticator actually did.

In a Web2 login a UV downgrade reduces authentication strength; in a Web3 wallet it reduces the strength of an on-chain asset authorization. On-chain validation therefore has to weigh not just whether the P-256 signature is valid, but the user-interaction state the assertion claims to represent.

6. Downgrade and Parallel-Path Attacks

Many production compromises do not target the Passkey itself; they target the systems around it.

The Microsoft Entra ID downgrade research is a clear example of an explicit downgrade attack. An attacker spoofs the User-Agent string to cause the server to conclude that FIDO is unsupported and to fall back to OTP, push notification, or SMS. The strong factor is never invoked. BleepingComputer's coverage describes the mechanism.

A related but distinct class is parallel-path AiTM (adversary-in-the-middle) phishing. The attacker does not downgrade FIDO; the attacker targets users who have not yet enrolled FIDO and are still authenticating with OTP or push. Tycoon 2FA is the canonical example: an AiTM phishing kit that harvests OTPs, push approvals, and session cookies at scale, documented by Proofpoint and Sekoia. The Passkey is structurally strong; the attacker simply does not encounter it.

Applied to Passkey Wallets, both patterns say the same thing. The cryptographic core (the P-256 signature and the challenge-response protocol) is strong. The client surface (BitM, XSS, AiTM) and the parallel paths (recovery, device migration, MFA fallback, support flows) are weaker. Attackers do not take on the core directly; they route around it to the cheapest path.

7. Recovery and Cloud Sync

Coinbase the exchange disclosed in 2021 that more than 6,000 customers were affected by SMS 2FA and recovery-path issues; see BleepingComputer.

Synced Passkeys redraw the security boundary in a different direction. Cross-device synchronization through Apple and third-party password managers is a substantial usability improvement, but the security boundary extends from a single device to a cloud account, the recovery flows protecting that account, and the multi-device migration mechanisms. Apple's documentation on iCloud Keychain security is published at Apple Support. A related class of attack sidesteps the credential entirely: SpyCloud's analysis of Passkey vulnerabilities shows how stolen session cookies let an attacker ride an already-authenticated session, making the strength of the Passkey irrelevant.

Applied to Passkey Wallets, syncing changes the threat model in two ways. First, clone detection breaks: iCloud Keychain keeps signCount at 0, because a monotonic counter cannot survive multi-device sync, so any wallet that relies on signCount to spot cloned credentials should drop that assumption. Second, the cloud account and its recovery flows become part of the attack surface; if that account falls, so does the credential.

Mapping Vulnerabilities to the Passkey Wallet Lifecycle

Placing the trace and the historical cases side by side makes one thing clear: a Passkey Wallet has no single security boundary. The authority to move assets runs as a chain through the whole product lifecycle.

In a seed-phrase wallet, almost every risk comes down to one question: was the seed phrase exposed? In a Passkey Wallet that authority is spread across the lifecycle, and each stage has its own boundary. Mapped onto those stages, the past attacks do not land randomly. They cluster in three places: the app and WebAuthn surface before signing, the validation logic after signing, and the sync and recovery paths.

Rows are lifecycle stages; columns are where the security boundary sits.The H numbers are the historical cases from the previous section, with the boundary where each one mainly lands:

The H numbers are the historical cases from the previous section, with the boundary where each one mainly lands:

Two things stand out. First, Custody is not equally strong in every setup. For a device-bound credential (a hardware key, or a non-syncable platform credential like TPM-backed one), it is one of the strongest boundaries: the key sits in a secure element and the relying party never sees it in plaintext. Even then it is not absolute, as the EUCLEAK and Titan side-channel work (H2, H3) showed with physical access.

For a synced Passkey it is weaker still: the real floor is whatever protects the cloud account, namely an Apple ID or Google password plus its second factor and recovery options. Here Custody and Recovery are effectively the same boundary, so presenting the device as the whole security story is misleading.

Either way, attackers rarely engage Custody head-on. They move around it, to Frontend, Validation, or Recovery, the boundaries teams tend to underweight.

Second, the risk changes shape as the wallet moves through its lifecycle. Custody and registration give way to binding, construction, and signing, then to execution, migration, and recovery, and at each stage the authority to move assets can be amplified, mis-bound, replayed, or bypassed in a different way. A full audit therefore follows the table end to end, from custody through recovery; the next section turns each stage into concrete checks.

Implementation Considerations

These questions turn the risk points from the trace and the historical cases into concrete checks for anyone building a Passkey Wallet.

Registration. Is the Passkey public key bound to the correct user, the correct domain, the correct application, and the correct smart account? Is the registration flow exposed to injection of an unintended credential?

Transaction construction. Does what the user sees match the on-chain callData? Are batched calls, delegate calls, and module executions clearly displayed and bound to the signature?

Signing. Does the challenge bind the full transaction semantics? Does it cover the account, the chain identifier, the nonce, the callData, and the EntryPoint, or an equivalent set in a native-AA stack?

Application access vs on-chain authorization. Application-layer authentication (JWTs, MFA, Privy sessions) governs access to the application, not the right to move assets. Moving on-chain assets must depend only on a valid Passkey signature bound to a specific UserOperation, never on a valid application session.

On-chain validation. Does the validator check the critical WebAuthn fields? Are authenticatorData, clientDataJSON, UP, UV, type, and challenge handled correctly? P-256 verification. Is the verifier in use trustworthy? Does it depend on an external upgradeable contract? How are RIP-7212 call failures handled? Are low-S and public-key validity checks enforced?

Account abstraction. Can nonce handling, validator routing, session keys, paymasters, hooks, or modules bypass or expand the Passkey's authorization? For EIP-7702-style smart EOAs that delegate to a Passkey-controlled implementation, does the delegation-revocation path remain under the user's control, and what happens if the delegated contract is upgraded?

Infrastructure. Are bundlers and RPC providers single points of dependency? Are API keys exposed on the client? When a service degrades, can user assets become locked or unmanageable?

Recovery. Are guardian, OIDC, email, SMS, and cloud-account recovery weaker than the Passkey main path? After a successful recovery, can the signer be rotated immediately? Are there delay, notification, and revocation mechanisms?

Sync. Does the project distinguish device-bound credentials from synced Passkeys? Does multi-device synchronization alter clone detection, signCount semantics, device-loss procedures, and cloud-account-takeover risk?

Every one of these comes back to the same question: is the authority to move assets correctly scoped at each stage?

Conclusion

Passkey Wallets offer a credible path past the seed-phrase barrier that has long constrained Web3 adoption. For builders, they reduce onboarding friction, shorten the first-run experience, and bring the growth path closer to that of a mainstream consumer application. For users, opening a wallet for the first time no longer requires assuming full key management on day one.

But dropping the seed phrase does not drop the job of protecting the keys. The authority that moves a user's assets now runs across many parts: device authenticators, the app that builds the transaction, the WebAuthn challenge, account-abstraction infrastructure, on-chain validators, cloud sync, and recovery flows. If any link in that chain reads a user's confirmation as broader permission than the user meant, it will sooner or later show up as a loss, both in the builder's product and in the user's portfolio.

As more assets move onto chains that support Passkey-based authorization, getting this right is what separates a safer wallet from a costly one. CertiK is researching this ecosystem and will keep publishing work to help make it safer.

FAQs

What is a Passkey Wallet and how does it differ from a seed-phrase wallet?

A Passkey Wallet replaces the traditional seed phrase with WebAuthn-based authentication, letting users authorize on-chain transactions using a device biometric (such as Face ID or Touch ID) instead of guarding a mnemonic phrase. Where a seed-phrase wallet concentrates all asset-control authority in a single secret the user must protect alone, a Passkey Wallet distributes that authority across several components — the device authenticator, the wallet application, the WebAuthn challenge protocol, account-abstraction infrastructure, on-chain validator contracts, and cloud sync and recovery surfaces — each of which represents its own security boundary.

How does a Passkey Wallet authorize an on-chain transaction?

When a user initiates a transfer, the wallet application assembles the transaction and hashes it into a fixed-length fingerprint called a userOpHash. That hash is passed to the device as the WebAuthn challenge. After the user completes biometric verification, the authenticator signs the challenge along with authenticatorData (which carries user-presence and user-verification flags). The resulting signed assertion is encoded and submitted on-chain, where a validator smart contract checks that the signature is cryptographically valid, that the signed fingerprint matches the pending transaction, and that the required user-interaction flags are set before execution proceeds.

What are the biggest security risks in a Passkey Wallet?

The main risks cluster in three areas rather than at the cryptographic core. First, the app and WebAuthn surface before signing — malicious browser extensions, injected scripts, or compromised WebViews can manipulate the WebAuthn API or the challenge being signed. Second, on-chain validation logic — bugs analogous to CVE-2022-21449 ("Psychic Signatures") can cause a verifier to accept invalid signatures, and missing checks on user-presence or user-verification flags can weaken transaction authorization. Third, sync and recovery paths — synced Passkeys extend the security boundary to the user's cloud account, so an account takeover compromises the credential, and weak recovery options (SMS, email, OIDC) can represent a lower-security parallel path to asset control.

Are synced Passkeys safe to use in a Web3 wallet?

Synced Passkeys, the default on iOS via iCloud Keychain, offer a meaningful usability improvement by letting credentials travel across a user's devices, but they change the threat model in important ways. The security boundary expands from the local device to the cloud account protecting the sync service, meaning an Apple ID compromise can lead to a credential compromise. Additionally, iCloud Keychain keeps the WebAuthn signCount at zero because a monotonic counter cannot survive multi-device sync, so any wallet relying on signCount to detect cloned credentials must drop that assumption. Teams building Passkey Wallets should clearly distinguish device-bound credentials from synced ones and design recovery and revocation flows accordingly.

What should developers check when auditing a Passkey Wallet?

A full audit should trace the full asset-control lifecycle rather than focusing only on the cryptographic primitive. Key checks include: whether the Passkey public key is correctly bound to the right user, domain, and smart account at registration; whether the WebAuthn challenge commits to the full transaction semantics including account, chain ID, nonce, callData, and EntryPoint; whether the on-chain validator correctly checks authenticatorData flags (UP, UV), the clientDataJSON type field, and the embedded challenge; whether the P-256 verifier enforces low-S normalization and public-key validity; whether account-abstraction components such as paymasters, session keys, and module hooks can bypass or expand Passkey authorization; and whether recovery paths are at least as strong as the primary Passkey flow.