Secure Elements: What Certification Proves, and What It Does Not

A secure element is a dedicated chip designed to hold a secret and resist attempts to extract it, including by someone holding the device. Certification schemes test that resistance against defined attack budgets and publish the result. Both the chip and the certificate are real engineering. What they cover is narrower than the phrase suggests, and the difference is where most confusion about hardware wallet security lives.

The threat it is built for

The problem a secure element solves is physical. If someone has your device, an ordinary microcontroller will surrender its contents to a determined attacker with laboratory equipment: probing the silicon, inducing faults with voltage or laser glitches, or reading power consumption to infer the key being used.

A secure element is hardened against each of these. Sensors detect abnormal voltage and clock behaviour and wipe or halt. The physical layout resists probing. Cryptographic operations are implemented so that timing and power draw do not vary with the secret. None of that is marketing; it is the specific engineering the certification tests.

This matters most in the scenarios people find easiest to imagine: a stolen device, a lost device, a device seized at a border. Without a secure element, the seed on a hardware wallet is recoverable by an attacker with the right equipment and enough interest. With one, it is not, within the attack budget the certificate describes.

What certification actually says

Certificates in this field state a scope and an assurance level, and both qualifiers do work.

The scope names what was evaluated. It is frequently the chip alone rather than the finished product, which means the certificate belongs to a component the manufacturer bought rather than to the device you are holding. A wallet built badly around a certified chip inherits the chip's resistance and none of its own.

The assurance level describes how thoroughly it was tested and against what attacker capability. Higher levels mean a better-resourced attacker was assumed and more of the design was examined. A certificate without its level quoted is close to meaningless, and it is quoted less often than it should be.

The date matters too. Attack techniques improve, and a certificate is a statement about the state of the art when the evaluation ran.

The gap: what the chip is asked to sign

Here is the limit that the phrase secure element does the most to obscure. The chip holds the key and performs signatures on request. It does not decide what to sign. That decision belongs to the firmware, and the firmware is separate.

So a device with an impeccable secure element can still sign a transaction that sends your funds to an attacker, if the firmware displays one thing and requests another. The chip did exactly what it was built for. The failure happened one layer up, in the part the certificate never covered.

This is the reason firmware verifiability is a separate question from chip certification, and why the two together are stronger than either alone. Certification answers: can someone with my device extract the key. Verifiability answers: does the device do what it says it does. A product can be strong on one and weak on the other, and several are.

The clearest demonstration of the gap

The most instructive case in this category was not an exploit at all. It was a manufacturer announcing a feature that let seed material be exported from devices as encrypted shards, as an optional recovery service.

The security debate that followed was not about whether the secure element had failed — it had not. It was about the discovery that signed firmware could instruct the chip to export key material at all. Owners who had assumed the architecture made that impossible learned that the constraint was a policy in firmware rather than a property of the hardware.

Whatever one thinks of the feature, the episode drew the boundary precisely: a secure element protects a secret from someone attacking the device from outside. It does not protect it from the code the device is running.

Reading a device's claims

• Find the certificate's scope. If it covers the chip rather than the product, it does not describe the device you are buying.
• Find the assurance level and the evaluation date. Both qualify the claim substantially.
• Ask separately whether the firmware is open and whether builds are reproducible, because certification says nothing about either.
• Check whether key export is architecturally impossible or merely disabled by firmware policy — these are different guarantees.
• Treat a certified chip as necessary rather than sufficient. It closes one attack class completely and leaves another entirely open.

The right conclusion is not that certification is theatre. It is that it answers one question extremely well, and buyers keep hearing it answer a second one it never addressed.