Dr. Sarah ChenWhat Hardware Wallets Actually Do
A hardware wallet is a dedicated signing device. Its core function is to store your private key in a secure enclave, typically a certified secure element chip, and perform cryptographic signing operations inside that enclave. The private key never leaves the device in plaintext. When you initiate a transaction, your computer sends the unsigned transaction data to the hardware wallet, the device signs it internally, and sends back only the signature.
This design protects against a specific and real threat: an attacker who compromises your computer through malware, phishing, or remote access cannot extract your private key because it never touches the compromised machine. Hardware wallets are highly effective at this.
What hardware wallets do not change is which signature algorithm they use. Every major hardware wallet ships with ECDSA over secp256k1 for Bitcoin and Ethereum, and ed25519 for some other chains. The secure enclave protects the key from software attackers. It does nothing to protect the cryptographic scheme itself from an attacker with a quantum computer running Shor's algorithm.
These are two separate security properties. Conflating them is one of the most common misconceptions in the quantum security conversation. See our broader analysis of protecting crypto from quantum attacks for the full framework.
Ledger's Current Cryptographic Support
Ledger devices (Nano S Plus, Nano X, Stax, Flex) use an ST33 or similar secure element. They support secp256k1 ECDSA for Bitcoin and Ethereum, ed25519 for Solana and related chains, and several other classical curves for specific blockchains. Ledger's cryptographic support is determined at the firmware level and implemented in their SDK.
As of mid-2026, Ledger has not shipped any production firmware or application that uses ML-DSA, CRYSTALS-Kyber, or any other NIST-standardized post-quantum algorithm for transaction signing. Ledger has publicly discussed post-quantum cryptography in research contexts, and their Ledger Research team has published work on the topic, but that has not translated to a shipping product feature for signing operations.
Ledger Recover, their seed phrase backup service, is a separate matter and uses different cryptographic infrastructure. It does not make your signing operations post-quantum safe.
Trezor's Position
Trezor devices (Model T, Model One, Safe 3, Safe 5) run open-source firmware. Their security model uses a different chip architecture than Ledger: the Safe 3 uses an ATECC608 secure element alongside the main microcontroller, while older models rely on microcontroller-level protections.
Trezor's signing operations use the same classical algorithms: secp256k1 ECDSA and ed25519. The open-source nature of Trezor's firmware means community contributors can in principle submit post-quantum signing implementations, but as of this writing no such implementation has been merged into production firmware. The Trezor firmware repository has had discussions about post-quantum roadmap items, but no shipping timeline has been committed to publicly.
Trezor's open-source model does make it easier to audit what cryptographic operations are running on the device, which is meaningful for security researchers. It does not change the current quantum vulnerability.
Coldcard's Approach
Coldcard (Mk4, Q) is Bitcoin-only and is known for being an extremely conservative, security-focused device. It uses dual secure elements and emphasizes air-gap operation. For Bitcoin specifically, Coldcard supports Taproot (P2TR) addresses, which when used correctly with key-path spends on fresh, never-reused addresses provide some degree of public key hiding.
However, Coldcard still uses secp256k1 ECDSA and Schnorr signatures. It does not support ML-DSA or any other post-quantum signature scheme. The Coldcard team has not published a post-quantum roadmap. Given their Bitcoin-only focus and conservative development philosophy, post-quantum support would require significant firmware and potentially hardware changes.
The Taproot support is worth noting for Bitcoin holders who are serious about reducing public key exposure. Using a fresh P2TR address for each receive, and spending the full balance in one transaction to a new address, minimizes the window during which your public key is visible. This is risk reduction, not quantum safety. For the full picture on Bitcoin's quantum exposure, read our dedicated analysis of Bitcoin quantum vulnerability.
Does Any Hardware Wallet Support ML-DSA in Production?
As of mid-2026, no major hardware wallet supports ML-DSA or any other NIST PQC standard for production transaction signing. Some vendors have experimental branches or internal research builds, but nothing is shipping to end users for real asset management.
This is not a simple firmware update. Post-quantum signature algorithms have larger key sizes and signature sizes than ECDSA. ML-DSA public keys are 1312 bytes; ECDSA public keys on secp256k1 are 33 bytes compressed. Signatures under ML-DSA-44 are 2420 bytes; ECDSA signatures are approximately 71 bytes. These differences affect memory requirements on the secure element, transaction size on-chain, and the computational load during signing. Existing secure element chips were not designed with these parameters in mind.
What Hardware Wallet Vendors Would Need to Change
A hardware wallet that genuinely supports post-quantum signing would need:
- A new or updated secure element with sufficient memory and processing capability for ML-DSA or equivalent operations.
- Firmware implementing the post-quantum signing algorithm, certified to the same security standards as existing firmware.
- Application-layer support for the specific chains that have implemented post-quantum signature verification on-chain.
- User interface changes to handle longer addresses and different key derivation paths.
The blockchain layer also needs to support post-quantum signature verification. Ethereum mainnet does not yet have a production ML-DSA precompile. Bitcoin has no post-quantum signature scheme in its roadmap with a confirmed activation date. Hardware wallet vendors cannot ship quantum-safe signing for chains that do not yet verify post-quantum signatures on-chain.
Realistic Timeline and What to Do Now
Post-quantum hardware wallets are likely 2 to 5 years away for most users, with early adopters on experimental chains like QuanChain having access sooner through software wallets. The hardware wallet ecosystem will follow after blockchain-level post-quantum support becomes stable.
In the meantime, hardware wallets remain worth using. They protect against the threat that is active today: private key theft via malware, phishing, and remote compromise. A quantum attack against ECDSA at scale is not the current threat; classical theft is. Use your hardware wallet for key storage security while accepting that quantum risk applies to the signing algorithm.
For long-term, high-value cold storage holdings:
- Use hardware wallets to protect against classical theft. This threat is real and present.
- Prefer address formats that minimize public key exposure (P2WPKH or P2TR for Bitcoin, fresh addresses on Ethereum).
- Never reuse addresses. Each spend exposes the public key; reuse gives an attacker the public key with more time to act.
- Monitor post-quantum developments at the blockchain level. When your chain of choice implements post-quantum signing, migrate at that point.
For assets you want genuine quantum protection on now, the only practical option is a chain that implements post-quantum cryptography at the protocol level. Read our overview of post-quantum cryptography standards to understand what protocol-level protection actually involves.
