Can a Hardware Wallet Generate a Weak Bitcoin Seed?

A hardware wallet has one job before anything else: create enough unpredictable randomness to produce private keys nobody else can realistically guess. So when a real, disclosed vulnerability in one hardware wallet brand becomes public, an uncomfortable question follows naturally. Could a device built to protect Bitcoin ever create a recovery phrase weaker than it was supposed to be?

The honest answer is not yes or no. It depends on where trust sits inside a specific device, what has been proven about it, and what has only been claimed. A hardware wallet does not remove trust from the process of holding Bitcoin. It relocates it: toward a physical chip, a piece of code, a certification body, or a set of steps the holder controls directly. This article walks through exactly where trust sits, using the July 2026 Coldcard incident and Ledger's different design as the two working examples, so the situation can be judged on evidence rather than on a headline.

The Four Places Trust Lives Inside a Hardware Wallet

A hardware wallet is often described as removing the need for trust. It is more accurate, and more useful, to think of it as concentrating trust into four specific places:

• A physical chip: in the default setup process, seed creation begins with a random number generator built into a piece of silicon. It can be a simple, general-purpose chip, or a dedicated Secure Element built and tested specifically to resist tampering. Holders can substitute their own entropy, such as dice rolls, but most seeds start here.

• A piece of code: even a good chip is only as good as the software instructions reading from it. One wrong instruction can unknowingly break the connection between good hardware and a good outcome.

• A certification body: some manufacturers submit a specific chip to an independent lab for formal testing against a published standard. Certification is a real, bounded data point, not a guarantee of permanent safety, a distinction covered later in the article.

• The holder's own process: buying from an official source, verifying the device on first use, keeping firmware updated, and backing up the seed correctly all sit entirely with the person holding the device.

Every hardware wallet, regardless of brand, asks a holder to accept some mix of these four. The 2026 Coldcard incident and a much earlier, unrelated finding involving Ledger both teach the same lesson from different angles: a security design can be sound in every documented respect and still fail if one connection in the chain breaks.

The Coldcard Bug, Explained in Plain Language

In 2021, Coinkite, the company behind Coldcard, rewrote part of its firmware to use a shared Bitcoin code library instead of a wallet-specific one. The reasoning was sound: use the same well-tested cryptographic code Bitcoin Core relies on. The wiring of the change was not. In Coinkite's own words from its technical explanation of the bug: "The cryptographic choice was sound. The integration was not."

What went wrong, step by step:

• The seed instruction was re-pointed: during the March 2021 migration, the instruction generating a new seed was moved to a different function, one meant to reach the device's dedicated hardware random number generator.

• A safety check tested the wrong thing: a check in the code was supposed to confirm the hardware generator was switched on. Coinkite had deliberately set the relevant switch to off, because Coldcard uses its own separate hookup to the hardware generator. But the check only tested whether the switch existed in the code at all, not what it was set to. It existed, set to zero, so the check passed. Had that check tested the switch's value instead of merely its existence, the build would have failed at compile time and the defect would have been caught before any firmware shipped.

• A silent fallback took over: with the check passed, the finished firmware quietly drew randomness from a general-purpose software formula instead of the hardware generator. On older models, its starting values came mostly from device identifying data and timing information, not from anything unpredictable. On newer models, an extra step mixed in some secure element randomness, which meaningfully improved things but did not restore the intended level of security.
  
  The danger was difficult to see because the wallet still appeared to work normally. As Gonçalo Magalhães, Head of Security at Immunefi, explained to Coinjuice:

  “A guessable seed still writes out twenty-four valid words, still passes the checksum, and still funds and spends normally. Nothing looks wrong from the outside, and there is no alert for a number that was too easy to pick.”

  That is what made the flaw so dangerous. The recovery phrase looked valid, the wallet generated addresses, and transactions worked as expected. The weakness existed underneath the visible setup process, where the seed’s randomness had already been reduced before the holder ever saw the words.
  
  

• Review looked at the right code, not the live path: by Coinkite's own account, earlier review had confirmed the intended hardware random number code was present in the finished firmware. It had not checked which version of the code the seed generation process reached at the end of a chain of function calls. The reviewed code was real. It simply was not the code being used.

