Hardware Wallets And Secure Elements: What Are You Really Trusting?

By Lucien Bourdon, Bitcoin Analyst at Trezor

A hardware wallet is a standard tool for securing cryptocurrency, and most rely on a dedicated chip known as a Secure Element; the same type used in credit cards and passports.

But here’s what matters most: how a wallet uses this chip. This choice defines what you are ultimately asked to trust, and it splits the industry into two fundamentally different philosophies.

Why ‘Trusted’ Hardware Can’t Be Trusted

A standard Secure Element operates on a principle of secrecy. Manufacturers shield their chip’s inner workings with non-disclosure agreements (NDAs).

This makes independent security review impossible. Users and makers alike must take the manufacturer’s word for it. Researchers and hardware wallet makers cannot freely test or publicly discuss what they find. Even if a critical flaw is discovered, the NDA can legally prevent its disclosure, leaving users in the dark.

We learned this the hard way. Years ago, Trezor evaluated a leading Secure Element under NDA for a prototype. Our testing revealed issues we couldn’t publicly discuss, as the NDA prevented transparency.

That experience clarified our path. We decided we didn’t want your private keys dependent on closed, unauditable hardware. Instead of searching for a chip to trust completely, we built an architecture where the Secure Element never holds your keys. Even when we later developed our own fully auditable Secure Element (TROPIC01), we kept this design. We don’t ask you to trust us. We don’t even trust ourselves. The architecture is trustless by default.

Two Designs, One Critical Difference

This is where hardware wallet designs diverge. All use a Secure Element for protection, but where your private keys are stored changes everything.

Design 1: The Chip Holds Your Keys

Here, your private keys live inside the Secure Element. It generates, stores, and uses them in a closed, certified environment.

• The Logic: Contain all sensitive operations in a tamper-proof box.
• What You Trust: The chip maker’s reputation, their secret internal code, and the hope their certifications match your real-world threats.
• The Reality: You get strong physical protection but must accept that the most critical processes are invisible and unauditable.

Design 2: The Chip Unlocks Your Keys

Here, your private keys are encrypted on the main processor. Without the decryption key, this encrypted data is completely worthless to an attacker. The Secure Element holds only that decryption key, protected by your PIN. It never sees your actual private keys.

Your keys are protected by unbreakable encryption; the same cryptographic strength that secures Bitcoin and other crypto networks. The entire system runs on open-source firmware anyone can audit.

• The Logic: Strong and verifiable encryption beats hidden secrets. With auditable code, you can prove how your keys are protected. With closed hardware, you can only believe the claims.
• What You Trust: Cryptography and public code. The Secure Element only handles access control like PIN verification.
• The Reality: Complete transparency. The chip provides hardware protection without becoming an unverifiable single point of trust.

Why We Built for Transparency

Trezor is built on the second design model. Your private keys remain encrypted outside the Secure Element, protected by encryption and an operating system anyone can audit.

This aligns with our founding principle: true security requires transparency, not obscurity. You shouldn’t have to trust us; you should be able to verify how your wallet works.

This commitment to verification guides our entire approach. We believe you should have hardware security without compromise, which is why we advocate for and develop open security tools where every layer of protection can be examined.

The Bottom Line

A Secure Element is not a guarantee of security by itself. It is a component whose value depends entirely on how it is implemented.

The decisive choice is whether your private keys depend on code or hardware you cannot audit.

_________________________________________________________________________

Bitcoin.com accepts no responsibility or liability, and shall not be liable, whether directly or indirectly, for any loss, damage, claim, cost, or expense of any kind, whether actual, alleged, or consequential, arising out of or in connection with the use of, or reliance upon, any content, goods, or services referenced in this article. Any reliance placed on such information is strictly at the reader’s own risk.