Skip to Content

Security

KeepKey uses a separate device for key operations and transaction review. Its firmware source is public, allowing researchers and users to inspect the implementation. These controls reduce particular risks; they do not make a device or transaction immune to attack.

Has KeepKey ever been “hacked”?

Researchers have reported physical-access and software vulnerabilities over KeepKey’s history. Evaluate the affected version, prerequisites, mitigation and release evidence for each finding. Do not assume that possession of the device eliminates every remote threat or that a current version proves the absence of unknown vulnerabilities.

See the vulnerability history references and firmware release record .

Does KeepKey have a Secure Element?

KeepKey’s production design uses an STM32F205 general-purpose microcontroller rather than a dedicated secure element. The tradeoff includes physical-access risks. Kraken Security Labs’ published research  describes extracting encrypted seed material using voltage glitching and recommends physical protection and a strong passphrase.

A passphrase protects a different boundary from the PIN. It derives a separate wallet; its usefulness against extracted seed material depends on its strength and secrecy. It does not protect against entering it into a compromised environment or losing the passphrase yourself. See Hidden Wallets.

Our security philosophy: open over secret

Public source, reproducible build instructions, device review and independent research make security claims easier to investigate. Openness does not by itself prove implementation correctness or establish superiority over another architecture.

Our documentation distinguishes source review, automated tests, emulator screenshots, physical-device testing and published signed artifacts. The Test Atlas explains how to read one candidate’s evidence without confusing skipped tests or historical prose with current acceptance.

Vulnerability history

Start with primary reports and the corresponding fixes:

This list is not an exhaustive vulnerability inventory. A historical fix addresses the named issue in its documented scope; it does not remove the entire class of USB, software, physical-access or supply-chain attacks. Exact CVE/version claims require the original advisory and release proof.

How to protect yourself

  1. Install official software and follow firmware update instructions. Read device warnings and identify the release before accepting an update.
  2. Keep the hardware and written backup physically secure. Never share recovery words with support or enter them into an emulator.
  3. Verify your backup without wiping a funded device.
  4. Read the complete destination, amount, network and permission on the device. Cancel when the request cannot be understood.
  5. Understand PINs and passphrases, including their recovery consequences.
  6. Treat provider context and KeepKey-approved ClearSign as distinct authorities. An approved description does not guarantee a safe contract or outcome.

For a problem with your device, use Troubleshooting. To report a suspected security issue, use the reporting instructions in the firmware repository’s security area .

Last updated on