Glossary — hardware wallet, seed phrase, secure element & key terms
Quick glossary: what this page covers
This glossary explains the technical terms you’ll see in setup guides, reviews, and troubleshooting pages for hardware wallets. I wrote this from hands-on testing and reading primary specs (BIPs, SLIPs, NIST). You’ll get plain-language definitions, short how-to guidance, and links to deeper guides elsewhere on the site (for example, see seed phrase, secure element, and firmware updates).
Seed phrase — meaning and BIP-39 definition
A seed phrase (also called a recovery phrase) is a human-readable list of words that encodes the entropy used to derive your private keys. The most widely used standard is BIP-39, which defines how words map to binary entropy and how the phrase is converted into a binary seed that wallet software uses to derive accounts (BIP-32/BIP-44) [1][2].
Why care? Because the seed phrase is effectively the master key to your non-custodial funds. Lose it, and you lose access (unless you have another copy). Store it securely.
Sources: BIP-39 (spec) and BIP-32 (HD wallets) explain the math and the PBKDF2 step that turns mnemonic+optional passphrase into a seed [1][2].
12 vs 24 words: quick comparison
| Seed length |
Entropy bits |
Typical trade-offs |
| 12 words |
128 bits (plus checksum) |
Easier to write; less entropy but still practically secure today. See BIP-39 for exact maths [1]. |
| 24 words |
256 bits (plus checksum) |
Higher entropy, favored for long-term cold storage; longer to transcribe. |
In my experience, many long-term holders opt for 24 words because it reduces brute-force risk margin over many decades. But 12 words remain widely used and acceptable for everyday security needs.
Passphrase (25th word): benefits and risks
BIP-39 supports an optional passphrase that is combined with the seed phrase in the derivation step. People sometimes call this a "25th word." It acts as an additional secret — effectively creating a second seed that’s only recoverable with both the phrase and the passphrase [1].
But there’s a trade-off. If you forget or lose the passphrase, funds become unrecoverable (no vendor or court can restore it). So, only use a passphrase if you can reliably back it up (see passphrase (25th word)).
Secure element — definition and role
A secure element is a tamper-resistant microcontroller designed to store cryptographic keys and perform sensitive operations inside an isolated environment. It’s not a marketing term — it’s a class of hardware often certified under standards like FIPS 140 or Common Criteria [3][4].
A secure element protects private keys from being read even if the rest of the device is compromised. That said, implementation matters (how keys are used, firmware checks, and supply-chain security all affect real-world safety). For a deeper discussion see secure element.
Sources: FIPS 140 and Common Criteria summaries explain what tamper resistance means in practice [3][4].
Firmware — definition and how to verify updates
Firmware is the device-level program that runs the wallet: UI, transaction construction, and hardware access. Firmware updates add features and fix bugs. But updates are also an attack vector if attackers can push malicious firmware.
A secure update process uses cryptographic signatures: the update package is signed by the vendor (or a key managed by the vendor) and the device verifies that signature before applying the update. You should verify firmware authenticity and follow a documented verification process (see firmware updates and verify firmware).
For design guidance, see NIST and OWASP recommendations on secure firmware update practices [5][6].
Air-gapped explanation — offline signing workflows
Air-gapped means the signing device is physically isolated from the internet. How does it work in practice? You prepare a transaction on an online machine, export it to the offline wallet (QR, microSD, or USB), sign the transaction on the air-gapped device, then import the signed transaction back and broadcast.
This reduces remote attack surface, because private keys never touch an internet-connected computer. But it adds friction and requires careful handling of exported data (PSBT format — BIP-174 — is commonly used for partially signed Bitcoin transactions) [7].
See air-gapped and air-gapped-signing for step-by-step guides.
And yes, air-gapped setups are slower and require more attention to detail.
Multi-signature (multisig) glossary
Multi-signature setups require multiple independent keys to sign a transaction (for example, 2-of-3). Multisig reduces single-point-of-failure risk and helps with shared custody, geographic separation, and inheritance planning.
Important technical points:
- Multisig relies on script types (P2SH, P2WSH, etc.) and wallet compatibility varies. Check multisig compatibility and signing formats before you set up [8].
- PSBT (BIP-174) standardizes partially signed workflows, which makes multisig across different software/hardware easier [7].
If you’re considering multisig, read multisig, multisig setup, and multisig compatibility.
Backup methods: metal plates, SLIP-39, and best practices
Common backup options:
- Paper: cheap but vulnerable to fire, water, and decay.
- Metal backup plates: resist fire and water; popular for long-term cold storage. I’ve used a metal plate in combination with geographic separation (one copy in a safe, another in an off-site deposit box). See metal backup plates.
- Shamir Backup (SLIP-39): splits a seed into shards using Shamir’s Secret Sharing; you need a quorum of shards to recover the seed. SLIP-39 spec explains parameters and trade-offs [9].
Keep backups offline, avoid photos or cloud storage, and test recovery on a testnet or spare device before trusting a backup method in production.
Connectivity trade-offs: USB, Bluetooth, NFC, air‑gapped
| Connection |
Convenience |
Attack surface |
Notes |
| USB |
High |
Medium (USB firmware attacks exist) |
Common desktop workflow; watch for BadUSB-style risks [10]. |
| Bluetooth |
High (mobile) |
Higher (wireless interception/relay risks) |
Requires pairing; follow vendor and NIST Bluetooth guidance [5]. |
| NFC |
Low–Medium |
Low–Medium |
Short range, useful for quick mobile taps; still a wireless channel. |
| Air‑gapped |
Low |
Low (best remote risk reduction) |
Best for long-term cold storage, higher friction. |
Read connectivity-usb-bluetooth-nfc before choosing a model.
Common mistakes & quick checklist
- Don’t buy from unofficial sellers — tampering risk (see where-to-buy-safely).
- Never store your seed phrase in cloud services or on photos.
- Verify firmware signatures before updating (see verify-firmware).
- Test your recovery procedure on a spare device before you store large amounts (see restore-recovery).
My rule of thumb: assume user error is likelier than device breakage; design backups and access around that assumption.
FAQ — real user questions
Q: Can I recover my crypto if the device breaks?
A: Yes, with your seed phrase you can restore to another compatible wallet (follow the steps at restore-recovery). Test this in advance.
Q: What happens if the company goes bankrupt?
A: Your private keys are non-custodial; as long as you control your seed phrase and follow standard derivation schemes (BIP-32/BIP-44), you can restore funds independent of the company (see company-failure-recovery).
Q: Is Bluetooth safe for a hardware wallet?
A: Bluetooth adds convenience but increases attack surface. Follow pairing best practices, firmware verification, and consult connectivity-usb-bluetooth-nfc. NIST Bluetooth guidance is helpful here [5].
Q: Can I use a passphrase and still recover if I forget it?
A: No — losing the passphrase is effectively losing access to funds secured by that passphrase. See passphrase-25th-word.
Q: Does multisig remove the need for backups?
A: No — multisig reduces single-key risk but you still need reliable backups of each required signing key or shard. See multisig-setup.
Conclusion & next steps
Glossaries are most helpful when paired with hands-on guides. If you’re starting: follow a step-by-step setup and test restore on a small amount first (see getting-started and setup-initial).
But don’t rush—security is about repeatable processes. If you want a deeper technical reference, read the specs linked below and the multisig and firmware pages on this site.
References
- BIP-39 — Mnemonic code for generating deterministic keys: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
- BIP-32 — Hierarchical Deterministic Wallets: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
- FIPS 140-2 — Security Requirements for Cryptographic Modules: https://csrc.nist.gov/publications/detail/fips/140/2/final
- Common Criteria / ISO/IEC 15408 — Evaluation for IT security: https://www.commoncriteriaportal.org/
- NIST SP 800-121 Rev.2 — Guide to Bluetooth Security: https://csrc.nist.gov/publications/detail/sp/800-121/rev-2/final
- OWASP — IoT and firmware security guidance: https://owasp.org/www-project-internet-of-things/
- BIP-174 — Partially Signed Bitcoin Transactions (PSBT): https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
- Bitcoin Wiki — Multisignature: https://en.bitcoin.it/wiki/Multisignature
- SLIP-0039 — Shamir Backup (Shamir Secret Sharing for Mnemonics): https://github.com/satoshilabs/slips/blob/master/slip-0039.md
- US‑CERT / BadUSB advisory and USB risks: https://www.us-cert.gov/ncas/alerts/TA14-012A
Ready to apply these terms? Start with the getting started guide or review device-specific setup steps at device-overview.
