A 24-word seed phrase feels like the end of the security conversation. It isn’t. Anyone who finds that paper backup, photographs it, or coerces you into revealing it owns every coin tied to it. A BIP-39 passphrase, often called the “25th word,” closes that gap by turning one seed phrase into an unlimited number of separate wallets, each one invisible unless you type the exact extra word or sentence that unlocks it. This tutorial walks through setting one up correctly on the hardware wallets that support it, testing recovery before you fund anything, and avoiding the mistakes that have permanently locked people out of their own coins.
By the end you’ll have a working hidden wallet, a documented recovery plan, and a checklist you can hand to anyone who might need to help recover funds after you. The steps below apply to Trezor Safe 7, Ledger Nano X/Flex/Stax, Coldcard Q1/Mk4, and Blockstream Jade, with notes on where each device diverges.
What a BIP-39 passphrase actually does
BIP-39 is the Bitcoin Improvement Proposal that standardized the 12- or 24-word mnemonic most wallets use today, documented in the official BIP-39 specification on GitHub. That spec includes an optional extension: any string you append to the mnemonic before it’s run through the PBKDF2 key derivation function produces a completely different binary seed. Change the passphrase by one character and you get a different set of private keys, a different set of addresses, and a different wallet, even though the 24 words on your metal backup never change.
This matters because the passphrase is never stored on the device and never printed on your backup. It exists only in your memory (or in a second, separately secured location). If someone steals your seed phrase card but doesn’t know the passphrase, they can still restore “a” wallet from it, but it will be the empty default wallet, not the one holding your funds. Trezor’s own documentation calls this a “hidden wallet,” and the design intentionally makes the hidden wallet indistinguishable from an empty standard wallet unless you know to look for it.
The tradeoff is unforgiving. There’s no password reset, no support ticket, no recovery email. If you forget the exact passphrase, capitalization included, the funds inside that hidden wallet are gone forever, with no way for the manufacturer, a court order, or a hardware fault report to get them back. That single fact should shape every decision you make in this guide.
Prerequisites
Gather everything below before you touch a live wallet. Skipping the test-fund step later is the single most common cause of support requests about “lost” hidden wallets.
- A hardware wallet with native passphrase support: Trezor Safe 7 or Model One/T (firmware 2.8.x or later), Ledger Nano X, Flex, or Stax running Ledger Live 2.9x+ with the passphrase feature enabled in developer settings, Coldcard Mk4 or Q1 (firmware 5.4.x+), or Blockstream Jade (firmware 1.0.x+)
- An existing 12- or 24-word BIP-39 seed phrase already generated on the device, ideally one you’ve already backed up on steel
- A second, separate physical medium to record the passphrase (never the same card or plate as the seed words)
- A small amount of cryptocurrency, roughly $10 to $20 worth, to test the hidden wallet before moving real funds
- A companion app: Trezor Suite, Ledger Live, the Coldcard’s own menu system (air-gapped, no companion app required), or Blockstream Green for Jade
- 30 to 45 minutes of uninterrupted time in a private space with no cameras or onlookers
If you haven’t generated a seed phrase yet, do that first and confirm it restores correctly on a wipe-and-restore test before adding a passphrase on top of it. Layering a passphrase onto an unverified seed just compounds the risk if the base backup was transcribed wrong.
Step 1: Decide where the passphrase will be entered
Every supported device gives you a choice: type the passphrase on the device’s own screen and buttons, or type it into the companion app on your computer or phone. Enter it on the device whenever the hardware allows it. Coldcard and Jade only support on-device entry, which sidesteps the question entirely. Trezor and Ledger both support on-device entry as the default, more secure path, with host-app entry available as a fallback for devices with no keyboard, like the older Ledger Nano S.
Entering the passphrase on a computer means it passes through that computer’s memory, however briefly, and a compromised host could theoretically log it. On-device entry via a touchscreen or button-matrix keeps the string inside the secure element the entire time. If your device supports both, on-device entry is worth the extra thirty seconds it takes to enter longer strings with a directional pad.
Step 2: Choose a passphrase with real entropy
A weak passphrase defeats the entire point. “bitcoin2026” or your dog’s name adds almost no protection against a targeted attacker who already has your seed words, because they can brute-force a short dictionary-style passphrase in a reasonable amount of time. NIST’s guidance on entropy applies directly here: longer, higher-entropy strings resist guessing far better than short “clever” ones, as outlined in NIST’s glossary definition of entropy.
Two approaches work well in practice. The first is a long, random sentence you can memorize through repetition, built from unrelated words that don’t form a common phrase, something like a five- or six-word string generated with dice and a wordlist. The second is a shorter but genuinely random string of mixed-case letters, numbers, and symbols generated by a password manager and stored as securely as the seed phrase itself, just never in the same physical location.
Avoid anything you’ve used elsewhere. Avoid quotes, song lyrics, or phrases that show up in leaked password databases. Avoid keyboard patterns. And avoid making it so long and complex that you can’t reliably reproduce it a year from now under stress, because a passphrase you can’t type back correctly is functionally the same as a passphrase you never wrote down.
| Passphrase style | Approx. entropy | Memorability | Recommended use |
|---|---|---|---|
| Single dictionary word | ~13 bits | Very high | Never use |
| Short phrase, no randomness (“MyDog2019!”) | ~30 bits | High | Not recommended |
| 4-word Diceware-style phrase | ~52 bits | Medium-high | Everyday hidden wallet |
| 6-word Diceware-style phrase | ~77 bits | Medium | High-value cold storage |
| 16-character random string (mixed case, digits, symbols) | ~95+ bits | Low without a manager | Institutional / max security |
Step 3: Enable the passphrase feature on your device
The toggle location differs by manufacturer. On a Trezor, open Trezor Suite, go to Settings, then Device, and switch on “Passphrase.” From that point forward, every time you connect the device you’ll be prompted to enter a passphrase, where leaving it blank restores your original standard wallet and any non-blank entry opens a corresponding hidden wallet.
On a Ledger device, the passphrase feature lives under Settings, then Security, then “Passphrase,” where you can choose between a temporary passphrase that resets when the device powers off, or a passphrase permanently attached to a second PIN. The PIN-attached mode is genuinely convenient: PIN one opens your normal wallet, PIN two opens the hidden one, and you never have to type a long string each session, according to Ledger’s own support documentation at support.ledger.com.
On a Coldcard, navigate to the main menu, select “Passphrase,” and the device walks you through on-screen entry using its physical keypad or touchscreen depending on the model, as documented at coldcard.com/docs/passphrase. Coldcard also supports a clever trick worth knowing: it can derive and display the resulting hidden wallet’s first receive address before you commit any funds, letting you sanity-check the derivation before risking anything.
On a Blockstream Jade, go to Options before selecting your wallet, then “BIP39 Passphrase,” and choose whether the device should prompt for it on every login or only the first time you connect in a session, per Blockstream’s Jade product documentation.
Step 4: Enter the passphrase for the first time
Type slowly. Most devices show the string as you enter it, character by character, specifically so you can catch typos before confirming. Trezor and Coldcard both display the input on-screen; Ledger’s PIN-attached method has you confirm the passphrase twice during setup to catch transcription errors early.
Once confirmed, the device derives a completely new set of addresses. This is the moment the hidden wallet is created, in the mathematical sense; there’s no separate “create wallet” action beyond entering a passphrase the device hasn’t seen before. Every unique passphrase string produces its own deterministic wallet, so a typo doesn’t corrupt anything, it just opens a different (empty) hidden wallet than the one you meant to reach.
# Conceptually, this is what the device does internally (simplified):
# BIP-32 root seed = PBKDF2-HMAC-SHA512(
# password = mnemonic_words,
# salt = "mnemonic" + passphrase,
# iterations = 2048
# )
#
# Change the passphrase string -> different salt -> completely different root seed
# Same 24 words + empty passphrase = standard wallet
# Same 24 words + "correct horse" = hidden wallet A
# Same 24 words + "correct-horse" = hidden wallet B (different address set entirely)
Step 5: Verify the receive address before funding anything
Before sending a single satoshi, generate a receive address from the new hidden wallet and confirm it on the device’s own trusted screen, not just in the companion app’s window. This step exists specifically to catch host-side malware that swaps displayed addresses, and it applies just as much to a fresh hidden wallet as it does to your standard one.
Write down or screenshot this first address in a note that also records which passphrase generated it (store the note somewhere separate from the passphrase itself, or encrypted). This becomes your reference point for confirming, months or years later, that you’re re-entering the correct passphrase during recovery.
Step 6: Send a small test amount
Send $10 to $20 worth of crypto to the hidden wallet’s receive address. Confirm it arrives and shows the correct balance in your companion app while the passphrase is entered. This step catches two separate failure modes at once: a typo in the passphrase that silently opens the wrong hidden wallet, and any misconfiguration in the derivation path your wallet software is using.
Do not skip ahead to moving your full balance yet, even if the test transaction looks perfect. The real test is recovery, which happens on a second, independent device.
Step 7: Test full recovery on a second device
This is the step almost everyone skips, and it’s the one that actually proves your setup works. Take a second hardware wallet, ideally a different unit of the same model, wipe it or use a fresh one, and restore it using only your written 24-word seed phrase plus the passphrase you memorized or wrote down separately.
Confirm the test funds you sent in Step 6 show up with the correct balance. If they do, your backup materials are sufficient to recover the hidden wallet from scratch, with no reliance on the original device’s memory or settings. If the balance doesn’t appear or the address doesn’t match, stop, don’t fund anything further, and work backward through Steps 3 to 6 to find where the passphrase entry diverged.
A surprising number of “lost” hidden wallets trace back to invisible differences between devices, like a keyboard layout that inserts a different character for the same keystroke, or leading and trailing spaces the companion app silently trims on one device but not another. Testing recovery on separate hardware surfaces these issues while the stakes are still $15, not your life savings.
Step 8: Document a recovery plan without exposing the passphrase
Write instructions for whoever might need to recover these funds after you, without writing the passphrase itself into that document. A reasonable structure: a sealed instruction sheet that says “the seed phrase is stored at [location]; it requires an additional passphrase, stored separately at [location or with lawyer/executor]; both are required together.”
Separating instructions from secrets means someone who finds only the instructions still can’t access funds, but someone who’s authorized to execute your estate plan has a clear path forward instead of a locked hidden wallet nobody knew existed.
Step 9: Move real funds and monitor the first live transaction
With recovery verified on a second device, move a larger but still not maximal amount, confirm it clears normally, and check the balance again from the companion app connected to your primary device. Only after this second successful round should you consider moving your full holdings into the hidden wallet.
If you’re consolidating funds from an existing standard wallet into the new hidden one, treat it like any other wallet migration: send in a few smaller batches rather than one large sweep, and confirm each batch before sending the next.
Step 10: Set up a decoy wallet (optional but recommended for high-risk users)
The plausible-deniability use case for a passphrase only works if the standard, passphrase-less wallet holds something. An empty standard wallet next to a hidden wallet with real value is itself a signal to an attacker who understands how passphrases work. Consider keeping a modest, spendable amount in the standard wallet, something you could hand over under duress, while your primary holdings live behind the passphrase.
This only helps against an attacker who doesn’t already know you use a passphrase system. Against a sophisticated or informed attacker, a visibly empty standard wallet won’t stop further coercion, so weigh this step against your actual threat model rather than treating it as a guaranteed defense.
Step 11: Store the passphrase using a different method than the seed
Never engrave the passphrase on the same steel plate as your seed words, and never write it on the back of the same paper. If both pieces travel together, you’ve recreated a single point of failure, just with extra steps. Common separation strategies include memorization for a short, well-rehearsed passphrase, a sealed envelope with a different trusted party or safe deposit box than the one holding the seed, or splitting the passphrase itself across two locations using a simple, pre-agreed method.
Whichever method you choose, test it. If the plan relies on memory, quiz yourself weekly for the first month, then monthly. If it relies on a stored physical copy, confirm you can actually retrieve it within the timeframe you’d need in an emergency.
Step 12: Schedule a periodic recovery drill
Once a year, repeat Step 7: restore on a spare device using only your stored materials, confirm the balance, and wipe the spare device again. This catches drift, a swapped storage medium, a passphrase you’ve started misremembering, a firmware update that changed a default setting, before it becomes a real problem. Treat it the same way you’d treat testing a data backup: untested backups are not backups, they’re hope.
Common pitfalls to avoid
- Treating the passphrase as a 13th or 25th mnemonic word. It is not selected from the BIP-39 wordlist and is not subject to the same checksum validation, so a typo produces a different valid-looking wallet instead of an error.
- Writing the passphrase in the same location as the seed phrase. This defeats the entire purpose; anyone who finds one finds both.
- Skipping the second-device recovery test. A passphrase that “works” on the original device only proves the device remembered your settings, not that your written backup is sufficient.
- Using a passphrase that’s case- or space-sensitive without noting the exact formatting. “Correct Horse” and “correct horse” derive entirely different wallets, and trailing whitespace on some apps is silently trimmed while others preserve it.
- Assuming the manufacturer can help if you forget it. There is no reset. Trezor, Ledger, Coldcard, and Blockstream all confirm this is by design, not a limitation they can patch.
- Entering the passphrase on an unverified or compromised computer. Prefer on-device entry whenever your hardware supports it.
- Funding the hidden wallet before testing recovery. Order matters: verify recovery on separate hardware first, move meaningful funds second.
- Forgetting the passphrase exists at all after years of dormancy. Document a recovery plan (Step 8) precisely because memory fades and life circumstances change.
Expected output at each stage
Knowing what a successful step looks like helps you catch problems early rather than discovering them months later. Here’s what you should see at each checkpoint.
| Stage | Expected result | Warning sign |
|---|---|---|
| Enabling passphrase feature | Device prompts for a passphrase on every subsequent connection | No prompt appears; feature toggle didn’t save |
| First passphrase entry | New, previously unseen receive address appears, balance shows 0 | Same address as your standard wallet appears (feature not actually active) |
| Test transaction | Balance updates to match the sent amount within 1-2 confirmations | Balance stays at 0 after confirmations clear on-chain |
| Second-device recovery | Identical balance and address appear using only seed + passphrase | Balance shows 0 or a different address entirely |
| Annual recovery drill | Same result as the original recovery test | Any discrepancy from the prior year’s result |
Troubleshooting
- The hidden wallet shows a balance of zero after I know I sent funds. Double-check the exact passphrase string, including capitalization and spacing; a single-character difference opens a different wallet entirely.
- My companion app doesn’t prompt for a passphrase at all. Confirm the passphrase toggle is actually enabled on the device (not just in the app), and that you’re running a firmware version that supports it; older firmware on some Ledger and Trezor units predates the feature.
- The device froze or restarted mid-passphrase-entry. Power cycle the device and re-enter the passphrase from scratch; a partial entry does not save or corrupt anything since the wallet is derived fresh each time.
- I get a different address every time I connect, even with the same passphrase. Check whether your wallet software’s derivation path setting changed (e.g., switching between native SegWit and legacy paths produces different addresses from the same passphrase-derived seed).
- My recovery test on a second device shows a different result than the original. Suspect a firmware or app-level default difference; check both devices’ passphrase-related settings side by side, including any “always ask” versus “ask once” toggle.
- I can’t remember if I used a trailing space in my passphrase. Some apps trim trailing whitespace automatically and others don’t; test both versions (with and without the space) on a spare device before assuming funds are lost.
- Ledger’s PIN-attached passphrase isn’t opening the hidden wallet. Confirm you’re entering the second PIN, not re-entering the first PIN with extra digits; the two are separate secrets tied to separate derivations.
- I set up a passphrase years ago and no longer remember which device or app version I used. Try the exact string on the most current version of the manufacturer’s official software first, since backward compatibility for BIP-39 passphrase derivation is standardized across BIP-32 and has remained stable since the spec’s adoption.
Advanced tips for institutional and high-value setups
For holdings large enough to justify extra operational overhead, consider combining a passphrase with multisignature setups rather than relying on either technique alone. A 2-of-3 multisig arrangement where one or more keys also uses a passphrase adds a meaningful layer, though it also adds real complexity and more places a mistake can happen, so this combination suits organizations with documented procedures rather than individual holders managing things from memory.
Some Coldcard users generate the passphrase itself using dice rolls mapped to a fixed wordlist, treating it with the same rigor as original seed generation rather than picking something memorable. This produces a passphrase with verifiable entropy at the cost of memorability, which is a reasonable tradeoff for cold storage that’s accessed rarely and where the physical backup medium is the primary access method rather than memory.
If you manage multiple hidden wallets under one seed for different purposes (savings, a business treasury, a decoy), keep a private, encrypted index mapping each passphrase’s purpose to a receive address checksum, never the passphrase text itself, so you can identify which wallet is which without re-deriving each one from scratch during an audit.
Complete working example: a two-tier cold storage setup
Here’s how the full setup looks in practice, combining every step above into a single reference project you can adapt.
Project: Two-tier hidden wallet on Coldcard Q1
--------------------------------------------------
1. Generate 24-word seed on-device (dice-seeded, verified against
device's own entropy check).
2. Engrave seed words on a steel backup plate. Store in home safe.
3. Enable Passphrase menu on Coldcard.
4. Generate Passphrase A ("decoy"): a 4-word Diceware phrase.
-> Fund with a small, spendable amount ($100-$200 equivalent).
-> This is the wallet you could disclose under pressure.
5. Generate Passphrase B ("primary"): a 6-word Diceware phrase,
stored in a sealed envelope at a separate location (e.g., a
bank safe deposit box), never alongside the steel seed backup.
-> Fund with primary holdings only after Step 6 below.
6. Recovery drill: wipe a spare Coldcard Mk4, restore using only
the steel-plate seed words plus Passphrase B retrieved from
the sealed envelope. Confirm balance matches Passphrase A's
*and* B's wallets independently.
7. Document: instruction sheet naming both storage locations,
without either passphrase written on it, held by an estate
executor or attorney.
8. Calendar reminder: annual recovery drill using steps 6-7.
--------------------------------------------------
Result: seed compromise alone exposes nothing. Passphrase A
compromise alone exposes only the decoy balance. Both are
required, from two different physical locations, to reach
primary holdings.
This structure isn’t the only valid design, but it demonstrates the core principle: no single stolen item, whether that’s the steel plate, a phone photo, or a sealed envelope on its own, should be enough to move real funds. The passphrase system only delivers that guarantee if you build the separation in from the start and actually test it, rather than assuming the math works out because the feature exists in the settings menu.
Adapt the number of tiers to your own situation rather than copying this exact three-location structure. A single person with modest holdings might reasonably collapse this down to one seed backup plus one memorized passphrase, skipping the decoy wallet entirely. A family office managing treasury funds for multiple stakeholders might add a third or fourth passphrase tier, each mapped to a different spending policy, with the recovery drill in Step 12 run separately against every tier rather than just the primary one. The scenario that should worry you isn’t complexity for its own sake, it’s a setup nobody has actually rehearsed recovering from.
Passphrase support in software wallets
Hardware wallets aren’t the only place BIP-39 passphrases work. Desktop software wallets like Electrum support entering a passphrase during wallet restoration, and Sparrow Wallet exposes the same option when you import a seed backed by a connected hardware signer. The mechanics are identical: the passphrase modifies the derived seed before any keys are generated, so a software wallet and a hardware wallet given the same 24 words and the same passphrase will produce the same addresses, since the derivation follows the same standardized path defined alongside BIP-39 in BIP-32’s hierarchical deterministic wallet specification.
The security tradeoff shifts, though. A software wallet running on a general-purpose computer or phone exposes the passphrase to that device’s memory and, potentially, to malware running alongside it, in a way a dedicated hardware wallet with a secure element doesn’t. Treat software-wallet passphrase entry as acceptable for a watch-only setup or for verifying a hidden wallet’s address on a machine you trust, but keep the device that actually holds signing authority for real funds limited to hardware with on-screen entry whenever your holdings justify the extra step.
One caveat worth flagging: not every wallet implements the passphrase field identically. A handful of older or non-standard wallet apps historically mislabeled a PIN or a wallet-file password as a “passphrase,” without actually feeding it into the BIP-39 derivation step. Before trusting a new piece of software with a passphrase-protected recovery, do a small test restore, exactly as described in Step 7, using that specific software rather than assuming compatibility because the field is labeled the same way.
Real-world scenarios where a passphrase earns its complexity
The extra setup time is easiest to justify against concrete situations rather than abstract risk. A traveler crossing a border where customs agents have, in some documented cases, compelled device unlocks can hand over a seed phrase for the standard wallet, which holds a believable but modest balance, while the funds that matter stay behind a passphrase nobody asked about. A household with a shared safe can store the seed phrase where a spouse or roommate could find it for legitimate reasons, while a business-critical treasury balance sits behind a passphrase known only to the account holder.
It also matters for anyone who has ever had a hardware wallet lost, stolen, or seized. The seed phrase alone recovers only the standard wallet in that scenario; the passphrase-protected balance requires the thief or seizing party to also know a second secret that was never written on the same medium and, ideally, never stored digitally anywhere at all. None of this replaces good physical security practice around the seed phrase itself, but it does mean a single point of physical compromise no longer automatically means total loss.
How this compares to other seed-protection methods
A BIP-39 passphrase isn’t the only way to add a layer beyond a raw seed phrase, and it’s worth knowing where it fits relative to the alternatives. Shamir’s Secret Sharing splits a single seed into multiple shares where a threshold number are needed to reconstruct it, which protects against loss of any one share but requires all shares to eventually come together at reconstruction time, unlike a passphrase, which never needs to be combined with anything beyond your own memory. Multisignature wallets distribute signing authority across multiple independent keys and devices, which protects against a single point of compromise but adds meaningfully more setup and transaction complexity than a passphrase does.
A passphrase is comparatively simple to set up and free on every device that supports BIP-39, but it places the entire burden of a second secret on one person’s memory or a second storage location, with zero tolerance for error. None of these approaches are mutually exclusive. Serious cold storage setups often combine a passphrase-protected seed with multisig, so that even a fully compromised device plus a leaked passphrase for one key still isn’t enough to move funds without additional signatures.
| Method | Setup complexity | Recovery requires | Best for |
|---|---|---|---|
| BIP-39 passphrase | Low | Seed + memorized/stored passphrase | Individual holders, plausible deniability |
| Shamir’s Secret Sharing | Medium | Threshold number of shares | Distributing trust across locations/people |
| Multisig (2-of-3, 3-of-5, etc.) | High | Threshold number of independent keys/devices | Businesses, high-value institutional storage |
| Passphrase + multisig combined | Very high | Threshold keys, at least one also passphrase-protected | Maximum security, treasury-grade holdings |
Frequently asked questions
Is a BIP-39 passphrase the same as my wallet’s PIN?
No. The PIN protects physical access to the device itself and, if entered incorrectly too many times, typically wipes or locks the device. The passphrase is a cryptographic input that changes which wallet gets derived from your seed words, and it isn’t checked or validated by the device at all; there’s no “wrong passphrase” error, just a different resulting wallet.
Can I add a passphrase to a wallet I’ve already been using for years?
Yes. Enabling the feature doesn’t touch your existing standard wallet or its funds. It simply means that from now on, entering any non-blank string at the prompt opens a new, separate hidden wallet derived from your same seed words. Your original funds stay exactly where they are, accessible the same way as before by leaving the passphrase field blank.
What happens if I forget my passphrase?
The funds in that specific hidden wallet become permanently inaccessible. There is no recovery mechanism, no manufacturer override, and no brute-force approach that’s realistic against a passphrase with reasonable entropy. This is why Steps 7 and 12 in this guide, testing recovery and repeating the drill annually, matter more than any other part of the setup.
Do I need a different passphrase for every hardware wallet brand?
No. Because BIP-39 passphrase derivation is a standardized part of the specification, the same seed words plus the same passphrase should produce the same wallet and addresses regardless of which supported manufacturer’s device you use, which is exactly why the second-device recovery test in Step 7 works even across brands.
Is it safe to type my passphrase into Trezor Suite or Ledger Live on my computer?
It’s less risky than typing your full seed phrase into a computer, since the passphrase alone doesn’t expose your base wallet, but it’s still preferable to enter it on the device’s own screen when that option exists, precisely to avoid any exposure to host-side keyloggers or compromised software.
Can someone brute-force my hidden wallet if they steal my seed phrase?
Only if your passphrase is weak. A short, dictionary-based passphrase is vulnerable to a determined attacker with GPU or cloud compute resources. A passphrase built with genuine entropy, such as a multi-word Diceware-style phrase or a long random string, is not practically brute-forceable with current computing methods, which is why Step 2 in this guide treats entropy as the single most important decision in the whole process.
Should I use the same passphrase across multiple hardware wallets for redundancy?
You can, as long as those devices also share the same underlying seed words; a passphrase paired with different seed words produces an entirely unrelated wallet. Many people set up an identical seed-plus-passphrase pair on two separate hardware wallet units specifically for redundancy, treating the second device as a tested backup rather than a daily-use wallet.
Does adding a passphrase protect me if my seed phrase and passphrase are both stolen together?
No. If both secrets are compromised at the same time, from the same location, the passphrase provides no additional protection, which is exactly why Step 11 in this guide insists on storing the passphrase somewhere physically separate from the seed phrase itself.
Will a firmware update on my hardware wallet ever change how my passphrase-derived wallet is calculated?
It shouldn’t, because the derivation follows the standardized BIP-39 and BIP-32 specifications rather than any proprietary logic a manufacturer controls. That said, this is exactly why the periodic recovery drill in Step 12 matters: it confirms, on a real device running current firmware, that nothing about the derivation has drifted, rather than trusting the standard’s stability as a matter of theory.