Coinkite published a security advisory on July 30, 2026 listing affected firmware versions and migration steps, and losses tied to affected wallets continued to develop after disclosure. Two things did not change because of the bug, worth stating clearly:

• Dice-roll seeds were never affected: Coldcard's dice-roll mode, where the holder rolls physical dice and the device turns the rolls directly into a seed using documented, checkable math, never touched the flawed code path.

• Open code did not fail as a concept: because Coldcard's code is public, the flawed function call and the incorrect check could be identified, described in exact technical detail, and independently reviewed by an outside engineering team within days. Public code does not prevent a mistake. It makes the mistake far easier to find and prove once someone looks.

One distinction is worth keeping precise, because the two words get used interchangeably. As Immunefi founder Mitchell Amador explained in a separate interview on how crypto bug bounties work:

• A bug: any case where a system does not behave the way its own design intended. Plenty of bugs are harmless.

• A vulnerability: a way a flaw can be used to cause real harm.

• The Coldcard case: the meeting point of both. An unintended coding bug produced a real vulnerability, inside a design that was, on paper, correctly conceived.

[Related reading: Mitchell Amador on how crypto bug bounties work]

How Much Randomness Was Lost, in Brief

Two technical analyses published on the day of disclosure, Coinkite's own and an independent review by Block's engineering team, reached different estimates of the remaining randomness, ranging from effectively predictable in some scenarios up to roughly 72 bits, depending on the model and the assumptions used. Both were published in good faith, and neither has been confirmed as final.

The exact figure changes the attack cost, instead of the conclusion: meaning a seed meant to draw from roughly 2^256 possibilities, a number larger than the atoms in a meaningful fraction of the observable universe, was instead drawn from a search space small enough for specialized hardware to plausibly work through. Whichever estimate proves correct, the affected path fell far below the security level a Bitcoin holder is entitled to expect.

The Airbag Problem: When Good Design Still Fails

A useful comparison for what happened is a car's airbag system:

• The design can be correct: engineered properly, tested properly, documented properly by the manufacturer.

• The execution path can still break: a documented category of failure inside the airbag control unit, electrical damage to an internal chip triggered by the crash event itself, has prevented deployment even when the underlying design was sound. This is not hypothetical. U.S. safety regulators have formally investigated airbag control units affected by exactly this failure mode, across multiple manufacturers.

• The lesson: a safety system is only ever as strong as its weakest connection, not its best-engineered part.

The same applies directly to Coldcard between 2021 and 2026. The hardware random number generator existed, was real, and worked exactly as designed. The connection between it and the seed stored on the device broke down, silently, for years, without anyone noticing.

Could My Hardware Wallet Have a Weak Seed?

For a device to be affected by the Coldcard issue specifically, all of the following normally have to be true at once:

• The device is a Coldcard: not a different brand.

• The seed was generated on an affected firmware version: listed in Coinkite's advisory, not a version released after the fix.

• The seed was not generated with the dice-roll method: which was never affected.

• Fewer than 50 independent, private dice rolls were added during setup: Coinkite's advisory states 50 or more rolls added enough independent randomness on their own to sit outside the affected risk.

• The wallet is not protected by a strong, unique BIP-39 passphrase: a strong passphrase adds a separate barrier an attacker still has to break, though Coinkite still recommends migrating to a newly generated seed as soon as practical, even for passphrase-protected wallets.

A disclosed defect in one brand's specific firmware does not mean every hardware wallet shares it. Reading past the headline to the specific affected versions and conditions is the single most useful step in judging whether a personal setup was ever exposed.

How Ledger Places Its Trust

Ledger's hardware answers the same underlying problem with a different structure. Instead of asking a holder to inspect every layer of code, Ledger concentrates the sensitive work inside a dedicated chip. According to Ledger's own developer documentation:

• Two separate chips: a general-purpose microcontroller runs the screen and buttons, and a dedicated Secure Element, a hardened chip based on the same smartcard technology used in bank cards and passports, handles the sensitive cryptographic operations.

