Security

Every hardware wallet rests on a supply chain you mostly can’t see — the silicon, the firmware burned into it, and every hand the device passes through before it reaches yours. Most wallets ask you to trust that chain. KeepKey is built so you can verify it instead.

That starts with the hardware. KeepKey runs on a commodity STMicroelectronics STM32 microcontroller — a general-purpose chip with a public datasheet and no NDA, sold by ordinary distributors worldwide. There is no proprietary, single-vendor secure element sitting at the center of the design as an un-inspectable chokepoint. The firmware is open source under LGPLv3 (GitHub ), the schematics are public, and the design is open enough to be built DIY from public sources. Nothing about the device depends on one vendor’s sealed black box — and that openness is a security property, not just a slogan:

• No single-vendor chokepoint. A closed secure-element wallet concentrates its deepest trust in one proprietary part you can’t audit, from a supplier you can’t substitute. KeepKey’s components are commodity and multi-source, its firmware is public, and its build is reproducible — and even DIY-able — by anyone who wants to check the work.
• The device proves itself. On first boot, KeepKey verifies that its firmware and bootloader are genuine and signed by a KeepKey key, and you can independently check any release’s SHA-256 against the GitHub releases page . You don’t have to trust the box — you can check it.
• Open is what gets things fixed. Every issue ever disclosed against KeepKey was hardened in public, on GitHub, where anyone can read the commit — often within days of disclosure. The full record is below; the latest firmware is v7.14.1.

We hold the boundary honestly: openness is not immunity. A determined attacker who intercepts a device before it reaches you — the classic evil-maid or hardware-implant attack — is a real risk for every hardware wallet, KeepKey included (see the supply-chain row in the history). What openness changes is your ability to do something about it: buy direct, let the device verify genuine signed firmware and bootloader on first boot, and inspect anything you doubt. The claim we make is the narrow, sturdy one — a supply chain you can inspect beats one you’re told to trust.

We present everything below the way it should be presented — as reports from security researchers that KeepKey reviewed and fixed. Where something is a researcher’s assessment rather than an established fact, it’s attributed that way. Nothing here is hidden, and nothing is dramatized.

Has KeepKey ever been “hacked”?

The short answer: no remote attacker has ever been able to take funds from an up-to-date KeepKey that you physically control. The findings that occasionally draw headlines fall into two groups, and the difference between them is the whole point of a hardware wallet:

• Findings that require physically holding the device. Researchers (Kraken Security Labs in 2019, the wallet.fail team in 2018) have shown that someone in possession of your unlocked device, with specialized equipment and time, can extract the encrypted seed and then brute-force a weak PIN. This is a known tradeoff of KeepKey’s general-purpose microcontroller design (see Secure Element below), not a remote threat — and a BIP-39 passphrase fully defeats it, because the passphrase is never stored on the device.
• USB-reachable firmware bugs — all fixed. A small number of firmware bugs (notably CVE-2019-18671 and CVE-2021-31616) were reachable over USB, including from a website using WebUSB. Every one was addressed in firmware, several within days of disclosure. Keeping firmware current closes them.

Most of these were found through responsible disclosure by independent researchers — Christian Reitter (inhq.net), Ledger Donjon, Kraken Security Labs, and the wallet.fail team — and every fix is a public commit you can read. That open report-and-fix cycle is the security model working as intended.

One organizational myth, while we’re here: ShapeShift did not “shut down.” In July 2021 it decentralized into a DAO; KeepKey spun out as an independent open-source hardware wallet and is still maintained today (latest firmware 7.14.1). Because KeepKey is non-custodial, your funds live in your BIP-39 seed regardless of any company’s status.

Does KeepKey have a Secure Element?

No — by design. KeepKey is built on a general-purpose STMicroelectronics STM32F205 microcontroller (ARM Cortex-M3), the same chip family as the Trezor One, with no dedicated secure element. This is a deliberate architectural choice, and it cuts both ways.

Spec note: the production KeepKey uses the STM32F205 (Cortex-M3). The “STM32F405 / Cortex-M4” you may see referenced is the recommended chip for the third-party DIY build, not the shipped hardware.

What “no secure element” actually means

