Edouard.ai
Back to blogSécurité Technique

Verify Your Hardware Wallet Firmware: A Practical Guide

February 3, 2026
14 min read
155 views

Verify Your Hardware Wallet Firmware: A Practical Guide


Table of Contents

  1. Introduction
  2. Why Verify Your Firmware?
  3. Trezor Firmware Verification
  4. Coldcard Firmware Verification
  5. The Ledger Case: Limitations of Closed Source
  6. Firmware Update Best Practices
  7. Verification Comparison Table
  8. FAQ
  9. Resources and Tools
  10. Conclusion
  11. Internal Links
  12. Sources

Suggested URL: /security/verify-hardware-wallet-firmware-practical-guide

Category: Technical Security Tutorials

Summary: Complete tutorial for independently verifying the firmware of your hardware wallet (Trezor, Coldcard, Ledger). Protect yourself against supply chain attacks and compromised updates.


Introduction

Protect yourself from supply chain attacks and compromised firmware

Your hardware wallet is the guardian of your private keys. But what happens if the device itself has been compromised? Malicious firmware could record your seed phrase, alter destination addresses, or exfiltrate your keys without your knowledge.

This threat is not theoretical. Supply chain attacks -- where a device is intercepted and modified before reaching the user -- are well documented. Compromised updates could theoretically be distributed by an attacker who has infiltrated a manufacturer's infrastructure.

The solution? Independently verify that the firmware running on your device matches the public source code exactly. This tutorial guides you step by step through this verification process for the major hardware wallets on the market.


1. Why Verify Your Firmware?

Understand the real threats that target your device

1.1 The risk of supply chain attacks

A supply chain attack targets the distribution chain rather than the end user:

Vector Description Example
Postal interception The device is modified during transit Firmware replaced before delivery
Malicious reseller Purchase through an unofficial channel Device pre-configured with a seed known to the attacker
Manufacturer compromise Attack on the manufacturer's infrastructure Official firmware itself compromised

Documented real-world cases:

  • In 2020, counterfeit Ledger devices were sent to customers after their database was leaked
  • Modified Trezor units with additional chips were identified on the secondary market

1.2 The risk of compromised updates

Every firmware update is an opportunity for an attacker:

  • Infrastructure attack: Compromise of distribution servers
  • MITM attack: Interception of the connection during download
  • Social engineering: Fake urgent update distributed via phishing

1.3 Open source vs closed source

The ability to verify firmware depends on its open source status:

Device Firmware Verification possible
Trezor 100% open source ✅ Complete
Coldcard Open source (application) ✅ Complete
SeedSigner 100% open source ✅ Complete
BitBox02 Open source ✅ Complete
Ledger Closed source (Secure Element) ⚠️ Partial

Key point: With open source firmware, you can compile the code yourself and compare the result with what is installed on the device. With closed source, you must trust the manufacturer.


2. Trezor Firmware Verification

Compile the source code yourself to guarantee its authenticity

The Trezor is entirely open source, which allows for complete verification.

2.1 Prerequisites

  • A computer running Linux, macOS, or Windows with WSL
  • Git installed
  • Docker (for reproducible compilation)
  • Your Trezor connected

2.2 Step 1: Download the source code

# Clone the official repository
git clone https://github.com/trezor/trezor-firmware.git
cd trezor-firmware

# Check out the version matching your firmware
# Check the version on your Trezor: Settings > Device > Firmware Version
git checkout core/v2.6.4  # Replace with your version

2.3 Step 2: Verify GPG signatures

Official releases are signed by Trezor developers.

# Import the developers' public keys
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys \
    86E6792FC27BFD478860C11091F3B339B9A02A3D \
    F2BBD5F2B8C6B8B8C6B8B8C6B8B8C6B8B8C6B8B8  # Example - verify on trezor.io

# Verify the tag signature
git verify-tag core/v2.6.4

The result must display "Good signature from" followed by the name of a known Trezor developer.

2.4 Step 3: Compile the firmware (Docker)

Trezor uses reproducible builds via Docker:

# Build the Docker environment
docker build -t trezor-build .

# Run the compilation
docker run -it --rm -v $(pwd):/src trezor-build \
    bash -c "cd /src && poetry install && poetry run make -C core build_firmware"

The compilation produces a binary file in core/build/firmware/firmware.bin.

2.5 Step 4: Compare with the installed firmware

Get the hash of the installed firmware:

Use the trezorctl tool:

# Install trezorctl
pip install trezor

# Get firmware information
trezorctl get-features

Calculate the hash of the compiled firmware:

sha256sum core/build/firmware/firmware.bin

Compare the two hashes:

If the hashes match, your firmware is identical to the verified source code. If they differ, something is wrong -- do not continue using the device.

2.6 Command recap

# 1. Clone
git clone https://github.com/trezor/trezor-firmware.git && cd trezor-firmware

