Hardware Wallet Security: 12 Steps After $100M Hack [2026]

Coinkite’s Coldcard has spent years marketing itself as the paranoid option for Bitcoin self-custody: open source, air-gapped, no secure-element single point of failure. Then, on July 30, 2026, an attacker started draining Coldcard wallets in under half an hour. Galaxy Research mapped one sweep that pulled roughly $70 million from 1,196 addresses in just 41 minutes. By August 4, TechCrunch put the running total above $130 million, with at least a dozen different hackers working the same bug.

The cause wasn’t a stolen private key or a phishing email. It was a firmware bug that had shipped since March 2021, quietly weakening the randomness behind seed generation on affected devices. Anyone who generated a seed on vulnerable firmware, without adding their own dice-roll entropy, was exposed the moment researchers reverse-engineered the flaw.

This tutorial covers hardware wallet security from the ground up: how to check whether your device is exposed, how to verify and install firmware safely, how to generate a genuinely random new seed, and how to build a small audit script you can rerun any time a vendor ships a security advisory. Every step below uses tools you can inspect yourself, not a screenshot or a forum thread you have to take on faith.

Why Hardware Wallet Security Is Back in the Headlines

For most of the last decade, the pitch for hardware wallets was simple: keep your keys offline, and nobody can touch them remotely. The Coldcard incident complicates that pitch without breaking it entirely. TRM Labs called it the “largest hardware wallet exploit of 2026,” and the damage kept climbing for days after disclosure. That wasn’t because the attack kept evolving. It was because researchers kept finding more exposed addresses tied to the same root cause.

Coinkite, the Canadian company behind Coldcard, confirmed the bug affects Mk2 and Mk3 units running firmware 4.0.1 through 4.1.9, plus older Mk4, Mk5, and Q models on firmware released before mid-2026 patches. The company’s own advisory is blunt about the mechanism: instead of relying purely on the device’s hardware random number generator during seed creation, the flawed firmware hashed the device-generated seed together with every dice roll entered. That change quietly cut the effective entropy on Mk2/Mk3 seeds from 128 bits down to roughly 40 bits, unless the owner had entered at least 50 independent dice rolls.

Forty bits sounds abstract until you translate it. A 128-bit key is effectively unguessable with any hardware that exists today. A 40-bit key sits within reach of a well-funded attacker running dedicated cracking hardware, and multiple research teams appear to have done exactly that within days of the flaw being scrutinized publicly.

This isn’t the first time self-custody hardware has made headlines for the wrong reasons. Ledger’s 2020 e-commerce database leak exposed customer contact information, not device keys, but it still triggered years of phishing attempts against known Ledger buyers. The Coldcard flaw is a different category of failure: it lives inside the cryptography itself, not around it. That distinction matters for how seriously you should treat firmware updates going forward, and it’s the reason hardware wallet security now means more than just “keep the box unplugged from the internet.”

Inside the Coldcard Entropy Flaw: What Actually Went Wrong

The timeline moved fast once the first drains were noticed. Here’s how the reported losses climbed, according to on-chain analysis firms and the outlets that covered them.

Date	Reported Development	Estimated Loss
July 30, 2026	First coordinated sweep begins, Galaxy Research maps 1,196 addresses drained in 41 minutes	~$70.2 million
July 31, 2026	Earlier wave drains roughly 500 wallets in a 25-minute window	~$38 million (594 BTC)
August 1, 2026	Coinkite ships patched firmware across affected model lines	Remediation begins
August 3, 2026	Reported theft climbs to roughly 1,359-1,367 BTC across about 4,585 addresses	~$89 million
August 4, 2026	The Hacker News and TechCrunch report at least a dozen distinct attackers exploiting the same bug	$130 million+

Different outlets landed on different totals because they were tracking different wallet clusters at different points in an active, ongoing sweep, not because the underlying facts were in dispute. CBC News reported the running theft had passed $100 million as attackers continued working through exposed addresses over the following days.

