Treat a hardware-wallet update as a provenance decision

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

“Update available” is not enough information to authorize new code on a signing device. The decision has at least four parts: whether the notice came through an authentic channel, whether the release applies to the exact hardware, whether its security or compatibility changes justify action now, and whether recovery remains possible if installation fails. Updating blindly and never updating are both policies that avoid the actual evidence.

Establish the device and release channel

Record the device model, hardware revision, installed firmware, companion-app version and whether the device reports an authenticity or secure-boot warning. Navigate to the manufacturer's site from a saved, previously verified address—not an email or advertisement—and find the release notes for that model. Distinguish standard, beta, edge and developer channels. COLDCARD's upgrade guide, for example, warns that model scope matters and describes its Edge firmware as a less-qualified preview channel.

Read the notes for security fixes, migration requirements, removed features, file-format changes and minimum companion-software versions. A release that fixes an exploitable signing flaw has a different urgency from one that adds an optional asset. If the vendor gives no usable changelog or model mapping, that absence is part of the risk decision.

Verify the recovery path before the binary

Locate the offline wallet backup and run the manufacturer's non-destructive backup check if available. Trezor's firmware-update guide warns that a malfunction can erase device memory and points users to dry-run recovery. Do not type the seed into the computer as preparation. The separate recovery rehearsal explains how to prove the backup without creating a digital copy.

Also export or verify non-secret wallet context: fingerprints, descriptors, account types and several known receive addresses. A valid seed restored under the wrong passphrase or derivation can create a different, empty-looking wallet.

Check provenance at two levels

First verify transport: download only from the official release location, calculate the file hash and compare it with the signed manifest. Then verify the manifest signature against a signing-key fingerprint obtained through a channel you already trust. COLDCARD documents this exact hash-plus-OpenPGP sequence. A matching hash from the same compromised web page proves only that two compromised files agree; the signature and trusted fingerprint are the independent link.

Second verify device enforcement. Some devices validate vendor signatures or firmware measurements during boot. Trezor's firmware hash-check documentation describes automated measurement and warnings for mismatches. That is vendor-specific evidence, not a guarantee that every bootloader, supply chain or companion application is uncompromised.

Control the update window

1. Use stable power and the documented cable, card or transport.
2. Close unrelated applications and confirm the exact file and model again.
3. Do not update immediately before a time-critical payment.
4. Photograph no seeds or screens containing secrets; record only versions and public hashes.
5. After reboot, inspect authenticity indicators and confirm the installed version.
6. Verify several receive addresses on the device before signing any material transaction.

If the device shows an unexpected wipe, unsigned-firmware warning, changed fingerprint or address mismatch, stop. Recover only through the official procedure on a known device; do not accept private-message support or seed-entry websites.

Document the decision, including deferral

Record the notice source, release channel, model applicability, security relevance, signature/hash result, backup-check date, installation result and post-update address check. If deferring, state the reason and next review trigger. Deferral may be rational when a release is preview-only or breaks a required workflow, but it accumulates exposure when supported security fixes are left unapplied.

This checklist cannot audit firmware source or prove the hardware is free of hidden faults. It creates a traceable decision boundary. Pair it with the signing-interface compromise case: cryptography does not help when an operator approves data they did not independently verify.