Bitcoin Multisig Security: Key Challenges

A multi-signature (multisig) wallet needs signatures from several private keys before it can move bitcoin. In a 2-of-3 wallet, three keys exist and any two can sign; a 3-of-5 needs any three of its five keys. No single key is a point of failure: losing one key doesn’t lock you out, and a thief who steals one can’t spend. The price is more work than a single-signature wallet asks of you, both when you set it up and when you need to recover it.

A comparison of 2-of-3 and 3-of-5 multisig. In 2-of-3, two of three keys sign: you can lose 1 key and still spend, a thief needs 2 keys, each payment needs 2 devices, and you look after 3 places, one key in each. In 3-of-5, three of five keys sign: you can lose 2 keys, a thief needs 3, each payment needs 3 devices, and there are 5 places to look after. — **Any M of the N keys can spend; fewer than M can’t move anything.** In a 2-of-3 one key alone is useless to a thief, and losing one key doesn’t lock you out. A 3-of-5 can lose two keys, at the cost of five places to look after and a third device at every payment.

This guide shows where that work lies. Each key has its own seed phrase, and software builds the wallet from each key’s extended public key (xpub: a read-only key from which software calculates that key’s public keys) and derivation path (the numbered route from a seed to that key). So your backups need more than the seed phrases on paper or metal: they need the wallet descriptor, one line of text that records every xpub and path, the script type and the threshold. Hardware wallets such as Coldcard, Ledger and Trezor hold the keys and sign; coordinator software such as Sparrow, Electrum or Nunchuk builds the wallet and prepares transactions, and the two must work together. Once the wallet exists, its structure is fixed: going from 2-of-3 to 3-of-5 means creating a new wallet and moving your funds to it. Then come a seven-step audit for a wallet you already run, the common mistakes and answers to frequent questions.

The wallet descriptor records the threshold (2 of 3), the script type (native SegWit), every key's xpub and every key's derivation path, such as m/48'/0'/0'/2'. If key C is lost but you kept the descriptor, seeds A and B can sign and the descriptor supplies C's xpub, so the coins are found. If key C is lost and there is no descriptor, C's xpub can't be calculated from A and B, so the addresses can't be rebuilt. Someone who finds a descriptor alone sees every address, your balance and your full history, but has no key to sign. — **Seeds sign; the descriptor finds the coins.** With one key lost, two seeds are enough to sign but not to rebuild the wallet’s addresses: that needs every xpub, and the lost key’s xpub now survives only in saved copies of the wallet setup, such as the descriptor, the coordinator’s wallet file or a Coldcard it was registered on. The descriptor can’t spend, but it reveals the whole wallet.

Step-by-Step Guide to Auditing Your Multisig Security

Each key's entry in a wallet descriptor reads [fingerprint/derivation path]xpub, for example [3a8f1c62/48'/0'/0'/2'] followed by the xpub. The fingerprint names the seed, the path is the route from the seed to this key, and the xpub is the read-only key. Step 1: three different fingerprints mean three seeds; if two keys show the same fingerprint, one seed fills two slots, so whoever holds it can sign twice and, in a 2-of-3, spend alone. Step 4: in the path 48'/0'/0'/2', 48' is the multisig standard, 0' bitcoin mainnet, 0' account number 0, and 2' native SegWit; 1' in the last place would mean wrapped SegWit (P2SH-P2WSH), which gives other keys. The same seed on another path gives a different xpub and the wallet looks empty. Both must match your setup notes. — **Your descriptor names every key by its fingerprint and its path.** A repeated fingerprint means one seed is doing the job of two keys. A path that differs from your notes means different keys. The fingerprints shown are examples.

