What is actually protecting your seed

The phrase "secure element" appears in eight guides on this site. It justifies why a COLDCARD wipes itself after thirteen wrong PINs, why Jade is built differently, why SeedSigner deliberately stores nothing, and why Ledger's closed firmware is a live argument. It is doing an enormous amount of work in those sentences, and none of them says what it is.

This page is that missing definition, and the honest account of what it buys. The short version, if you read nothing else: a secure element raises the price of stealing your seed from someone holding your device. It does not set that price to infinity, and neither does anything else on this page. The two measures that raise it furthest are not chips at all, and both come with conditions worth knowing before you rely on them.

1Where the seed actually sits

When your device is switched off, your seed is somewhere on it, in storage that survives losing power. That is the entire problem in one sentence. A backup you wrote on paper is protected by being in your house; a seed inside a device is protected only by whatever that device does to protect it.

There are broadly three answers on the market, and every device on this site takes one of them.

Those are three different answers to the same question, not three quality tiers, and the rest of this page is about what each one actually costs.

A hardware wallet's bare circuit board on a workbench, lifted out of its case, shot close and slightly overhead with hard side light. The small secure element in sharp focus, the larger microcontroller behind it falling out of focus.

Image to come

2What a secure element actually is

A secure element is a separate chip whose job is to hold secrets and refuse to give them up, including to someone with the chip in their hand and a laboratory around it. It is not simply "encrypted storage". Three properties make it different from ordinary memory:

• It resists physical reading. Shielding, sensors that detect the device being opened or run outside normal voltage and temperature, and layouts designed so that grinding the chip down destroys what you were trying to read. Historically this has come with a catch — the design is behind an NDA, so you are trusting a certification rather than reading anything. That is beginning to change.
• It can keep a secret to itself. The chip performs operations internally and returns results rather than handing over what it holds. What it holds is the design decision: in some devices that is the signing key itself, used inside and never given to the main processor. In others it is the secret that decrypts a key stored elsewhere on the device. That still means an attacker reading the main flash gets ciphertext, but the seed is not living inside the chip.
• It counts your failures itself. This is the property that matters most, and the one most people miss.

The reason a four-digit PIN can be reasonable protection is not that four digits are hard to guess. Ten thousand combinations is nothing. It is reasonable only because something is counting the wrong ones and will act before an attacker gets through them.

The whole security of a PIN therefore rests on where that counter lives. A counter kept in ordinary storage is a number an attacker can find and reset. A counter enforced inside a secure element is one they have to defeat the chip to reach. That is the actual product being sold.

3What happened to the devices without one

This is not theoretical, and the best-documented case involves a widely-owned device.

Trezor's earlier models, the One and the Model T, had no secure element. The seed lived encrypted in the flash of a general-purpose microcontroller, and the attempt counter lived there too. In 2020 Kraken Security Labs showed that this could be defeated with roughly fifteen minutes of physical access: desolder the microcontroller, and interfere with its supply voltage at a precisely timed moment during boot, a technique called voltage glitching, to dump the encrypted seed without knowing the PIN.

That dump was not the end of the attack, and the second half is the part worth understanding. The extracted storage was still encrypted under a key derived from the PIN. Kraken then guessed the PIN offline, against the dump, on their own hardware, and reported that a four-digit PIN fell in under two minutes even at a deliberately unoptimised guessing rate.

The original work needed skill and several hundred dollars of equipment. Kraken's own estimate was that a purpose-built consumer version of the tool could be produced for around seventy-five dollars.

Two things about that are worth sitting with.

• The PIN was broken, but not on the device. This is the distinction the whole page turns on. The counter was never defeated. It was made irrelevant, because once the encrypted storage is on an attacker's bench there is nothing left to count wrong attempts or wipe anything. A four-digit PIN is only ever protected by the thing enforcing it, and copying the data away removes that thing.
• The fix was already available to users. Trezor's response noted that the attack does not work against a wallet using a BIP39 passphrase. On these devices the passphrase was not written to the chip, so the dump did not contain it.
• It applied to the models researched, in the configurations researched. The Trezor One and Model T, with their particular STM32 microcontrollers. It is an illustration of what happens without an attempt counter you cannot walk away from, not a live claim about hardware sold today.

The later Trezor Safe line added a secure element, which is precisely the gap this closed. But the lesson generalises past one manufacturer: a device's resistance to someone holding it is a property of its hardware, and it is not something firmware can add later.

4The stateless answer

SeedSigner and Krux answer the question by refusing it. Out of the box they store no seed at all: you enter your words at the start of a session, the device holds them in volatile memory while it signs, and cutting the power erases them completely.

A device with nothing on it cannot have anything extracted from it. That is a genuinely strong property, and it is why a SeedSigner can be left in a drawer, or disassembled, with no more concern than any other Raspberry Pi.

