The "passphrase" often gets called the "25th word" because it is an extra input added on top of a standard 12- or 24-word seed phrase (recovery phrase). Technically this is an optional BIP-39 passphrase: it is not one of the 24 words, but rather an additional string you supply when deriving your wallet keys. See the BIP-39 specification for the exact derivation method (PBKDF2 with salt "mnemonic" + passphrase) (BIP-39).
Why do people use it? Because a passphrase creates a "hidden wallet": the same 24-word seed + different passphrases => different wallets. That property is powerful. And it is dangerous if used without planning.
In practice that means: forget the passphrase and you can still reconstruct the original wallet(s) that were created with an empty passphrase — but you cannot reconstruct any wallets that required a non-empty passphrase. The passphrase is not stored in the seed phrase or on the device.
In my testing, the passphrase feature is most useful when combined with a clear operational plan (what passphrase controls which funds, and where that passphrase is stored). Without a plan, the benefit quickly becomes a liability.
Forgotten passphrase = permanent loss. If you lose the passphrase for a particular hidden wallet, no amount of searching the 24 words will recover those funds. That’s a factual, repeatable property of the BIP-39 derivation.
Weak or guessable passphrases are attackable. A short, dictionary phrase or personal datum (birthdate, pet name) is susceptible to brute-force or informed guessing.
Storing the passphrase insecurely (cloud, phone notes, synced password managers) can negate the security benefit. Password managers that sync to the cloud increase the attack surface.
Cross-device differences and UI traps. Some wallet apps accept any Unicode passphrase, some restrict characters or length, and some implement passphrase entry off-device (host typing) which can expose the passphrase to a compromised computer. Always verify how a particular hardware wallet implements passphrase entry (device vs host) before relying on it.
False sense of redundancy. People sometimes write down the 24 words and assume that’s sufficient. But if funds were put into a hidden wallet protected by a passphrase, the written 24 words alone are not enough for recovery.
For technical reference, consult BIP-39 and the SLIP-0039 Shamir backup proposal (an alternative approach to redundancy) (SLIP-0039).
Need a more device-specific walk-through? See the general device setup guides: setup-initial and restore-recovery.
What I advise in practice: create a clear naming/usage convention (e.g., “savings-v1”), store it on metal, and test recovery annually. But everyone’s threat model is different.
| Option | How it works | Best for | Downsides |
|---|---|---|---|
| Passphrase (BIP-39, “25th word”) | Adds an optional string to the mnemonic derivation so the same seed produces separate wallets | Single-seed compartmentalization; plausible deniability | Forgetting it loses funds; user-managed security |
| SLIP-0039 (Shamir backups) | Split seed into multiple shares; a threshold is needed to recover | Redundancy and distributed custody | More complex recovery; tool and compatibility limits (shamir-backup-slip39) |
| Multisig | Funds require multiple signatures from different keys/devices | High-security custody; fault tolerance | Requires compatible wallets and coordination (multisig) |
Choose based on your operational needs. Multisig is often safer for long-term, high-value storage, but requires more setup and compatible wallet support.
For other frequently seen errors, read the guides on common-mistakes and where-to-buy-safely.
Q: Can I recover my crypto if the device breaks? A: Yes, if you have your 24-word seed phrase and the passphrase (if used). If the passphrase is lost for a hidden wallet, that wallet’s funds cannot be recovered. See device-broken and restore-recovery.
Q: What happens if the company that made my hardware wallet goes bankrupt? A: Your keys are derived from your seed phrase and passphrase; hardware vendor failure doesn’t inherently delete your funds. Still, vendor support affects firmware and tooling (see company-risk).
Q: Can someone brute-force the passphrase? A: Short or guessable passphrases can be brute-forced. Long random passphrases greatly increase the time and cost to attack. Use length and randomness.
Q: Is Bluetooth safe for a hardware wallet when using a passphrase? A: Bluetooth adds a wireless layer that some users prefer to avoid for high-value operations. The bigger risk for passphrase security is host compromise and where the passphrase is entered. See connectivity-usb-bluetooth-nfc.
A passphrase (the so-called 25th word) is a powerful security tool when used deliberately: it gives hidden wallets and an extra factor, but it also creates a single-point-of-failure if the passphrase is lost or handled poorly. I believe a passphrase makes sense for users who have a clear backup and inheritance plan and who are willing to test restores regularly. For others, multisig or Shamir-style backups may be safer.
Start small: test your chosen workflow with tiny amounts, confirm restores on a separate device, and document who can access recovery information. If you want detailed, device-specific instructions and walkthroughs, see our related guides: seed-phrase-management, backup-and-recovery, shamir-backup-slip39, and multisig.
(Technical references: BIP-39 and BIP-32 specifications linked above; SLIP-0039 for alternative backup strategies.)
If you have a specific scenario—inheritance, high-net-worth storage, or daily-spend split—I can outline a custom plan step-by-step. Want one? Click through the related guides and I’ll help map a safe approach.