Coinkite’s own advisory draws a hard technical line between affected and safe firmware. The company also confirmed that TAPSIGNER, OPENDIME, and SATSCARD run on separate codebases and were never at risk from this specific bug.

Model	Affected Firmware	Fixed Firmware	Entropy Impact
Mk2 / Mk3	4.0.1 – 4.1.9	4.2.0 or later	Drops to ~40 bits without 50+ manual dice rolls
Mk4 / Mk5 (standard)	Before 5.6.0	5.6.0 or later	~72 bits instead of 128 bits
Mk4 / Mk5 (Edge)	Before 6.6.0X	6.6.0X or later	~72 bits instead of 128 bits
Q (standard)	Before 1.5.0Q	1.5.0Q or later	~72 bits instead of 128 bits
Q (Edge)	Before 6.6.0QX	6.6.0QX or later	~72 bits instead of 128 bits

Crucially, the advisory notes that updating firmware alone does not repair a seed that was already generated under the bug. The fix changes how future seeds get created. Existing exposed seeds need to be replaced and their funds migrated, which is most of what the rest of this tutorial covers.

Prerequisites: Tools, Versions, and What You’ll Need

Gather the following before starting. Skipping one of these is the most common reason people end up redoing this process a second time.

• Your hardware wallet and its original packaging, useful for checking tamper-evident seals if your model uses them
• A computer you trust, one you can temporarily disconnect from the internet during the seed-generation step
• Two physical dice at minimum for manual entropy (a single die rolled repeatedly works too, it just takes longer)
• A steel or paper backup medium for your new seed, not just the cardstock insert that ships in the box
• Python 3.9 or later, if you plan to use HWI or run the audit script covered later in this guide
• The latest firmware for your specific model, downloaded only from your vendor’s official site or GitHub releases page
• A small amount of the same cryptocurrency already available to send, so you can test the new setup with funds you can afford to lose before migrating everything else

If you’re on Coldcard specifically, check your model and current firmware version first, under Advanced/Tools then Danger Zone then Firmware Version on the device’s own screen. Trezor Suite shows firmware version under Settings then Device. Ledger Live shows it under My Ledger after selecting your connected device. Write both numbers down before you go any further, you’ll need them to cross-reference against your vendor’s advisory in the next step.

Step 1-2: Identify Your Device and Check Firmware

Step 1: Confirm your exact model. “Coldcard” alone isn’t specific enough, and the same is true for “Trezor” or “Ledger.” Mk2, Mk3, Mk4, Mk5, and Q all shipped with different bootloaders and different fixed-firmware targets, so check the label on the back of the unit or the model name shown on the boot screen before you look anything up.

Step 2: Read the firmware version off the device itself, never off a box or a marketing page. On Coldcard, this lives under Advanced/Tools then Danger Zone then Firmware Version. On Trezor Suite, open Settings then Device. On Ledger Live, go to My Ledger and select your device to see the installed firmware alongside any available update.

Cross-reference the version against the table above, or against your vendor’s current security advisory page, before assuming you’re either safe or exposed. Coinkite’s advisory is unusually specific about version ranges, and that specificity is worth checking directly rather than trusting a summary, including this one.

Step 3-4: Verify and Install Firmware the Safe Way

This is the step most people rush, and it’s the one that matters most. Malware that swaps a firmware download for a backdoored copy is a documented attack pattern against self-custody users, so verify before you flash anything onto a device holding real funds.

Step 3: Download and verify. Get firmware only from the vendor’s official domain or their official GitHub releases page, never from a link in an email, forum post, or search ad. Then check the file’s checksum against the hash the vendor publishes alongside the release, and verify the signature on that hash if one is provided.

# Download the firmware and its published SHA-256 hash from the vendor's
# official site, then compare them locally before touching your device.

sha256sum coldcard-firmware-4.2.0.dfu
# Compare the output string against the hash published on the vendor's
# release page or signed release notes. They must match exactly, character
# for character. If they don't, stop and re-download from the source.

