The cryptocurrency custody industry operated under a broad premise: the presence of a certified Secure Element sufficed to classify a device as resistant.
The Coldcard incident, where firmware replaced the hardware random number generator with a software implementation reducing entropy to 40 bits, refutes the premise. My position is that evaluation of a hardware wallet must begin with traceability of randomness origin, not with certification of the chip that stores the key.
I argue the sector requires an analytical framework oriented toward verifiable attack vectors: physical extraction, fault injection, supply chain compromise, and secret generation. Ledger, Trezor, and Coldcard respond differently to each vector, and differences matter more than feature lists.
Ledger: certified Secure Element and proprietary firmware
The Ledger model relies on a Secure Element (SE) with Common Criteria certification. Nano S Plus, Stax, Flex, and Nano Gen5 models incorporate chips with EAL6+ certification, while earlier generations remained at EAL5+. The role of the SE is dual: store cryptographic material and resist side-channel attacks and physical manipulation.
For seed generation, Ledger employs a TRNG integrated into the Secure Element that produces 256 bits of entropy without a software fallback mechanism. The described design decision explains why the company could state its devices were not affected by the Coldcard failure. From an engineering perspective, eliminating the software fallback reduces the attack surface at the most sensitive point in a key lifecycle.
The counterpart is proprietary firmware. Ledger submits code to audits by the Donjon team and reviews from firms including EDSI and Synacktiv, but the community cannot verify the complete binary. For one part of the sector, opacity is an acceptable cost against physical resistance of the SE. For another part, opacity constitutes a trust risk not mitigated by certification.
Ledger’s history of customer data breaches is a reminder that operational security and device security are separate domains. A robust SE does not protect a poorly secured order database.
Trezor: open source transparency and multichip architecture
The Trezor model evolved from a general-purpose microcontroller architecture toward a scheme with a Secure Element. The Trezor Safe series incorporates dedicated chips, and the Safe 7 employs a dual-chip architecture: the TROPIC01, presented as the first independently auditable SE, alongside an OPTIGA Trust M from Infineon with EAL6+ certification.
Trezor’s central argument is the absence of a single point of failure for secret storage. Distribution of responsibilities between two chips from different vendors complicates an attack that depends on an isolated vulnerability. Entropy generation relies on the device TRNG, and the company maintains open source firmware verifiable across the stack, from boardloader to application.
The 2026 incident with the TROPIC01 deserves separate analysis. Ledger’s Donjon team documented a laser fault injection attack on the chip. Trezor disclosed the finding and argued the attack requires physical possession, laboratory equipment, and does not compromise funds, because keys do not reside exclusively on the affected chip. I consider responsible disclosure and the dual-chip architecture limited the impact, although the episode demonstrates no SE is immune to targeted physical attacks.
For the user who prioritizes verifiability, Trezor offers a coherent proposition. For the user who prioritizes certified physical resistance, comparison with Ledger depends on model and adversary considered.
Coldcard: air-gapped, Bitcoin-only, and dual Secure Element
Coldcard was designed for an advanced Bitcoin user profile. The defining characteristic is air-gapped operation: transaction signing via MicroSD or QR code, without connection to a networked computer. Mk4 and Q models incorporate dual Secure Element with chips from two manufacturers, Microchip ATECC608 and Maxim DS28C36B, under the logic that an attacker must compromise both to extract the master secret.
Firmware is open source, verifiable, and support is limited to Bitcoin, with features including multisignature and PSBT. Absence of altcoins reduces code surface and simplifies audit.
The 2026 entropy failure alters evaluation. A firmware error, active between March 2021 and mid-2026, replaced the hardware RNG with a software system that degraded entropy to 40 bits. The consequence was theft of more than 38 million dollars in Bitcoin and severe reputational damage for a device marketed under operational paranoia criteria.
My reading is that the Coldcard case demonstrates a hierarchy of risks the sector tends to invert. Supply chain and storage receive priority attention, while seed generation is treated as a solved component. A device with dual SE can lose all advantage if the process prior to key writing produces predictable material.
Comparison of models and threat models
Useful comparison is not of brands but of threat models. For a remote adversary without physical access, all three devices offer equivalent guarantees in transaction signing and key isolation. For an adversary with physical access and laboratory equipment, Ledger and Trezor Safe 7 present EAL6+ certifications and multichip architectures, while Coldcard adds air-gapped mode as an additional layer.
For an adversary exploiting randomness generation weaknesses, the difference is decisive. Ledger maintains a TRNG in SE without fallback. Trezor distributes responsibility across chips. Coldcard suffered documented degradation for five years.
I consider the sector underestimates firmware risk relative to hardware risk. Certifications evaluate silicon, not boot logic or RNG implementation. A continuous audit program across the complete lifecycle, with reproducible binary verification and production entropy testing, is more relevant than a static certification.
A further consideration concerns supply chain verification
A device purchased through secondary markets or resellers introduces risk of pre-loaded firmware or hardware modification.
Ledger, Trezor, and Coldcard each provide mechanisms for firmware attestation, but the burden falls on the user to validate the device before first use. Coldcard’s air-gapped design reduces exposure during operation but does not eliminate risk during procurement.
Trezor’s open source stack allows independent verification of published binaries, while Ledger’s proprietary firmware limits verification to hash comparison and vendor attestation. No manufacturer eliminates supply chain risk entirely. The practical recommendation is to purchase directly from the manufacturer, verify packaging integrity, and perform a firmware update through official channels before generating a seed.
My position is that no device should be considered secure by default
Self-custody requires active verification. I recommend four practices: first, verify the seed using an independent tool that estimates entropy before depositing funds. Second, require open source firmware or, absent open source, reproducible public audits.
Third, assume the Secure Element protects against physical attacks, not against implementation errors. Fourth, diversify: distribute funds across devices from different manufacturers to reduce exposure to a systemic failure from one vendor.
Ledger retains an advantage in physical certification and ecosystem. Trezor retains an advantage in transparency and multichip architecture.
Coldcard retains an advantage in air-gapped operation and Bitcoin-only focus, with a recent history that requires additional verification from the user.
