Skip to Content
DocumentationFirmwareFirmware 7.14.2

Firmware 7.14.2

GitHub status: Latest release: v7.14.2 (2026-10-16).

7.14.2 is a security release. It adds no features, on purpose. It makes one guarantee stronger: what your KeepKey asks you to approve is exactly what it signs. If the device can’t show a detail accurately, it now refuses instead of approximating. It also hardens how the firmware is built around the random-number generator, following a responsibly disclosed report.

Should I update?

If you transact actively on Solana, EVM chains, or THORChain and in-app swaps, updating is recommended. Otherwise it’s not necessary. Update from KeepKey Desktop: Firmware Updates.

Is an older version, such as 7.14.1, still safe? None of these fixes involves your private keys or recovery phrase leaving the device, and none changes how your recovery phrase was created. What 7.14.2 fixes is how faithfully the device screen describes certain Solana, EVM and THORChain transactions. On earlier versions, in the cases listed below, the screen could show less than, or something different from, what was being signed.

Bitcoin-only devices: 7.14.3 (release status) is built from 7.14.2 and keeps the changes that apply to Bitcoin.

What changed

ChangeWhat it means for youWho it affects
Accurate or refusedSigned messages, memos, contract data (calldata), amounts, fees, authorities and network assets are shown accurately, or the device refuses to sign.Anyone signing more than a simple send
Solana: nothing signed unseenSolana instructions are decoded only when every byte is accounted for. Before, extra bytes appended to a recognised instruction were signed without being shown (and without triggering the blind-signing warning), CreateAccount showed only the amount, not the space and owner it signed, and stake Authorize could read past its field. Anything the device can’t fully read is now treated as unverified. Token-2022 operations are never shown as verified, because their fees and hooks aren’t displayed; signing them needs Advanced Mode.Solana users
Token names on other EVM chainsA token on a chain with a high chain ID (above 255) could pick up an Ethereum mainnet token’s name. Lookups now use the full chain ID, so a chain such as 257 can’t borrow chain 1’s names.EVM users on chains other than Ethereum mainnet
Native-asset placeholderThe 0xeeee…eeee placeholder only means a known asset on Ethereum mainnet. On other chains, transfers and approvals using it show Unknown token value instead of borrowing Ether’s details.EVM users on other chains
EIP-1559 feesThe maximum fee and the priority fee are shown correctly, including on chains whose ID needs more than one byte.EVM users
THORChain swapsTHORChain’s native-asset placeholder now resolves to the signing chain’s own asset, not Ether.THORChain swap users
Blind signingSecurity-sensitive blind-signing paths require Advanced Mode.dApp and contract users
Cancel, clear, recovery and wipeThese stop any work in progress and clear secrets the device was holding in memory for it.Everyone
Invalid valuesOversized, empty, missing or invalid values fail before you’re asked to approve.Everyone

Each fix has a regression test, including checks that two addresses with the same beginning but a different ending are shown differently.

Random-number hardening (responsibly disclosed)

On 7 August 2026 an independent security researcher privately reported a fragile build configuration in KeepKey’s random-number setup. It belongs to the same bug class as the COLDCARD seed bug : a build setting was defined as 0 but checked only for whether it was defined.

It was not exploitable in shipped firmware. Production builds used the device’s hardware random-number generator. The protection was incidental, though: an innocent-looking cleanup could have silently swapped it for a predictable test generator. The researcher reported it privately so it could be fixed before that ever happened. We confirmed it on 10 August.

What 7.14.2 changes:

  • The build fails if the setting is removed. Production firmware can no longer compile the predictable test generator that a missing RAND_PLATFORM_INDEPENDENT setting would select. Before, only an incidental link error stood in the way.
  • Device firmware refuses the emulator setting. A build for the device itself now fails if EMULATOR is defined at all, so a setting of EMULATOR=0 can’t silently switch it to a computer’s random source.
  • The emulator uses a secure random source. The software emulator now reads the operating system’s secure generator instead of an unseeded one.

Related work in later releases: 7.14.3 (Bitcoin-only) tests the random-number generator before every new seed (the NIST SP 800-90B repetition-count and adaptive-proportion tests) and lets you add your own dice rolls. That test is also in 7.16 for multi-chain.

Thanks to @BitcoinQuentin for the report, and for reporting it responsibly.

Verify the release

The release on GitHub is signed by three of the five firmware keys, and lists the exact source commit and the expected firmware hash. To rebuild it yourself and compare, follow the steps in the GitHub release  and the verification guide .

Last updated on
Release Status & ClearSignSupported Chains