How to Evaluate a Bitcoin Hardware Wallet After a Security Incident

Written by Coinkite Team Reviewed September 6, 2026

A serious incident changes the question. Do not ask only whether a wallet is now “safe.” Ask what failed, which secrets remain exposed, whether the fix covers your exact model and release, and how much of that answer you can verify without trusting the vendor.

Start with the incident record. Then test the wallet you actually plan to use.

Start with the failure

A useful incident explanation should let you answer five questions without reading marketing copy:

What failed: hardware, firmware, companion software, a backend, or operating procedure?
What access did the attacker need?
Which models, versions, and workflows were affected?
Does updating stop only future exposure, or repair existing secrets too?
What must an affected owner do now?

The fourth question is easy to miss. A firmware update can fix future key or seed generation while leaving an old seed exposed. If so, the user needs a new wallet secret and an on-chain transfer. Updating the same device is not the migration.

Treat statements such as “fixed,” “not remotely exploitable,” and “no customer action required” as separate claims. Each needs its own evidence.

Find the current record

Look for one canonical page with a visible verification date. It should name the current recommended release, the minimum fixed release for every supported track, the remaining user action, and links to the original advisory, firmware archive, source changes, and independent checks.

A dated change log matters. Security guidance changes as evidence improves. Quietly replacing an old explanation makes it hard to know which statement was current at a given time.

Unknowns belong on the page too. A vendor does not need to settle attacker identity, discovery method, or every loss claim before publishing a usable fix and migration path.

Check seed generation

The seed is the root secret. Ask where its entropy comes from, what happens when a source fails, and whether the shipping firmware reaches the source described in the documentation.

User-supplied entropy can add an independent input. It is useful only when the device states how the input is mixed, sets a meaningful minimum, and does not invite the user to expose the intermediate values. Dice rolls, coin flips, key timing, the device-generated input, and the final seed all belong inside the wallet's secret-handling boundary.

If a tool can recompute a seed mix, use it on an offline machine with a disposable test. Prove the math, destroy the notes, and start again with fresh private inputs for the wallet you will fund. A verification exercise that leaves photos, shell history, clipboard contents, or notes behind can create the theft path it was meant to check.

COLDCARD seed-generation flow combining the hardware RNG, two secure elements, and user entropy before producing a BIP-39 mnemonic

Select any node in this source-linked map to inspect its implementation. Independent visualization by scgbckbone. Open full screen or view the source.

Verify the firmware chain

These checks answer different questions:

A hash detects whether a downloaded file changed.
A signature shows that the release was approved by the holder of the signing key.
Published source lets people inspect the implementation.
A reproducible build can connect a released binary to a specific source tree and toolchain.
A device check confirms which version and integrity state the hardware reports.

None proves that the code has no defect. Together they narrow the amount of trust required.

Before generating a real seed, get firmware from the official source, verify the published hash and signature, install it, restart the device, and confirm the reported version. Keep the signed release manifest with your incident notes so the exact artifact can be identified later.

Review signing and recovery

An air gap removes a live connection. It does not stop the device from parsing hostile transaction data carried by QR code or MicroSD card. Check what the screen shows before signing: destination, amount, fee, change, wallet policy, and any unusual sighash or script condition.

Then test recovery before the wallet holds a meaningful balance. Restore the backup, confirm the wallet fingerprint, verify a receive address on the device, and complete a small spend. If a passphrase is used, back it up separately and test the exact passphrase wallet. A perfect signer cannot recover a lost or mistyped passphrase.

For larger holdings, consider whether multisig reduces a single-device or single-vendor failure enough to justify the added backup and recovery work.

Read audits by scope

“Audited” is not a complete answer. Record the reviewer, date, model, firmware version or commit, signed artifact, and security-critical paths that were actually tested.

A source review, real-device test, reproducible build, hardware penetration test, and protocol review cover different failure modes. An old audit does not automatically cover a new model or release. A bug bounty count does not establish severity, and a long disclosure history is not a security score.

Good incident handling leaves behind artifacts: a reproducible report, a fix commit, a release tag, a test, a credit, and a correction log. That record is more useful than a promise that the product is now secure.

Choose for your own setup

There is no universal hardware-wallet winner. Check the dependencies you would inherit:

Is a vendor app or account required for setup, firmware, recovery, or ordinary signing?
Can you use standard recovery material and compatible coordinator software?
Do you need Bitcoin-only firmware or broad asset support?
Will you actually use advanced controls correctly?
Can you rehearse recovery without vendor infrastructure?
Does the incident and disclosure record show clear version boundaries and corrections?

More features are not automatically safer. Neither is a simpler product. Choose the smallest system that covers your real threat model and that you can recover under stress.

The current COLDCARD record

The COLDCARD Security Status page is the living postmortem and remediation record for the July 2026 seed-generation incident. It lists the affected boundaries, current releases, migration guidance, independent checks, and material corrections.

As verified on September 6, 2026, the current recommended standard releases are Mk4/Mk5 5.6.2 and Q 1.5.2Q. Fixed firmware corrects future seed generation. It does not repair an existing seed created on affected firmware; follow the migration guide unless the advisory's independent-dice exception applies.

Current standard firmware requires user-supplied entropy for a new seed and can display the device-generated input before mixing. The public-domain verify_seed_mix.py tool can recompute dice-roll or coin-flip mixing offline; it cannot verify Mash Keys. The verification material is useful, but it is also secret. Use a disposable run to test it, then make the funded wallet with fresh private inputs.

Sources and verification

Reviewed September 6, 2026.