# 2. Checkout version
git checkout core/v2.X.X

# 3. Verify signature
git verify-tag core/v2.X.X

# 4. Compile
docker build -t trezor-build . && \
docker run -it --rm -v $(pwd):/src trezor-build \
    bash -c "cd /src && poetry install && poetry run make -C core build_firmware"

# 5. Hash
sha256sum core/build/firmware/firmware.bin

3. Coldcard Firmware Verification

Verify GPG signatures and hashes to validate your firmware

The Coldcard uses a different approach: verification is performed via SD card and command-line tools.

3.1 Prerequisites

  • Python 3 installed
  • The ckcc-protocol tool from Coinkite
  • Firmware downloaded from coldcard.com

3.2 Step 1: Download the official firmware

Go to coldcard.com/docs/upgrade and download:

  • The firmware file (.dfu)
  • The signature file (.txt or .asc)

3.3 Step 2: Verify the signature

Coinkite signs each firmware with their GPG key.

# Import the Coinkite public key
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys \
    A3A31BAD5A2A5B10D6B8E8F5E6C2E6D9F8A8B0C0  # Verify the exact ID on coldcard.com

# Verify the signature
gpg --verify firmware-signature.txt firmware-X.X.X.dfu

3.4 Step 3: Use verify.py

Coinkite provides a Python tool to verify the firmware:

# Install the tool
pip install ckcc-protocol

# Verify the firmware
ckcc verify firmware-X.X.X.dfu

3.5 Step 4: Verification via SD card

The simplest method for non-technical users:

  1. Copy the .dfu file to a microSD card
  2. Insert the card into the Coldcard
  3. Navigate to: Advanced > Upgrade > From SD Card
  4. The Coldcard displays the file hash
  5. Compare with the hash published on coldcard.com

3.6 Verifying the currently installed firmware

On the Coldcard, navigate to:

Advanced > View Identity > My Fingerprint

This fingerprint must match the one documented for your firmware version.

3.7 Compile from source (advanced)

For technical users:

# Clone the repository
git clone https://github.com/Coldcard/firmware.git
cd firmware

# Verify the tag
git checkout v5.X.X
git verify-tag v5.X.X

# Compile (requires the ARM environment)
make setup
make all

4. The Ledger Case: Limitations of Closed Source

Discover what you CANNOT verify with a proprietary Secure Element

4.1 Ledger architecture

The Ledger uses a two-part architecture:

Component Description Open Source
BOLOS Secure Element operating system ❌ No
Applications Bitcoin, Ethereum apps, etc. ✅ Yes
Ledger Live Desktop/mobile software ✅ Yes

The core of the problem: the Secure Element runs proprietary code that no one can audit.

4.2 What can be verified

Applications (partially):

  • The application code (Bitcoin app, etc.) is on GitHub
  • You can compile and compare the hashes
  • But loading onto the device goes through BOLOS (closed source)

Ledger Live:

  • The code is open source on GitHub
  • You can compile your own version
  • Verifies application signatures

4.3 What cannot be verified

  • The BOLOS operating system
  • The actual behavior of the Secure Element
  • The absence of hardware backdoors

4.4 Why this is problematic

Without access to the Secure Element code, you must trust Ledger regarding:

  • The absence of voluntary or coerced backdoors (government pressure)
  • Code quality and the absence of vulnerabilities
  • The fact that generated keys are truly random

4.5 Verifications still possible

Device attestation:

Ledger Live verifies that the device is authentic via a certificate signed by Ledger:

  1. Connect your Ledger to Ledger Live
  2. Access the device settings
  3. Click "Check authenticity"

This verification confirms that the device comes from the Ledger factory, but not that the firmware is sound.

Verify applications:

# Clone the application repository
git clone https://github.com/LedgerHQ/app-bitcoin.git
cd app-bitcoin

# Compile (requires the Ledger SDK)
make

# Compare the hash of the compiled application
# with the one installed on the device

4.6 Recommendation

For users who prioritize verifiability, prefer:

  • Coldcard or Trezor as primary signers
  • The Ledger can serve as a backup key in a multisig setup
  • Avoid relying solely on a Ledger for significant amounts

5. Firmware Update Best Practices

Adopt a cautious approach to new firmware versions

5.1 Never update automatically

Practice Recommendation
Automatic updates ❌ Disable
Update notifications ✅ Enable
Delay before updating ✅ Wait 1-2 weeks

Why wait?

  • The community can detect issues
  • Vulnerabilities in new versions can be discovered
  • In case of manufacturer compromise, time allows for detection

5.2 Pre-update checklist

Before applying any firmware update:

  • Verify the official announcement (website, Twitter, GitHub)
  • Search for discussions on Reddit, Twitter, forums
  • Wait 1-2 weeks after release
  • Verify the GPG signature of the firmware
  • Make sure you have access to your seed phrase (in case of problems)
  • Test on a secondary device if possible