# If the vendor also publishes a PGP-signed hash file, verify the
# signature itself before trusting the hash at all:
gpg --verify firmware-4.2.0.sig coldcard-firmware-4.2.0.dfu

Step 4: Install. Use the device’s own update flow, typically a microSD card transfer or a direct USB update through the vendor’s desktop app, and let it finish without interrupting power. Most hardware wallets show a fingerprint or hash on their own screen during the update, a second confirmation independent of your computer. Confirm that on-device value matches what you verified in Step 3 before approving the install.

Step 5-6: Audit Your Seed’s Entropy and Regenerate If Needed

Updating firmware fixes the bug going forward. It does nothing for a seed that already exists under the old, weaker randomness. If your device and firmware version match anything in the affected-models table above, treat your current seed as compromised and plan to replace it, even if your balance looks untouched today.

Step 5: Understand the entropy math. Each fair six-sided die roll contributes log2(6), or about 2.585 bits, of entropy. Fifty rolls gets you to roughly 129 bits, comfortably above the 128-bit target Coinkite’s advisory treats as the safe threshold. Here’s a short script that makes the relationship concrete.

import math

def dice_entropy_bits(num_rolls: int, sides: int = 6) -> float:
    """Return total entropy in bits contributed by rolling a fair die."""
    return num_rolls * math.log2(sides)

for rolls in (20, 50, 99):
    bits = dice_entropy_bits(rolls)
    print(f"{rolls} rolls of a 6-sided die = {bits:.1f} bits of entropy")

# 20 rolls of a 6-sided die = 51.7 bits of entropy
# 50 rolls of a 6-sided die = 129.2 bits of entropy
# 99 rolls of a 6-sided die = 255.9 bits of entropy

Step 6: Generate a new seed. Use the device’s own dice-roll or hardware-entropy option, and if your model supports it, add your own manually rolled dice on top rather than trusting the internal generator alone. Write the new seed down on your backup medium as you go, not from memory afterward. Then verify the device can recover from that exact backup before funding the new wallet. Most hardware wallets include a built-in “confirm backup” flow for exactly this check, and skipping it is how people discover a transcription error only after it’s too late to matter.

Step 7: Add a BIP-39 Passphrase for a Second Layer

A BIP-39 passphrase, sometimes called a “25th word,” adds an extra string on top of your seed. Different passphrases, including no passphrase at all, each produce a completely separate wallet from the same 24 words.

Coinkite’s advisory calls out a strong, unique passphrase as an independent mitigation, since even a low-entropy underlying seed becomes far harder to exploit when paired with a passphrase an attacker doesn’t know and can’t derive from the seed words themselves. The tradeoff is real: if you forget the exact passphrase, there’s no recovery path. It isn’t stored anywhere, by design.

Treat it like a second, separate secret. Write it down somewhere different from your seed words, so that finding one doesn’t hand over both. Test the passphrase wallet with a small deposit before relying on it for anything meaningful.

Step 8-9: Verify Receive Addresses and Migrate Funds Safely

Step 8: Verify before you fund. Generate a receive address on your new seed and check it two independent ways: once on the hardware wallet’s own screen, and again in your software wallet or a block explorer. If the two don’t match character for character, stop. That mismatch usually means malware on the connected computer is substituting addresses, a known clipboard-hijacking pattern that has drained wallets even when the hardware device itself was never compromised.

Step 9: Migrate in stages. Send a small test amount first, something you could lose without it changing your week. Confirm it arrives and shows the correct balance in your wallet software. Only after that succeeds should you move the rest of your holdings, and even then, consider migrating in two or three batches rather than one transaction, so a mistake earlier in the process doesn’t touch everything at once.

Step 10: Automate Ongoing Checks with HWI

