Hardware wallets are usually sold around one simple idea: keep the private key away from the internet, and you remove a large part of the risk.
That is true, but only after the key has been created correctly.
A recent warning from Coinkite shows how security can fail much earlier – at the moment the wallet generates its seed phrase. The device may remain offline, never expose the key to a computer and still create a wallet that is far easier to attack than its owner realizes.
On July 30, Coinkite advised users to move funds from wallets whose seed phrases were generated on a Coldcard Mk3 running firmware 4.0.1 or later.
Older firmware versions on the Mk4, Mk5 and Q were also affected, although Coinkite estimates that the problem was less severe on those devices.
The device used the wrong source of randomness
A seed phrase begins with entropy – unpredictable data used to create the wallet’s private keys.
Coldcard was supposed to take that randomness from a hardware true random number generator built into the device. But after a firmware change introduced in 2021, the seed-generation process began calling a software-based fallback instead.
The mistake was easy to miss.
Both implementations used the same function name and interface. The firmware compiled normally. The correct hardware RNG code was still present in the final binary. A reviewer looking for the expected implementation could find it and reasonably assume it was being used.
It was not.
The seed-generation path was reaching the fallback function.
Coinkite’s early analysis estimates that affected Mk3 seeds may have had roughly 40 bits of effective entropy instead of the intended 128 bits.
The Mk4, Mk5 and Q also mixed in randomness from their secure elements, raising the estimate to around 72 bits. That is stronger than the Mk3 result, but still well below the security level users expected.
The difference is not cosmetic.
A 128-bit seed is considered beyond realistic brute-force attacks. A search space closer to 40 bits is much smaller and may be practical for a well-resourced attacker, especially when many potentially vulnerable wallets can be checked at once.
Why keeping the wallet offline did not solve the problem
The attack does not require someone to connect to the device, infect a laptop or extract a key from secure storage.
The weakness already exists inside the seed.
An attacker can generate possible seeds on separate hardware, derive the corresponding Bitcoin addresses and compare them with addresses visible on the public blockchain.
The owner’s Coldcard does not need to be online. It does not even need to be turned on.
This is the part that makes the incident uncomfortable. An air gap can protect signing and reduce exposure to remote attacks, but it cannot repair weak randomness used during wallet creation.
“Offline” describes where the key is stored and used. It does not prove that the key was generated securely.
A firmware update does not repair an old seed
Coinkite released firmware 5.6.0 for the Mk4 and Mk5 and version 1.5.0Q for the Q.
Those updates fix seed generation going forward. They do not add entropy to a seed that already exists.
Anyone covered by the warning needs to create a new wallet and move the funds.
The safer process is straightforward:
Install the corrected firmware on a supported device.
Generate a completely new seed phrase.
Write down the backup and verify it carefully.
Check the wallet fingerprint and receiving address on the device.
Send a small test transaction.
Move the rest only after confirming the test arrived correctly.
Until the transfer is complete, the old wallet should be treated as potentially exposed.
Dice rolls may have helped – but only when used properly
Coldcard lets users add their own randomness by entering physical dice rolls during seed generation.
According to Coinkite, a seed created with at least 50 fair, independent and private rolls is not considered vulnerable to this RNG issue on its own.
The details matter.
Users should not assume they are safe when they entered only a handful of rolls, cannot remember how many they used or recorded the sequence digitally.
In those cases, migration remains the safer option.
A BIP-39 passphrase may also make an attack harder, but it should not be confused with the device PIN. A short, reused or predictable passphrase may still be guessed.
Coinkite recommends moving funds even when a strong passphrase was used.
The real failure happened in the development process
Random-number failures are not new in cryptography. The more useful question is how this particular mistake remained unnoticed for years.
The intended hardware RNG implementation was in the codebase. It was included in the compiled firmware. The fallback function looked compatible. Nothing obvious broke during compilation.
The product worked.
It simply called the wrong function at the most sensitive moment in the wallet’s lifecycle.
That points to a broader engineering problem: checking that secure code exists is not the same as confirming that the application actually uses it.
For security-critical software, reviews need to follow the full execution path:
Which implementation does the final build link to?
Where does the entropy used for seed generation actually come from?
Can fallback RNG code be excluded entirely?
Will the build fail when the wrong symbol is present?
Are critical calls tested by behavior rather than by source inspection alone?
Coinkite says its hotfix now removes the fallback PRNG object and adds a build-time symbol check that fails unless the expected hardware-specific RNG is present.
That is a useful fix, but the wider lesson extends beyond one wallet manufacturer.
A device can isolate a private key perfectly after generation and still fail at the moment that key is created.
For a hardware wallet, that first moment may be the most important one of all.
Top comments (0)