• The general-purpose chip holds nothing secret: Ledger's documentation describes it as a router. It performs no application logic and stores no cryptographic secrets.

• Sensitive operations sit inside the Secure Element: Ledger's architecture places entropy generation and private key operations inside the hardened chip, not on the general-purpose one.

The trade-off is direct: the firmware running inside the Secure Element is closed. A holder cannot personally read it. Ledger states this is required under a non-disclosure agreement with its chip supplier, STMicroelectronics, covering the low-level code speaking directly to the chip. What a holder can verify instead is the certification record, the published architecture, and a body of dated security research, covered next.

Certification: What It Proves, and Where It Stops

A certification such as an AIS 31 PTG.2 rating is a real, meaningful data point. It means an independent lab tested a specific chip against a specific, published standard, under specific conditions, and the chip met it.

For Ledger, the confirmed record looks like this:

• Nano X: its ST33J2M0 Secure Element carries a French national cybersecurity agency (ANSSI) evaluated security target confirming its random number generator is certified Class PTG.2 under AIS 31.

• Nano S Plus and Stax: their ST33K1M5C Secure Element carries equivalent ANSSI-evaluated security targets with the same PTG.2 confirmation, and the chip itself holds an independently published EAL6+ Common Criteria certification.

• Flex: Ledger's own hardware documentation lists the Flex as using the same ST33K1M5C chip, though a Flex-specific certification record was not independently located during the research behind this article.

What certification does not mean:

• It does not cover every future condition: temperature, voltage, and manufacturing variation can measurably affect a chip's random output, a known category of risk across the semiconductor industry, and one the standards are written to account for rather than ignore.

• It does not rule out future software mistakes: certification evaluates hardware and firmware at a point in time. It does not re-run itself when software changes afterward, which is exactly the category of failure the Coldcard case demonstrated.

• It does not claim perfection: the AIS 20/31 standard itself states, in its own published text, "an ideal random number generator is a fiction." Certification is bounded, testable compliance, not an unattainable guarantee.

Certification answers a narrower question than it is often assumed to answer: did a system meet a defined standard under defined conditions? It does not answer whether a mistake can ever happen again. Confusing the two produces the least accurate claims on both sides of the hardware wallet debate.

Three Claims, Not One: What Ledger's Audits Cover

Ledger's statements about outside review are sometimes flattened into one phrase, "independently audited," when they describe three separate things with three different levels of evidentiary strength:

• Donjon, Ledger's internal security team: publicly named, publishing numbered and dated security bulletins, and running a public bug bounty program. Its role is finding weaknesses in Ledger's own hardware and firmware before outside attackers do, through work such as fault injection testing and side-channel analysis.

• An unnamed outside laboratory: Ledger states a third-party security lab audits its full operating system, including closed components, before releases. The lab's identity is not publicly disclosed, which limits how far the claim can be independently checked.

• Certification catalogue records: specific, named entries in public certification databases, some independently confirmed during this research and some not located at the cited reference at the time of writing.

These are three different levels of evidence, not one interchangeable claim, even where each individual claim may be entirely true.

A Historical Reminder: Every Security Model Has Failure Modes

The Secure Element approach has its own historical stress test, from 2018. It is included here for the same reason the Coldcard case is, not as criticism of either company:

• The finding: an independent researcher demonstrated an earlier Ledger generation could, given physical access before initial setup, have its onboarding manipulated so a supposedly random value was replaced with one the attacker already knew, while suppressing the tamper warning.

• Ledger's response: the company confirmed the underlying finding and stated the attack could not extract secrets already inside the Secure Element.

• The dispute: the researcher publicly contested Ledger's characterization at the time, so the "could not extract secrets" position should be read as Ledger's stated view, not settled fact.

• The lesson: read side by side with the Coldcard case, the finding shows the same principle from a second architecture. A security boundary is only as strong as the complete path from the chip to the person using the device.

Closed Source Is Common Practice, Not Just Ledger

Ledger describes its overall software stack as roughly 95 percent open source, with the remainder, mainly the code speaking directly to the Secure Element, kept closed.