HWI, the Hardware Wallet Interface, is an open source Python library and command-line tool maintained under the Bitcoin Core ecosystem’s GitHub organization. It talks to Coldcard, Trezor, Ledger, BitBox02, and several other devices through one consistent interface, which makes it useful for scripting checks you’d otherwise repeat by hand inside each vendor’s own desktop app.

# Install HWI in a virtual environment
python3 -m venv hwi-env
source hwi-env/bin/activate
pip install hwi

# List connected hardware wallets and their reported firmware/type
hwi enumerate

# Pull the extended public key for a given account path (read-only,
# never exposes private key material)
hwi -f coldcard getxpub "m/84h/0h/0h"

hwi enumerate returns a JSON list of connected devices along with their type and, for most models, their firmware version, so you can confirm what’s plugged in without opening a separate desktop app for each brand. Because these particular commands are read-only, it’s safe to script them into a recurring check without touching keys or funds.

Step 11: Build Your Own Cold Storage Audit Script

This is the piece that turns the individual steps above into something you can rerun. The script below checks the HWI-reported firmware version for a connected device against a small table of known-vulnerable ranges, then prints a pass or fail summary. It’s a starting point, not a substitute for reading a vendor’s own advisory, but it means you don’t have to remember exact version numbers from memory six months from now.

#!/usr/bin/env python3
"""Cold storage firmware audit: flags known-vulnerable firmware ranges
reported via HWI. Extend KNOWN_ISSUES as vendors publish new advisories."""

import json
import subprocess
import sys

KNOWN_ISSUES = {
    "coldcard": [
        {"range": ("4.0.1", "4.1.9"), "advisory": "Weak seed entropy, fixed in 4.2.0"},
    ],
}

def get_connected_devices():
    result = subprocess.run(
        ["hwi", "enumerate"], capture_output=True, text=True, check=True
    )
    return json.loads(result.stdout)

def version_in_range(version, low, high):
    parse = lambda v: tuple(int(x) for x in v.split("."))
    return parse(low) <= parse(version) <= parse(high)

def audit(devices):
    findings = []
    for dev in devices:
        dtype = dev.get("type", "unknown")
        fw = dev.get("firmware_version")
        for issue in KNOWN_ISSUES.get(dtype, []):
            low, high = issue["range"]
            if fw and version_in_range(fw, low, high):
                findings.append((dtype, fw, issue["advisory"]))
    return findings

if __name__ == "__main__":
    try:
        devices = get_connected_devices()
    except (subprocess.CalledProcessError, FileNotFoundError):
        print("No device detected, or HWI is not installed.")
        sys.exit(1)

    findings = audit(devices)
    if not findings:
        print("No known firmware issues detected on connected devices.")
    else:
        for dtype, fw, advisory in findings:
            print(f"WARNING: {dtype} on firmware {fw}: {advisory}")
        sys.exit(2)

Run it after every firmware update, and add new entries to KNOWN_ISSUES whenever a vendor discloses something new. The hwi enumerate output format varies slightly by device type, so treat the firmware-version lookup as a starting point to adapt for your specific model rather than a drop-in guarantee.

Step 12: Harden Physical Security Against Wrench Attacks

Software fixes don’t help if someone can just point a wrench at you, the term the security industry uses for coercing crypto owners in person rather than hacking them remotely. CertiK tracked 52 verified wrench attacks globally in the first half of 2026, up from 39 in the same period of 2025, a 33% increase. Separate research from Yellow.com put total physical crypto attack losses at $124 million in H1 2026, on pace to roughly double 2025’s full-year figure.

A few practical steps reduce exposure. Don’t disclose your holdings publicly, including on social media or in ways that make your wealth inferable from your activity. Use a passphrase wallet with a decoy balance if you’re at elevated risk, so a coerced device unlock doesn’t expose your full holdings. Consider a multisig setup, covered below, that requires more than one device or location to move funds, since that removes the “one wrench, one wallet” failure mode entirely.