• What it does NOT mean: it does not mean your funds are exposed to remote attackers, websites, or malware. A secure element primarily defends against an attacker who is physically holding your device and using lab equipment.
• What it DOES mean: an attacker with physical possession, the right gear, and time can perform fault-injection / glitching attacks against the commodity MCU to extract the encrypted seed (then brute-force a weak PIN offline). On this hardware this class of attack is not fully fixable in firmware — closing it completely would require a hardware redesign with a secure element. Ledger Donjon described the seed-extraction class on this chip as essentially unfixable in firmware, in contrast to the PIN side-channel, which was fixed.

The compensating controls

KeepKey trades the secure element for auditability and transparency, and pairs that with defenses you control:

• Open source + public build. Firmware is LGPLv3, the chip has a public datasheet (no NDA), and the schematics and build are public. Anyone can read exactly what the device does — including the researchers who found and fixed the bugs above. You can verify a release’s SHA-256 hash against the GitHub releases page  before flashing.
• Signed firmware. The bootloader refuses to install anything not signed by a KeepKey signing key, so a malicious desktop app or a download from the wrong place still can’t push altered firmware onto the device.
• On-device, full-address verification. Every address and transaction is shown on the device’s own screen. A compromised computer can lie to you on the host; it cannot change what the device displays. Always read the entire address on the device — see Verifying Transactions.
• BIP-39 passphrase — against physical extraction, it beats a secure element. This is the strongest physical-attack defense KeepKey offers, and the reason is structural: a secure element only makes the seed harder to extract, while a passphrase makes an extracted seed useless. The passphrase (“25th word”) is combined with your seed to derive a separate hidden wallet and is never stored on the device — so there is nothing on the chip for a glitching or decapping attack to recover. Even a flawless physical extraction yields an empty wallet. That is a categorically stronger guarantee than tamper-resistant storage, which every secure element — even the open TROPIC01 (below) — has eventually fallen to in the lab. KeepKey fully supports passphrases as named hidden wallets (Passphrase (Hidden Wallets)); the discipline it asks is to pick a strong passphrase and back it up — a weak one can still be brute-forced offline once a seed is extracted, and a passphrase can’t protect you from an implant that captures it as you type. Kraken, Trezor/SatoshiLabs, and Ledger all explicitly recommend a strong passphrase as the mitigation for the glitching class of attack.

Our security philosophy: open over secret

Everything on this page reflects one conviction: the durable path to security is openness, not secrecy. We harden every issue that’s disclosed, fix the ones we find ourselves, and publish the result — because security you can verify is worth more than security you’re asked to take on faith.

That places us on one side of a long-running debate in hardware wallets. The other side holds that a dedicated secure element (SE) is essential, and that a wallet built on a general-purpose microcontroller is “fundamentally flawed.” We don’t dispute that a secure element adds real resistance to physical attacks. We disagree about what it costs you — and recent events have made the disagreement concrete rather than theoretical.

A closed secure element asks you to trust firmware you can’t read. Most secure elements are proprietary and NDA-gated; their security rests on firmware no independent party can inspect. “The secure element protects your keys” reduces, in practice, to “trust the vendor not to ship firmware that extracts them.” Ledger said exactly that in May 2023 while defending its Ledger Recover service: “Technically speaking it is and always has been possible to write firmware that facilitates key extraction. You have always trusted Ledger not to deploy such firmware whether you knew it or not.” (CoinDesk, 2023 ) The boundary was never the silicon. It was the vendor’s unauditable firmware.

And the silicon itself is not magic. The strongest case for the secure-element camp is the open secure element — Tropic Square’s TROPIC01, whose design and firmware are genuinely public. In late January 2026, Ledger’s own research lab (Donjon) used laser fault injection to bypass its signature verification and extract a subset of the chip’s protected secrets; Tropic Square then found a further path to a PIN-related secret (publicly disclosed June 2026 — Trezor’s write-up , Ledger Donjon ). Funds in the Trezor Safe 7 stayed safe — that chip is one of several layers and doesn’t hold the keys or backup — and the attack required desoldering and decapping the chip under lab equipment. But the lesson stands: even the best, most-open secure element falls to a determined attacker holding the device. No silicon repeals the basic rule of hardware wallets — physical attacks require physical possession. Tellingly, it was TROPIC01’s openness that let the flaw be found, disclosed, and fixed in the next batch of chips.

