I still remember the quiet unease that settled in when the first reports about weakened seed generation started circulating. You buy a hardware wallet precisely so you never have to worry about someone else holding the keys. Then you learn that a change made years earlier left some of those seeds far weaker than intended. That is exactly the situation Coldcard owners faced this summer, and the latest firmware release does not wave a magic wand over the problem. It forces a hard choice: keep using a compromised recovery phrase or move everything to a brand-new wallet.
Why The New Firmware Still Demands A Full Wallet Migration
On August 20 the company pushed versions 5.6.1 for the Mk4 and Mk5 models and 1.5.1Q for the Q series. The update lands after three solid weeks of internal review that began with a July 31 emergency patch. The core issue was never a hardware failure in the classic sense. It was a software regression that quietly reduced the entropy feeding into new seed phrases on certain firmware builds.
Researchers discovered that older code paths sometimes fell back on a deterministic MicroPython routine instead of pulling fresh randomness from the STM32 true random-number generator and the two secure elements. The result? Seeds that should have offered roughly 128 bits of security ended up closer to 40 bits on some Mk2 and Mk3 devices and around 72 bits on later models. Those numbers are low enough that a determined attacker can brute-force candidate seeds offline, derive the corresponding addresses, and simply watch the blockchain until a match appears.
I’ve followed hardware-wallet security for years, and this particular flaw sits in an uncomfortable middle ground. It is not the dramatic physical attack that steals a device from your pocket. It is quieter and, in some ways, more unsettling because the private keys never leave the device yet the funds can still disappear. Once an attacker finds a matching address on-chain, the rest is just a standard transaction.
What The Update Actually Changes
The new firmware does three practical things. First, every freshly generated seed must now incorporate explicit user-supplied entropy. You can hammer at least 65 key presses with unpredictable timing, roll a physical six-sided die fifty times, or flip a coin 128 times. The device mixes that private input with fresh output from the hardware RNG and both secure elements. The idea is simple: no single component is allowed to be the sole source of randomness.
Second, the release tightens several signing and connection boundaries. Partially signed Bitcoin transactions now undergo staged verification right before the device commits a signature. Default SIGHASH behavior has been adjusted. USB handling and firmware-update checks are stricter. Delta Mode isolation is improved, and additional sanity checks sit around random-number generator initialization.
Third—and this is the part that matters most to existing users—the firmware cannot repair a seed that was already created under the flawed versions. Installing the update only changes future behavior. The old recovery words remain exactly as weak as they were the day they were generated. Importing those same words into a different wallet, a software tool, or even the newly updated Coldcard changes nothing about the underlying entropy deficit.
Which Seeds Are Actually Affected
Not every Coldcard seed ever produced sits in the danger zone. The company and independent researchers have drawn reasonably clear lines. Mk2 and Mk3 seeds generated on firmware 4.0.1 through 4.1.9 fall inside the affected window. For Mk4 and Mk5 devices the problem covers seeds created before standard firmware 5.6.0 or the corresponding Edge builds. Q users are covered if their seeds pre-date standard version 1.5.0Q or Edge 6.6.0QX.
Mk1 devices sit outside the regression. Other Coinkite products that use entirely different code bases—TAPSIGNER, OPENDIME, SATSCARD—are not part of this particular disclosure. There is also a narrow exception for anyone who deliberately added at least fifty fair, independent, private dice rolls before the final seed words were written down. Those extra rolls were intended to push the entropy back above the 128-bit threshold. If you cannot remember the exact count, used fewer than fifty, or ever exposed the sequence, the safe assumption is that the exception does not apply.
A BIP-39 passphrase does not magically repair the seed either. It adds another layer an attacker must guess, but the underlying recovery phrase itself stays weak. Owners of affected seeds have been told, quite correctly in my view, to treat the passphrase as insufficient and to replace the seed entirely.
The Practical Migration Path
The recommended sequence is straightforward yet non-negotiable. Update the device first and verify the digital signature of the firmware file before you install anything. Once the new version is running, generate a completely fresh seed using one of the new user-entropy methods. Record that seed offline, confirm the receiving address on the device screen itself, and send a small test amount. Only after the test confirms everything works should the bulk of the balance move.
Keep the old backup until you are certain the migration succeeded. Then destroy or securely archive it so it can never be used again for receiving funds. The old addresses remain visible on the blockchain; anyone monitoring them will eventually notice the movement. That visibility is simply the nature of a public ledger.
Some people ask whether they can simply keep the old seed and add a very strong passphrase. Technically the passphrase increases the work factor, but it does not restore the missing entropy in the seed itself. From a pure risk-management standpoint the cleaner solution is a new seed generated under the corrected process.
How The Attack Actually Worked
The vulnerability never required physical access to the device, knowledge of a PIN, or any on-chain attack against the Bitcoin network. An adversary who understood the reduced entropy space could generate large batches of candidate seeds, derive the corresponding addresses, and compare those addresses against the public blockchain. A match handed over the private keys. From that moment the funds could be moved like any other ordinary transaction.
Later analysis pointed to several waves of activity that collectively removed an estimated 1,816 BTC from more than five thousand addresses. Loss figures have shifted as researchers sorted confirmed victim reports from addresses that simply shared transaction patterns. Galaxy Research noted that roughly ninety percent of the coins taken during the confirmed waves had not yet moved from the identified destination wallets as of early August. That detail suggests either patient accumulation or careful laundering still underway.
In my experience the most unsettling part of these offline-seed attacks is the lag. Funds can sit for months or years before an attacker decides the time is right. Owners who never noticed unusual activity on their addresses could still be exposed.
Broader Effects On Custody Decisions
The episode has already nudged some holders toward different custody arrangements. Exchange inflow data after the first public warnings showed unusually large deposits. One compliance officer at a major platform described the volume as record-level. Moving coins to a centralized service removes the owner’s direct responsibility for seed generation and storage, yet it replaces that responsibility with counterparty risk. For pure price exposure, regulated spot Bitcoin products offer another route that keeps the underlying coins under institutional custody while the investor holds a share.
Neither path is universally better. Self-custody remains attractive for those who value direct control and are willing to follow rigorous operational security. The Coldcard incident simply raised the cost of that control for a subset of users who must now spend time and on-chain fees to migrate. It also reminded everyone that hardware wallets are only as strong as the software that generates the seeds and the entropy sources that feed them.
Additional Hardening Beyond Seed Creation
Firmware 5.6.1 and 1.5.1Q do more than enforce user entropy. Staged PSBT verification reduces the chance that a malicious or malformed transaction slips through. Changes to default SIGHASH handling limit the surface an attacker can exploit if they somehow influence transaction construction. Stronger USB and update-path boundaries make it harder for an intermediate machine to inject altered firmware or extract sensitive material during routine operations.
Delta Mode isolation received improvements, backup handling for the active wallet was cleaned up, and extra checks now sit around random-number generator startup and potential fault injection. None of these measures fix an already-generated weak seed, yet they raise the bar for future attacks that might target the device after the update.
Users are still expected to verify the signed firmware package before installation. Signature checks remain one of the simplest ways to confirm that the file actually came from the manufacturer and has not been altered in transit.
Practical Habits That Still Matter
Even after migration, a few operational habits continue to reduce risk. Always confirm receiving addresses on the device screen rather than trusting a computer display. Keep seed backups offline and physically protected. Prefer multisignature setups when the balance justifies the extra complexity. Test recovery procedures periodically with small amounts so that the process is familiar if it is ever needed under pressure.
I have watched too many people treat the seed phrase as a one-time chore that can be forgotten once written down. The Coldcard episode shows why that attitude is dangerous. Entropy quality, firmware history, and the exact generation method all matter. A seed that looked perfect in 2021 may sit inside a known vulnerable range today.
Looking Ahead
Hardware wallet manufacturers will keep refining entropy collection and verification. Users, for their part, will keep learning that “set and forget” is rarely safe in self-custody. The latest Coldcard release closes one specific regression and hardens several surrounding processes. It cannot, however, rewrite history for seeds that were already created under the weaker regime.
If your device and seed fall inside the affected ranges, the only reliable path is a full migration. Update first, generate a new seed with explicit user entropy, verify the new wallet thoroughly, move the funds, and retire the old recovery phrase. Anything short of that leaves the original weakness intact.
The episode also underscores a larger point about Bitcoin security. The protocol itself remains robust. The surrounding tools—seed generation, firmware, secure elements, user procedures—still require constant scrutiny. A three-week review cycle after an emergency patch is better than silence, yet the real test is whether owners act on the information while their coins are still under their control.
In the end the decision sits with each holder. Some will migrate promptly. Others will weigh the fees, the time, and the perceived risk and decide the old seed is still acceptable. The mathematics of reduced entropy do not care about that calculation. An offline attacker who already has the candidate list can wait as long as necessary. That simple reality is why the firmware release came with a clear warning rather than a reassurance that everything was already fixed.
Self-custody only works when the foundations stay solid. The newest Coldcard firmware restores stronger foundations for future seeds. For the seeds that already exist under the older, weaker process, the only remaining foundation is a deliberate, carefully executed migration. Anything less leaves the door open longer than most people would willingly accept.