Mail-based social engineering is a related, lower-tech threat. In February 2026, Ledger and Trezor customers both reported receiving fake security letters by physical mail, designed to look like official vendor correspondence and aimed at tricking recipients into typing their seed words into a phishing site. Neither company will ever ask for your seed phrase by mail, email, or phone. Treat any request for it, regardless of channel, as an attack in progress.

Common Pitfalls That Undo Good Hardware Wallet Security

Even careful people make these mistakes. Watch for the following.

• Updating firmware without regenerating the seed. The patch fixes future seed generation. It does not retroactively repair a seed your device already created under the old, weaker randomness.
• Storing a seed phrase digitally. Photos, cloud notes, password manager entries, and email drafts are all searchable by anything with access to that account. Seed phrases belong on physical media only, ideally steel.
• Skipping the test transaction. Moving a full balance in one shot means a typo or address mismatch costs everything at once instead of a small, recoverable amount.
• Reusing one seed across multiple wallet brands or apps. If a bug in one implementation ever exposes derivation data, keeping seeds separate per use case limits the blast radius.
• Buying hardware devices from unauthorized third-party resellers. A unit that shipped from anywhere other than the vendor or an authorized retailer could arrive with tampered firmware or a seed the seller already knows.
• Choosing a weak or reused BIP-39 passphrase. A passphrase that’s guessable, or copied from another account, defeats the entire point of adding one.
• Ignoring the on-device confirmation screen. Malware that alters a destination address on your computer can’t fake what your hardware wallet’s own screen shows, but only if you actually read it before approving.

Troubleshooting Guide

“Invalid firmware signature” during update. This usually means the firmware file was corrupted during download or, less commonly, tampered with. Re-download from the official source and re-verify the checksum before retrying, and never bypass a signature warning to force an install.

HWI doesn’t detect a connected device on Linux. Add the vendor’s udev rules (most publish them in their GitHub repo’s udev directory), then unplug and reconnect the device. Running hwi enumerate as root can mask this rather than fix it, so correct the udev rule instead.

New seed fails verification during backup confirmation. Double check you transcribed the exact word list shown on the device screen, including word order. A single transposed word produces an entirely different, unrecoverable wallet.

Passphrase wallet shows a zero balance. This is almost always expected behavior, not a bug. Every distinct passphrase, including a blank one, derives a completely separate wallet. Confirm you’re entering the exact passphrase used when that specific wallet was funded.

Firmware update appears frozen mid-flash. Don’t unplug the device. Most hardware wallets recover from an interrupted flash on the next boot, but pulling power mid-write on some models can corrupt the bootloader. Wait several minutes before assuming it’s stuck.

microSD card not recognized during firmware transfer. Reformat the card as FAT32, not exFAT, and keep it under the vendor’s documented size limit. Larger or non-standard formatted cards are a common, easy-to-miss cause on Coldcard and similar microSD-based models.

On-device address doesn’t match your software wallet’s display. Stop immediately and don’t send funds. Confirm you’re deriving the same account and address-index path in both places, a common false alarm, and if it still doesn’t match, treat the connected computer as potentially compromised.

Lost count partway through manual dice rolling. Restart the roll sequence from zero. Partial entropy counts aren’t retrievable after the fact, and guessing risks quietly reintroducing the exact weakness this guide is trying to eliminate.

Device won’t power on after an update. Try a different USB cable and port first, since power-delivery issues are a far more common cause than a bricked device. If the screen stays blank after that, check the vendor’s recovery-mode documentation before assuming the unit is dead.

Advanced Tips: Multisig, Shamir Backup, and Air-Gapped Signing

Once the basics are handled, a few upgrades meaningfully raise the bar for an attacker. None of these are strictly necessary for smaller holdings. They matter most once the amount at risk would meaningfully change your year if it disappeared.

Multisig Across Brands

A multisig setup requires signatures from multiple devices, often at multiple physical locations, to move funds. A 2-of-3 configuration spread across two different hardware wallet brands means a single vendor’s firmware bug, or a single stolen device, isn’t enough on its own to lose funds. It adds setup overhead and ongoing complexity, and it’s generally worth that cost once your holdings justify it.