Verify Key Independence Across All Cosigners
Confirm that each hardware wallet in your multisig configuration was initialized with an independently generated seed phrase, and that no two devices share the same seed. Open your wallet coordinator software and examine each cosigner’s master fingerprint -- every fingerprint should be unique. If two fingerprints match, one seed fills two slots: whoever holds it can sign twice, which in a 2-of-3 is enough to spend, and losing it loses two keys at once. Check which company made each device, too: use at least two makers, ideally a different one for each key, so one firmware flaw can’t reach enough keys to spend. In July 2026 a flaw in Coldcard firmware turned out to have made seeds generated on those devices far easier to guess (see our Coldcard advisory).
Audit Your Xpub Exposure
List every location where your extended public keys have been shared or stored: wallet coordination software, cloud backups, email threads, collaborative custody providers, and any device that has ever connected to your wallet. Each xpub exposure point is a privacy leak, and anyone who holds all of your xpubs (or the descriptor, which contains them) can see your full transaction history and current balance. If xpubs have been shared with unnecessary parties, consider whether this exposure is acceptable or whether migrating to a fresh wallet is warranted.
Test Each Signing Device Independently
For each hardware wallet in your multisig setup, verify that it can produce a valid signature by creating a test PSBT (Partially Signed Bitcoin Transaction) and signing it with that device alone. If your coordinator then shows the PSBT as signed by that device’s key, the device still holds its key for this wallet: its seed is intact and it has not been silently reset or corrupted. The PSBT carries the scripts the device signs with, so this doesn’t test your descriptor backup; the recovery drill below does. Run the signing test on every device, not just the ones you use most frequently. An untested backup device that fails during an emergency defeats the purpose of redundancy.
Validate Derivation Path Consistency
Export the wallet descriptor from your coordinator software and verify that each cosigner’s derivation path matches what you documented during initial setup. Common multisig derivation paths include m/48'/0'/0'/2' for native SegWit P2WSH and m/48'/0'/0'/1' for wrapped SegWit P2SH-P2WSH. If a hardware wallet firmware update has changed the default path, or if you restored a device without specifying the exact path, the resulting xpub may differ and the wallet will generate incorrect addresses.
Confirm Backup Completeness at Each Storage Location
Go in person to each physical location where you store backup materials. Verify that each location contains exactly what your backup map says it should: the correct seed phrase, the wallet descriptor file, any passphrase backup the map puts there, and any additional metadata. If someone you trust checks a location for you, they should only confirm that the backup is there and undamaged, without opening it or reading the words: a helper who reads one seed and already holds another key can spend from a 2-of-3. Check for physical damage -- water intrusion, corrosion on metal backups, faded ink on paper. Replace any degraded backups immediately. A backup that was valid two years ago may be unreadable today.
Review Coordinator Software Version and Integrity
Check that your wallet coordinator (Sparrow, Electrum, Nunchuk, etc.) is running a recent stable release and that you downloaded it from the official source. Verify the PGP signature of the download against the developer’s published key. Outdated coordinator software may contain known vulnerabilities, and a compromised coordinator could manipulate transaction details displayed on screen. If you are running a version more than six months old, update before your next signing session.
Document Findings and Schedule the Next Audit
Record the results of each verification step in a private, encrypted document. Note the date, the firmware version of each device, the coordinator software version, and the status of each backup location. Set a calendar reminder to repeat this audit every six months, or immediately after any significant event such as a firmware update, a device replacement, or a change in storage locations.

Common Mistakes to Avoid

Failing to Verify Receive Addresses on the Hardware Device

When receiving Bitcoin to a multisig wallet, the coordinator software displays a receive address -- but if the coordinator has been compromised, it could display an attacker’s address instead. A signing device that knows the whole multisig wallet can independently verify that a receive address belongs to the multisig quorum: a Coldcard, Passport or Keystone registers that wallet once, and a Trezor is sent the other keys with each request and can show them, so you can compare them with your records. Before sharing any receive address or sending funds to it, display the address on at least one (preferably two) hardware devices and confirm it matches what the coordinator shows. On a Trezor, also check that the threshold and the other keys it shows match your records: it builds the address from the keys the computer sends, so a tampered coordinator could swap in its own keys and both screens would still agree. Skipping this step exposes you to address substitution attacks.

Trust the address on the device, not on the computer. The device works out the address itself from the keys of the whole wallet, which a Coldcard, Passport or Keystone stores once you register it; a Trezor is sent them with each request, so compare the threshold and the keys it shows with your notes before trusting a match. If the two screens differ, the computer has been tampered with: don’t share that address.

Keeping All Hardware Devices in One Location

Storing all your signing devices together eliminates the geographic distribution that gives multisig its resilience against physical threats. A single burglary, fire, or natural disaster can destroy every device simultaneously. Distribute your signing devices across physically separate locations, one key per location. In a 2-of-3 setup, keep one device at home, one at a secondary secure location, and one with a trusted contact or in a bank vault. No single location should hold enough keys, counting devices and seed backups, to meet the signing quorum.