5.3 When in doubt

If something seems suspicious:

  1. Do not update -- Wait for more information
  2. Reach out to the community -- Reddit, Twitter, dedicated forums
  3. Check official sources -- Website, GitHub, verified social accounts
  4. Consider a new device -- If compromise is suspected

5.4 Secure update procedure

For Trezor:

  1. Download the firmware from GitHub (not directly from Trezor Suite)
  2. Verify the GPG signatures
  3. Use trezorctl to flash: trezorctl firmware-update -f firmware.bin

For Coldcard:

  1. Download from coldcard.com
  2. Verify the signatures
  3. Transfer via SD card
  4. Apply from the menu: Advanced > Upgrade

For Ledger:

  1. Verify official announcements
  2. Wait a few days
  3. Update via Ledger Live
  4. Verify attestation after updating

6. Verification Comparison Table

Evaluate at a glance the verification capabilities per device

Aspect Trezor Coldcard Ledger
Source code 100% open Mostly open Apps open, OS closed
Reproducible build ✅ Yes (Docker) ✅ Yes ⚠️ Partial (apps)
GPG signature ✅ Yes ✅ Yes ✅ Yes
Hash verification ✅ Complete ✅ Complete ⚠️ Partial
Device attestation ❌ No ⚠️ Basic ✅ Yes
Auditable Secure Element N/A ⚠️ Partial ❌ No

FAQ

Q1: Is firmware verification really necessary for an individual?

For the majority of users purchasing directly from the manufacturer, the risk is low. However, verification becomes crucial if you:

  • Bought second-hand or through a third-party reseller
  • Hold significant amounts (>10,000 EUR)
  • Are a potential target (public figure, crypto personality)
  • Have professional security requirements

Q2: What should I do if verification fails?

  1. Do not transfer funds to this device
  2. Do not reveal any seed phrase to the device
  3. Contact the manufacturer with the details
  4. Consider the device as potentially compromised
  5. Purchase a new device through the official channel

Q3: Do reproducible builds guarantee 100% security?

No. They guarantee that the compiled code matches the published source code. But:

  • The source code itself could contain vulnerabilities
  • The compiler could be compromised (a "Ken Thompson" attack)
  • The hardware could have backdoors

Reproducible builds are an essential verification layer, not an absolute guarantee.

Q4: Can I verify firmware on Windows?

Yes, but it is more complex. Recommendations:

  • Use WSL2 (Windows Subsystem for Linux) for Linux commands
  • Install Docker Desktop for compilation
  • Or use a Linux virtual machine

Q5: Should I verify with every update?

Ideally yes. In practice, do it at minimum:

  • On first use of a new device
  • After any major update
  • If you have doubts about the integrity
  • Periodically (every 6-12 months)


Related Articles -- Technical Security

Resources and Tools

Official GitHub repositories

Manufacturer Firmware Applications
Trezor github.com/trezor/trezor-firmware Included
Coldcard github.com/Coldcard/firmware github.com/Coldcard/ckcc-protocol
Ledger - github.com/LedgerHQ/app-bitcoin
SeedSigner github.com/SeedSigner/seedsigner Included
BitBox02 github.com/digitalbitbox/bitbox02-firmware Included

Official GPG keys

Verification tools

  • GPG: gnupg.org
  • SHA256: Built into Unix systems (sha256sum)
  • Docker: docker.com
  • trezorctl: pip install trezor
  • ckcc-protocol: pip install ckcc-protocol

Conclusion

Verifiability is the price of true digital sovereignty

Firmware verification is an advanced but accessible security practice. For users who are serious about minimizing their dependence on manufacturers, it is an essential step.

Key points to remember:

  1. Prefer open source devices (Trezor, Coldcard, SeedSigner)
  2. Always verify GPG signatures before updating
  3. Wait a few days before applying a new version
  4. If you cannot fully verify (Ledger), use it in a multisig setup with verifiable devices
  5. Verification takes time, but your bitcoins are worth it

Internal Links

Complete your security arsenal with these essential resources


Sources

Official documentation

  • Trezor Security: trezor.io/security
  • Coldcard Docs: coldcard.com/docs
  • Ledger Security: ledger.com/academy/security

Research and analyses

  • Wallet.fail: Security presentations on hardware wallets
  • Kraken Security Labs: Vulnerability analyses
  • Ledger Donjon: Internal Ledger research (partially open source)

Community

  • Bitcoin Stack Exchange: bitcoin.stackexchange.com
  • Reddit r/Bitcoin: Discussions and user feedback
  • Twitter/X: Security researcher accounts

Article written in December 2025. Commands and procedures may evolve with new firmware versions. Always consult the official documentation for up-to-date instructions.

Share:

Want to know more?

Discover all our articles and guides to master crypto.

View all articles