Keeping the most sensitive part of a security system closed is standard practice well beyond hardware wallets:

• Payment cards: run on closed, certified secure element chips.

• Biometric passports: rely on the same smartcard-derived chip technology.

• Smartphones: the secure enclave holding fingerprints and payment keys is closed on every major phone platform.

The pattern is the same everywhere: concentrate the most sensitive operations inside a single hardened, professionally tested chip, and accept the loss of public inspection over the small piece of code touching it directly.

Open Source vs Closed Source: Two Different Bets

Framed honestly, there is no winning side here, only two different answers to the same unavoidable question: where should trust be placed?

The Coldcard bet, transparency:

• What it offers: anyone with the right background can read the code, and a holder willing to learn the process can generate a seed entirely from physical dice, removing reliance on the device's generator altogether.

• What it costs: more surface area for a mistake to hide in, review by humans who can miss things, and now a real multi-year example of exactly such a miss.

• One precision: Coldcard's firmware has, since 2021, carried a license permitting inspection and modification but restricting commercial reuse. "Source available, with a licensing restriction" is the accurate label. "Fully open source" slightly overstates it.

The Ledger bet, the hardened boundary:

• What it offers: a certified, professionally tested Secure Element, a smaller and more contained surface for the class of mistake the Coldcard case demonstrated, and a documented internal security research program.

• What it costs: the closed portion cannot be personally verified. Trust sits with the certification body, Ledger's stated practices, and Ledger's track record when problems are found.

Neither bet removes trust from the equation. Each places it somewhere specific: toward the community and the math on one side, toward the chip and the certifying laboratory on the other. Asking which trade-off fits a specific holder's situation is more useful than asking which company is safer in the abstract.

[Related reading: Ledger vs. Trezor vs. Coldcard, a hardware wallet comparison]

Six Ways to Strengthen Any Hardware Wallet Setup

A hardware wallet is one part of a security setup, not the entire setup. A few concrete steps reduce exposure to this category of risk, regardless of brand:

• Buy only from official sources: devices from unofficial resellers carry a separate risk of physical tampering before a seed is ever generated.

• Verify authenticity on first use: using whichever manufacturer-provided check exists for the specific model.

• Keep firmware current: fixes for exactly this category of defect ship through firmware updates, and an out-of-date device cannot benefit from a fix it has not installed.

• Consider a passphrase or dice-based seed: for anyone wanting to remove reliance on a single device's random number generator entirely.

• Consider multisig for larger holdings: spreading trust across multiple devices or manufacturers rather than concentrating it in one generator or one supply chain.

• Understand the backup process fully: a correctly generated seed with a poor backup carries its own, entirely separate risk.

[Related reading: Bitcoin self-custody, a beginner's guide]

The Real Question: Where Does Trust Sit

Hardware wallet security is not one property a device either has or lacks. It is a chain: how a chip generates randomness, how the surrounding code is written and reviewed, what an outside party can verify, what has been formally certified, and how carefully the holder protects the result. The strength of the chain is set by its weakest connection.

Bitcoin removes the need for a bank or custodian to hold funds on someone's behalf. It does not remove engineering trust from the tools built around ownership. Holding a private key directly makes the holder the final security layer, which makes understanding the tools protecting the key part of owning Bitcoin itself.

For the holders affected by the Coldcard incident, none of the above was theoretical. Real Bitcoin was lost because a tool built specifically to protect it carried a flaw undetected for years. That deserves acknowledgment before any lesson gets drawn. The lesson itself is narrower than the headlines suggested. The Bitcoin protocol was never touched, hardware wallets as a category did not fail, and neither open nor closed code was proven wrong as an approach. A specific tool failed at one specific layer, and perhaps the uncomfortable reality of being early is exactly this: every new monetary technology has to survive the mistakes, attacks, and blind spots which appear as more people come to depend on it.

The goal is not finding a system with zero trust. Such a system does not exist. The goal is knowing where trust sits, what evidence supports it, and whether the trade-off matches the Bitcoin being protected. Readers who want deeper structural breakdowns of self-custody trade-offs can find further analysis across Coinjuice's research library and PRO membership.