Work through these six questions in order. Answer them about the wallet holding most of your bitcoin, then repeat for any others. If an answer is genuinely unknown, treat it as exposed rather than safe until you can establish it.
What matters is where the seed phrase was created, not which wallet holds it today. A seed created on a Coldcard and later imported elsewhere carries its origin with it.
This specific defect does not apply to you. The architecture questions further down still do.
Continue to step 2.
Exposure follows the firmware version at the moment of seed generation, not the purchase date and not the current firmware. If you cannot establish which firmware created the seed, treat it as unknown rather than safe.
Both primary sources place this range at risk. Coinkite estimates about 40 bits of effective entropy against an intended 128. Fixed in 4.2.0 or later, but that fix does not repair an existing seed. Continue to step 3, then plan a migration.
Coinkite's advisory, updated August 1, confirms these are affected at about 72 bits of entropy. Earlier coverage said these models were safe; that guidance is superseded. Continue to step 3.
Affected on the same basis as Mk4 and Mk5. Continue to step 3.
The affected range begins at v4.0.1 (March 2021), so earlier firmware sits outside this regression. That is not a statement that the device is free of every possible issue.
Coinkite's advisory states that funds are at risk if the seed was created without at least 50 independent, private dice rolls. Fifty fair rolls of a six-sided die contribute at least 128 bits of entropy on their own, which is why that path is treated differently. Adding a handful of rolls inside the normal new-wallet flow is not equivalent.
Your entropy came from the dice rather than the device generator, which materially reduces exposure. Continue to step 4.
Treat the seed as generated by the device. Continue to step 4.
A passphrase is an additional secret that produces a different wallet from the same seed words. An attacker who reconstructs the seed still needs it.
Your bitcoin is now only as protected as that passphrase. Real risk reduction, not elimination. Plan a migration on your own timeline rather than in a panic.
Treat the wallet as exposed and continue to step 5.
This is where the most consequential misreadings happen, in both directions. Multisig protects you when the keys are genuinely independent of one another.
If the steps above put you at risk, there is nothing else standing between the reconstructed seed and your bitcoin. This is the highest-priority configuration to migrate.
Those keys are not independent. They share one firmware and one entropy path, so the quorum can be reached by the same root cause. Rotate the affected keys out.
The threshold still holds, and this is exactly what genuine vendor diversity is for. Rotate the affected keys out in an unhurried, verified process.
The weakness lives in the seed itself, not in the device currently holding it.
Every wallet derived from that seed is exposed, on every chain. Migrate all of them, not only the bitcoin.
Your exposure is whatever the steps above established.
The greatest risk to an exposed holder is usually not the attacker. It is a rushed transfer made at midnight by someone frightened, to an address they did not verify, into a setup they have not tested. Slow down enough to be deliberate.
Generate new keys on a process unaffected by this defect, verify the receiving addresses on the device screen rather than a computer, send a small test amount first, confirm it arrives, then move the balance. Treat the old seed as permanently burned even if a later analysis clears your model.
On where to move: a different hardware vendor, a dedicated dice-generated seed, multi-vendor multisig, collaborative custody, and institutional custody are all legitimate destinations, and the right one depends on how much operational burden you want to carry. Temporarily parking funds at a reputable exchange while you build a proper setup is a defensible choice and is safer than a botched self-custody migration, provided it is temporary and you understand the counterparty trade.
The question worth answering before you choose is not which brand to buy. It is how many independent things would have to fail in the new setup, and who maintains that independence over the next twenty years. We work through that in Is your custody setup actually safe? and score arrangements against it in the Custody Independence Standard.
Check your own records: the purchase date, any firmware update history you kept, and when you first set the device up. If you cannot establish which firmware was running at seed generation, treat the seed as exposed rather than safe. The cost of migrating unnecessarily is far lower than the cost of being wrong.
Temporarily parking funds at a reputable exchange while you build a proper setup is defensible and is safer than a rushed self-custody migration you have not tested. Understand that you are taking on counterparty risk while they sit there, and treat it as a staging step rather than a destination.
Updating firmware does not repair a seed that was already created on an affected version. If your seed is exposed, you need a new seed, not new firmware. Whether to keep using the hardware afterwards is a separate decision about the vendor and your own comfort.