Two of the pieces I’ve written this week both point at the same failure mode without stopping to explain it properly: someone restores a wallet, follows every step correctly, and lands on a balance of zero. Almost always, the missing piece is a passphrase, and the confusing part is that a passphrase and a seed phrase sound like the same kind of thing. They aren’t, and the difference is worth its own explanation rather than a footnote in someone else’s article.
The seed phrase is the whole wallet. The passphrase decides which one you get.
Your seed phrase, the ordered list of 12 or 24 words a hardware wallet gives you at setup, is generated under BIP-39, a specification I went back to directly for this piece rather than relying on how vendors summarize it. Underneath the words there’s just entropy, a random number, encoded so a human can copy it down without making transcription errors. On its own, that mnemonic is enough to derive a seed and rebuild every account tied to it.
A passphrase is a second, separate string you can optionally add on top. It isn’t one of the 2,048 words in the standard wordlist, and it doesn’t get appended to your 12 or 24 words as a literal 13th or 25th entry, even though that’s the informal name the community uses for it. The spec itself just calls it a passphrase. What actually happens, per the standard, is that your mnemonic and your passphrase both get fed into a key derivation function together, and the output is a completely different seed. Same words, different passphrase, different wallet, different addresses, no overlap.
That’s the part that trips people up. It feels like a passphrase should work the way a second password works on an email account, an extra lock on the same door. It doesn’t. It’s not locking the door. It’s opening a different room, and the words alone tell you nothing about how many rooms exist or which one you were actually using.
Why this exists at all
The BIP-39 spec is explicit that this is by design, not an accident of the math. It states plainly that every passphrase produces a valid seed, so there’s no way to look at a set of 12 or 24 words and know whether a hidden wallet exists behind some passphrase, or which one is the “real” wallet. That property has a name in the space: plausible deniability. Show someone your seed phrase under duress, and the wallet it opens can hold whatever small amount you’re comfortable losing, while a passphrase you never mentioned protects the rest.
I don’t know how many people actually use a passphrase for that specific threat model versus just for the extra layer of security if the seed phrase alone ever leaks. Nobody publishes that split. What I can say is that vendor documentation treats both uses as legitimate and treats “I forgot my passphrase” as a routine, unresolvable support request, not an edge case.
The part that actually locks people out
A passphrase is not selected from a fixed list, so there’s no built in typo checking the way there is with the seed words themselves. Capitalization matters. A trailing space matters. “Correct horse” and “correct horse ” are different passphrases, opening different wallets, and neither device nor software will warn you, because from the system’s point of view you just successfully opened a valid wallet. It’s simply not the one you meant.
Trezor’s own documentation is direct about this: the passphrase is never stored on the device, cannot be recovered if forgotten, and has to be entered exactly, every time. BitBox says essentially the same thing. There’s no password reset flow here, because a reset would require someone, somewhere, to hold a copy of your passphrase, and the entire design exists specifically so that nobody does.
What this means practically
If you’ve never set a passphrase, none of this changes anything for you. Restoring your seed phrase alone opens your one and only wallet.
If you have set one, or you’re thinking about it, treat the passphrase as at least as sensitive as the seed phrase itself, not as a convenience add-on. Write it down with the same care, store it separately from the seed words rather than next to them, and if you’re inclined toward the hidden-wallet use case, remember that the decoy wallet and the real one need to look plausible independently; an empty decoy invites more questions than it deflects. Test the exact passphrase on a spare device before you rely on it for anything meaningful, the same way you’d test the seed phrase itself. And if you ever hand someone your recovery instructions for inheritance purposes, the passphrase has to be part of that plan explicitly. A seed phrase alone, without the note that a passphrase exists, will hand your executor an empty wallet and no reason to suspect there’s another one.
For the broader recovery picture behind this, see What Happens If You Lose Your Hardware Wallet?
Disclosure: educational content, not individualized security, legal or financial advice.
If the words may already have been exposed, do not try to repair the same wallet: follow the compromised seed response. For prevention, use the seed storage design.