• Krux is stateless by default, not by construction. Its own documentation describes storing an encrypted mnemonic in the device's internal memory or on an SD card, and loading it back by entering the key used to encrypt it. A Krux configured that way has something on it, and the protection is the encryption rather than the absence.
• So "nothing to extract" is a claim about how you are running it. If you have used the stored-mnemonic feature, the device and any SD card left with it are sensitive objects: on loss, on disposal, and in a drawer. Treat them the way you would treat a written backup with a password on it.
• An inserted SD card counts. A stateless device with a mnemonic backup card still in the slot is not a stateless device while that card is in it.

It moves the problem rather than removing it. The seed still exists — on whatever you wrote it on, and in your hands every time you type it in. A stateless device converts "protect the hardware" into "protect the backup, and protect every session", which is a fair trade for some people and a worse one for others. It is the reason those guides spend so long on where you are standing when you enter the words.

5What an attacker with your device can actually do

The honest version, since every device guide gestures at this and none of them states it plainly.

Read the last row twice. Most of this page is about hardware, and the most common way seeds are actually taken is that somebody found the paper. Chips are a defence against a threat that is real but comparatively rare; the backup is the one nearly everybody actually faces.

6The two things that survive physical possession

Everything above is about raising a price. These two change the shape of the problem, because neither can be extracted from hardware someone is holding.

A passphrase the device does not retain

A BIP39 passphrase is not part of the seed sitting in storage. It is mixed into the key derivation itself, so that the words and the passphrase together produce the seed. A passphrase you type in each time is therefore not on the chip for a physical attack to recover. This is exactly why Trezor's answer to the glitching attack was to point at the passphrase feature, and why the wallet-compatibility trackers qualify their physical-extraction findings with when no passphrase or multisig is in use.

• Some devices will store it for you, and then it is on the device. Ledger's OS documents attaching a passphrase to a second PIN, so that unlocking with that PIN activates that wallet. That is a convenience feature and a real one, but a passphrase stored this way is no longer a secret held outside the hardware, and anyone who obtains that PIN reaches that wallet. If the passphrase is doing the work described in this section, it has to be one you enter rather than one the device remembers.
• A weak passphrase is guessable once the seed is out. The protection is not the mechanism, it is the search space. After a successful extraction an attacker holds the words and can try passphrases offline, as fast as their hardware allows, with no device counting anything. A short or memorable passphrase does not survive that; a long, high-entropy one is what the argument in this section actually depends on.
• A device in use is handling derived keys regardless. A passphrase protects the secret at rest. It is not a claim about a powered-on, unlocked signer, which necessarily has signing material in memory while it works.

The cost is real and it is covered properly in the passphrase guide: it is a second irreplaceable secret, and forgetting it loses the wallet as thoroughly as losing the words.

Multisig

A key extracted from one device in a 2-of-3 is a key that cannot spend anything. The attacker needs a second one, held elsewhere, running different firmware. That is a structural answer rather than a procedural one, and it is the same reasoning that makes multi-vendor multisig the only defence against a dishonest manufacturer.

7What to actually take from this

• Treat a lost or stolen device as urgent, not annoying. A secure element buys you time to move funds. It does not make the device safe to write off.
• Match the chip to the threat you actually have. If your realistic concern is fire, flood and your own filing, secure elements are close to irrelevant and your backup is everything.
• Consider a passphrase before you conclude your hardware is the weak point. Use one you enter rather than one the device stores, long enough to survive offline guessing. It is the documented answer to physical extraction. It is not free: it is a second irreplaceable secret, and the passphrase guide exists because losing it loses the wallet.
• Do not let the chip choice decide the product. A closed secure element and a fully open device with no secure element are two coherent positions, and the manufacturers taking each one are explicit about it. A third has recently appeared — an auditable secure element, published rather than certified-and-sealed — which is worth watching without yet being a reason to replace anything.

The short version

A secure element is a chip built to hold secrets and count failed attempts somewhere an attacker cannot simply reset. Devices that lacked one have had their storage pulled out with a soldering iron and a well-timed voltage drop, after which the PIN was guessed offline in minutes. Devices that store nothing cannot be read at all, and move the problem to your backup and your hands. Every one of those is a price rather than a wall. The two measures that raise it furthest are a passphrase the device does not retain and a second key somewhere else, and each holds only under conditions this page has tried to state rather than assume.

The extraction technique described here is documented public research from 2020 against hardware that has since been superseded, including its offline PIN-guessing step, and it is included because it is the clearest illustration of what the attempt counter is for, not as a live claim about any current product. The Trezor Safe architecture described above, Ledger's passphrase-to-PIN option and Krux's stored-mnemonic feature are each taken from that project's own current documentation. Chip choices, firmware and model lineups change; confirm what your own device uses against the manufacturer's documentation, and treat this page as the reasoning rather than the specification.