A 2-of-3 wallet kept in two places: home holds keys A and B, a bank vault holds key C. A burglar at home takes two keys, enough to spend, and a fire at home leaves you one key, not enough. The same wallet in three places, one key each: home holds A, a bank vault holds B and a trusted contact holds C. A burglar at home takes one key, not enough to spend, and a fire at home leaves two keys, so you can still spend. — **In a 2-of-3, three places, one key in each.** A key is its device or its seed backup, so count both. Keep a copy of the descriptor in every place, so any two places together can rebuild the wallet.

Using the Same PIN or Passphrase Across Multiple Devices

If an attacker learns the PIN for one of your hardware wallets through shoulder surfing or social engineering, using the same PIN on all devices means they can unlock every cosigner key once they physically obtain the devices. Assign a unique, strong PIN to each hardware wallet. Similarly, if you use BIP39 passphrases, use different passphrases for different devices. This way, compromising the access credentials for one device does not cascade to the others.

Neglecting Firmware Updates Out of Fear

Some users refuse to update their hardware wallet firmware because they worry the update process will wipe the device or introduce bugs. While caution is reasonable, running severely outdated firmware exposes you to known security vulnerabilities that have been publicly disclosed and potentially exploited. The correct approach is to verify your seed backup is intact, update one device at a time, and confirm the device still produces valid signatures before updating the next one.

Not Testing Recovery Before You Need It

The worst time to discover a gap in your recovery procedure is during an actual emergency. Many users set up multisig, store their backups, and never test whether they can reconstruct the wallet from those backups alone. Perform a full recovery drill at least once a year, covering every seed, one at a time so two never sit in the same place: restore each seed backup (with its passphrase, if you use one) onto a wiped test device, reimport the wallet descriptor, verify that the addresses match and have that key sign a test transaction, then wipe the device again. Open every descriptor copy too.

Frequently Asked Questions

Can an attacker steal my Bitcoin if they obtain one of my hardware wallets?

In a properly configured multisig setup, possessing a single hardware wallet is not sufficient to move funds. The attacker would also need to bypass the device’s PIN protection and then obtain additional cosigner signatures to meet the quorum threshold. However, a stolen device does compromise one key, which reduces your security margin. If a device is lost or stolen, immediately create a new multisig wallet with fresh keys and move your funds to it, signing with the keys you still hold.

An old 2-of-3 wallet with keys A, B and C, where key C has been stolen. One transaction signed with A and B, which pays a fee, moves every coin to a new 2-of-3 wallet made with three fresh keys, D, E and F. The new wallet has a new descriptor and different addresses; the old one's addresses are left empty. Going from 2-of-3 to 3-of-5 works the same way: a new wallet and one move. — **A multisig wallet’s structure is fixed; changing it means moving the coins.** The addresses are calculated from the exact set of keys and the threshold, so even one replaced key, or a new threshold, gives a different wallet. After a key is lost or stolen, make the new wallet with fresh keys, and set it up, test it and back up its descriptor before the coins move.

What happens if my wallet coordinator software is discontinued?

Your Bitcoin is secured by the Bitcoin protocol itself, not by any particular software application. If your coordinator is discontinued, you can import your wallet descriptor (which contains all xpubs, derivation paths, and the quorum requirement) into any other compatible coordinator software. The standardized output descriptor format (BIP 380, with the multisig expressions in BIP 383) ensures portability between different wallet applications. Keep an exported copy of your wallet descriptor specifically for this scenario.

How do I handle a situation where one cosigner device has outdated firmware that cannot be updated?

If a device’s firmware is so outdated that it can no longer receive updates or communicate with current coordinator software, you should treat it as a compromised key. Use your remaining functional devices to sign a transaction moving all funds to a new multisig wallet that includes a replacement device with current firmware. Do not continue operating with a device that cannot be verified or updated, as undisclosed vulnerabilities in old firmware may put your funds at risk.

Is a 3-of-5 multisig always more secure than a 2-of-3?

Not necessarily. A 3-of-5 setup tolerates the loss of two keys before funds become unrecoverable, versus one key in a 2-of-3 setup. However, it also requires managing five separate backup locations and five hardware devices, which introduces more operational complexity and more surface area for human error. If you cannot reliably maintain five independent secure storage sites, the additional complexity of 3-of-5 may actually decrease your practical security compared to a well-executed 2-of-3 configuration.

Related Resources

Part of our free Bitcoin course: This topic is covered in Multisig Wallets Explained: 2-of-3 Security With Multiple Keys, from the Advanced Bitcoin Security & Privacy course.

Filed under: Bitcoin Security