The industry is converging on the premise we started from. Even Trezor — which now ships secure elements — refuses NDA black-box parts, and put it plainly in that same disclosure: “We don’t believe obscurity = security,” adding that closed, NDA-protected secure elements are “hiding risks behind black-box designs and forcing users to trust what they can’t verify.” That is our argument, made by a company that chose to add a secure element. The thing worth keeping was never the secrecy — it was the auditability.

So we bet on the open path end to end:

• Proven, fully documented hardware. A commodity STM32 microcontroller with a public datasheet and no NDA — decades of open scrutiny, not a sealed box.
• Open firmware. LGPLv3, every line and every fix public and auditable by anyone, including the researchers listed below.
• An open standard for the hard part — and a stronger one. The physical-attack gap a secure element is sold to close, we close with the BIP-39 passphrase — an open, standardized, math-based defense that is never stored on the device and depends on no vendor’s silicon. A secure element bets that the seed can’t be pulled off the chip; a passphrase makes that bet irrelevant, because the secret that unlocks your funds was never on the chip to begin with. Extract the silicon and you still don’t have passphrase-protected funds.

We hold this honestly: a no-secure-element design is not invulnerable, and we have never claimed it is — the vulnerability history below is the record of exactly how we handle that. Our claim is narrower and sturdier: a system you can fully inspect is more trustworthy over the long run than one whose security you must take on faith. The recent history of secure elements has, if anything, made that case for us.

Vulnerability history

This is the full public record, and it’s also the evidence for the claim at the top of this page: nearly every row reads Fixed in a named firmware version. The remainder are either vendor-disputed as insignificant, an inherent design tradeoff that a passphrase mitigates, or a supply-chain class issue that applies to hardware wallets generally — not unpatched holes.

Every row traces to an authoritative source (NVD/MITRE, the vendor advisory, the fix commit, or the original researcher write-up) and was independently cross-verified, except where explicitly flagged single-source — confirm. CVE IDs and fix versions are exact; where a second source corrected a field, the corrected value is used.

How to read “Status”:

• Fixed — patched in the named firmware version. Stay current and you are not exposed.
• Disputed — the vendor publicly assessed the risk as insignificant; never patched. Lowest-severity item here (CVSS 2.4).
• By-design tradeoff — a consequence of the no-secure-element architecture, not a software defect. Cannot be fully fixed in firmware; mitigated by a BIP-39 passphrase.
• Supply-chain class issue — applies to hardware wallets generally; mitigated operationally (buy direct, verify genuineness), not by a firmware patch.

How to protect yourself

Most of the attacks above require someone to physically hold your device. The rest are fixed in current firmware. So the practical defense is straightforward:

1. Keep firmware current. Every “Fixed” row above is closed by updating. The desktop app checks automatically — see Firmware Updates. This alone removes the entire remote/USB attack surface.
2. Buy direct, and let the device prove itself. This is your defense against the supply-chain class of attack the page opens with. Buy from official sources, and on first boot let the device verify that its firmware and bootloader are genuine and signed — the verification a closed wallet can’t offer you. If anything looks off, don’t fund it.
3. Keep the device physically secure. The unfixable attacks need physical possession. Treat the device like cash or a key: don’t leave it where strangers can reach it, and be cautious about leaving it unattended while unlocked.
4. Use a PIN — and a passphrase for high-value storage. A PIN slows down a physical attacker. A BIP-39 passphrase is the real mitigation for the glitching class: it’s never stored on the device, so physically extracting the seed does not reveal passphrase-protected funds. Be disciplined — write the passphrase down and test recovery before funding the hidden wallet. See Passphrase.
5. Verify firmware before flashing. Compare the release’s SHA-256 against the GitHub releases page . The desktop app does this automatically, and the device’s signed-firmware bootloader is a second layer that rejects unsigned firmware.
6. Verify every address on the device screen. Read the whole address, not just the first and last few characters. Your computer can be lying; the device screen is the source of truth. See Verifying Transactions.