Shamir Backup (SLIP-39)

Shamir Backup, standardized as SLIP-39 and supported on newer Trezor models, splits a seed into multiple shares where only a subset, say 3 of 5, is needed to reconstruct it. That protects against losing any single backup location without needing full multisig infrastructure across separate devices.

Air-Gapped Signing

Air-gapped signing keeps your seed on a device that never connects to any network, communicating with your computer only through a microSD card or a QR code shown on screen and scanned by camera. Coldcard supports this natively. It closes off an entire category of remote attack, since there’s no USB or Bluetooth link for malware to exploit in the first place, though it does mean paying closer attention to your day-to-day signing workflow.

Staying Ahead of the Next Advisory

The uncomfortable detail buried in the Coldcard timeline is that the flawed code was open source the entire time it was live. Anyone could have read it. Nobody caught the interaction between the dice-roll mixing function and the hardware random number generator until a researcher went looking after unrelated reports of suspicious drains. Open source makes an eventual catch more likely, but it doesn’t make it fast, and five years is a long time to carry a silent bug in code that protects real money.

That argues against relying on memory to catch the next one. Most vendors publish releases through GitHub, so you can poll their releases API on a schedule instead of manually checking a blog post every few months. The script below flags the moment a vendor’s latest release tag changes, so a new advisory doesn’t sit unread.

import json
import urllib.request

REPO = "your-vendor-org/firmware-repo"  # swap in your device vendor's actual GitHub repo
STATE_FILE = "last_seen_release.txt"

def latest_release_tag(repo: str) -> str:
    url = f"https://api.github.com/repos/{repo}/releases/latest"
    req = urllib.request.Request(url, headers={"User-Agent": "cold-storage-audit"})
    with urllib.request.urlopen(req, timeout=10) as resp:
        data = json.load(resp)
    return data["tag_name"]

def check_for_update():
    latest = latest_release_tag(REPO)
    try:
        with open(STATE_FILE) as f:
            last_seen = f.read().strip()
    except FileNotFoundError:
        last_seen = None

    if latest != last_seen:
        print(f"New release detected: {latest} (previously seen: {last_seen})")
        with open(STATE_FILE, "w") as f:
            f.write(latest)
    else:
        print(f"No change. Latest release remains {latest}.")

if __name__ == "__main__":
    check_for_update()

Point REPO at your actual vendor’s GitHub organization and repository name, then schedule the script with cron or a similar task scheduler to run weekly. Pair it with the audit script from Step 11 and you’ve got two independent checks: one confirms your connected device isn’t running known-bad firmware, and the other tells you the moment a vendor ships something new to check against. Neither replaces actually reading the advisory when one appears, but together they mean you’ll know an advisory exists instead of finding out from a headline about drained wallets.

Hardware Wallet Security at a Glance

Device	Secure Element	Fully Open Source	Air-Gapped Option	Price
Coldcard Mk4	Dual (Microchip + NXP)	Yes	Yes (microSD/QR)	$148
Trezor Safe 5	Single, EAL6+ certified	Yes (hardware + firmware)	No (USB required)	Check current vendor pricing
Ledger Flex	Single, CC EAL6+ certified	No (closed-source firmware)	No (USB/Bluetooth)	$249

None of these architectures made their vendor immune to a security incident this year. Coldcard’s dual secure elements didn’t prevent the entropy bug, because the flaw lived in the software layer generating the seed, not in the secure element hardware itself. Architecture choices change your threat model, but they don’t replace the need to verify firmware and audit your setup on a schedule, whichever brand you own.

Does This Change the Case for Self-Custody?

The Coldcard incident revived a debate that flares up after every major self-custody failure: are individuals better off holding their own keys, or leaving custody to exchanges and ETFs built to handle exactly this problem? CoinDesk reported the exploit was already “shaking faith in self-custody” within a day of disclosure, with some commentary suggesting it could push cautious investors toward regulated, custodial products instead.

