Multisig, passkeys and wallet recovery: ask who can restore control

Multisig and passkeys are not competing answers to the same question. Multisig specifies how many approvals an account requires. A passkey is a way to authenticate using a public-key credential. A wallet can combine them, but neither label tells you what happens after a lost device, an unavailable signer or a compromised recovery account.

A useful comparison starts with control: who can authorize an ordinary transaction, who can change that rule, and who can restore access when the normal route fails?

Understand the approval threshold

Safe's smart account documentation describes owners and a threshold: the minimum number of owners required to approve a transaction. The account verifies the required authorization through its code.

In a simple hypothetical two-of-three arrangement, owners A, B and C are configured so that any two can approve an ordinary transaction. If A becomes unavailable, B and C can still act. If two owners become unavailable and there is no other authorized route, the remaining owner cannot satisfy that threshold.

The same design must be assessed for unauthorized control. If one attacker acquires sufficient owner credentials, the contract sees valid approvals even though the owner's intent has been violated. The number of listed owners therefore needs to be read alongside how those credentials are controlled.

A three-owner configuration is not automatically three independent decision-makers. One person could operate all three. That may provide redundancy across devices, but it does not provide the same separation as approvals from independent people or teams.

Count shared failures, not just devices

Consider another hypothetical two-of-three setup in which all three signer backups are stored in one cloud account. Losing access to that account might affect several restoration paths at once. An attacker who can obtain usable copies of enough signer credentials from that location could undermine the intended separation.

A different setup could have independent credentials but rely on the same employee, laptop or office for access. The failure is then organizational or physical rather than a weakness in the signature algorithm.

These examples are threat-model reasoning, not claims about a particular product's storage design. Their purpose is to make the dependency visible. Write down the people, devices, backup locations and service accounts required for each signer, then look for overlap.

A recovery arrangement should explain both how legitimate access survives a failure and what prevents an unauthorized person from exploiting the same route. Redundancy alone does not answer the second question.

Identify what the passkey authorizes

The W3C Web Authentication specification describes credentials scoped to a relying party, such as a web service. Authentication demonstrates possession and use of the relevant credential through the WebAuthn process.

That does not automatically make the credential the key that controls a blockchain account. A passkey might authenticate a website login, unlock a service workflow, or supply a signature that a smart account accepts. These arrangements have different trust and recovery boundaries.

Safe's passkey documentation provides a concrete example of the last model: its passkey contracts verify WebAuthn credentials using the secp256r1 curve. Additional verification logic connects the authentication credential to the account's authorization rules.

Ask the wallet provider to describe that connection in plain language. Does restoring website access restore spending authority? Must an existing signer approve a replacement credential? Is the service able to change the onchain owner, or does the account contract require another authorization?

A familiar fingerprint or face-unlock screen cannot answer these questions. The user experience and the account's authority are different parts of the system.

Distinguish synchronization from account recovery

The FIDO Alliance distinguishes synced passkeys from device-bound passkeys. A synced credential can become available through the user's passkey provider on other devices; a device-bound credential remains tied to its device. When biometrics are used, verification happens locally; biometric records are not sent to the website. Depending on the device, a PIN or another supported method can authorize credential use.

Those differences affect the loss scenario. Replacing a phone may be straightforward if the necessary credential can be restored through the provider. A device-bound credential requires another enrolled route or the application's recovery process if its device is gone.

Still, recovering a passkey provider account and recovering a wallet are not necessarily identical operations. Confirm which credential returns, whether the wallet still recognizes it, and what additional records or services are needed. A backup succeeds only if the complete authorization path works.

Check the recovery mechanism and its authority

ERC-4337 defines an account-abstraction architecture in which a smart account validates user operations. It supports programmable account behavior; it does not prescribe a universal recovery policy.

A wallet described as “account abstraction” may therefore have useful recovery features, limited ones, or none configured for the user's account. The relevant evidence is the deployed implementation and settings.

Safe's module documentation explains that extensions can implement features such as social recovery. It also warns that modules can execute transactions and that a malicious module can take over an account. Recovery authority must be assessed with the ordinary approval threshold, because an enabled module can introduce another authorized path.

Use this worksheet to make the design concrete:

A practical recovery rehearsal can use an account with a small test balance, following the provider's documented process. Record the required approvals, delays and external dependencies, including how transaction fees are paid. Never put private keys or recovery secrets in the rehearsal notes.

The useful result is a documented route from a specific failure back to control, with its limits understood. No authentication label can promise an impenetrable or permanently recoverable wallet.

Keep the account's spending-permission inventory alongside the recovery record. Our guide to token approvals and wallet control explains how delegated token access differs from a wallet connection.

Source review: 22 September 2026.