That framing undersells what actually failed here. The bug lived in one company’s implementation of seed generation, not in the underlying concept of self-custody itself. A private key you hold, generated correctly and backed up properly, remains harder for a remote attacker to reach than a balance sitting on a platform that can be hacked, frozen, or run into its own solvency problems. Drift Protocol’s $285 million exploit earlier this year made a related point from the other direction, since custodial and protocol-level failures carry risks of their own.

What the incident argues for is treating self-custody as an ongoing practice, not a one-time purchase. Buying a hardware wallet and generating a seed once, then never revisiting either decision, is exactly the pattern that left thousands of Coldcard owners exposed for years without knowing it. The steps in this guide, verify, audit, migrate, monitor, aren’t a checklist you complete and forget. They’re maintenance, the same way you’d patch a server rather than configure it once and assume it stays secure indefinitely.

Frequently Asked Questions

I own a Ledger or Trezor, not a Coldcard. Does any of this affect me?
The specific bug is Coldcard-only, confirmed by Coinkite’s own advisory. The broader lesson isn’t brand-specific, though. Every device’s security depends on its random number generator working correctly, so the verification habits in this guide, checking firmware versions, verifying checksums, testing before migrating, apply no matter which brand you use.

How do I know for certain if my Coldcard was affected?
Check the firmware version your device was running when you first generated your current seed, not just your current version. If that historical version falls in the affected ranges and you didn’t add 50 or more manual dice rolls at the time, treat the seed as exposed and migrate to a new one.

Do I need to buy new hardware after this?
No. The vulnerability is fixed in firmware, not hardware. Updating to a patched version and generating a new seed on a device you already own is sufficient, according to Coinkite’s own remediation guidance.

What’s the actual difference between updating firmware and generating a new seed?
A firmware update changes the code running on the device going forward. A new seed is an entirely new set of private keys. Updating firmware without generating a new seed leaves you protected against future bugs but still exposed if your existing seed was generated under weak entropy.

Is HWI safe to use, and does it ever touch my private keys?
HWI is open source and maintained under the Bitcoin Core ecosystem’s GitHub organization, so its code is publicly auditable. The commands covered in this guide, like enumerate and getxpub, are read-only and never transmit or expose private key material off the device.

How many dice rolls are actually enough?
Coinkite’s advisory uses 50 independent, private rolls of a fair six-sided die as its threshold, which works out to roughly 129 bits of entropy, above the 128-bit target. Fewer rolls, or rolls that aren’t truly independent, reduce that figure.

What is a wrench attack, and is it really a bigger risk than hacking?
It’s industry shorthand for physically coercing someone into handing over access to their crypto, rather than attacking it remotely. CertiK verified 52 such attacks globally in H1 2026, up from 39 in H1 2025. For holders with publicly known or inferable wealth, it’s a real and growing risk category, separate from firmware-level threats.

Should I use a passphrase, multisig, or both?
They solve different problems. A passphrase is fast to set up and protects against a seed or backup being found on its own. Multisig protects against a single device or location failing entirely. Larger holdings often justify combining both.

Treat this guide as a baseline, not a finish line. Vendors will keep shipping firmware updates, and the specific version numbers in the tables above will eventually go stale. Bookmark your vendor’s advisory page and run the audit script after every update, because there will be a next time.

Related Coverage

• Ledger vs Trezor: $79 vs $59 Hardware Wallets [2026]
• Drift Protocol Hack: $285M Gone in 12 Minutes [2026]
• 1Password vs LastPass: $36/yr, 0 Breaches [2026]
• Passkeys vs Passwords: 8.5s vs 31s Sign-In [2026]
• Post-Quantum Cryptography: 50% of Web Now Safe [2026]

For more on securing digital assets, see our full cryptocurrency coverage.