Last reviewed: 22 July 2026 | What I checked: the BIP-32 and BIP-39 standards, the SLIP-39 spec, Bitcoin Core’s descriptor documentation, and current guidance from Trezor, Ledger and BitBox.
A hardware wallet company can close its doors without taking your crypto with it. That’s true, and it’s the part every headline stops at. The part that actually determines what happens to you is duller: what you backed up, which standard the wallet used, whether you added a passphrase, and whether anyone ever tested that the backup actually works.
Company failure is usually an inconvenience when you hold a verified, interoperable backup and understand your own wallet’s configuration. It becomes dangerous when the device was your only working copy, when the backup format got misunderstood, or when “compatible” never got checked against what it actually needs to mean.
The company was never holding your coins
A hardware wallet signs transactions. It doesn’t store your Bitcoin or your tokens; those live on their respective blockchains, recorded there regardless of whether the company that sold you the device still exists.
I went back through the BIP-32 and BIP-39 specifications for this piece, mostly to check exactly how much of the recovery story actually lives in the standard versus in a given vendor’s implementation of it. BIP-32 defines how a single master seed deterministically generates a whole tree of accounts and addresses. BIP-39 is the mnemonic layer on top: it turns entropy into the ordered word list you actually wrote down, then derives the seed from those words. Enter the same valid words, with the same passphrase and settings, on any device that implements the standard correctly, and you reproduce the same keys. That’s why a dead company doesn’t automatically mean dead funds. The relationship between your words and your addresses was never the company’s to hold.
“The seed works elsewhere” is true. It just isn’t the whole sentence. Recovery has layers, and the words are only the first one.
Four ways this actually plays out
If the company closes but your device still works, nothing changes today. The risk is slower: the companion app stops getting updates, the blockchain data service it relied on goes dark, an operating system update breaks compatibility, or a firmware bug never gets patched. Use the window while the device still works to verify your backup and plan a migration, rather than treating a working unsupported device as a permanent home.
If the official app disappears but the device itself is fine, Bitcoin and other widely standardized assets can usually still be signed through third party software, with the hardware keeping the keys offline as it always did. Support gets narrower the further you get from Bitcoin. A signer with broad Bitcoin wallet support can have almost no third party options for a specific altcoin or staking setup, and a valid 24 word phrase does not guarantee any given replacement app knows every account type the original software created. I haven’t personally tested every vendor’s cross compatibility claim device to device; this is their own documentation, so treat “supports the same format” as vendor reported until you’ve checked it against your specific model.
The real test comes if the device itself fails after the company is already gone. With a standard backup, you can usually restore on another manufacturer’s hardware that supports the same format, entering the words on the new device’s own screen, never into a website, an app, a note, or an “emergency recovery” tool someone is advertising. A vendor collapse is exactly the kind of moment that produces convincing phishing pages, aimed at people who are frightened and searching for a replacement fast.
And if there’s no usable backup anywhere, the company’s health was never really protecting you. No manufacturer can rebuild a self custody wallet from your name, your receipt, or your device’s serial number. A working device with no backup can still let you move funds to a freshly generated wallet. A dead device with no backup usually can’t. The company closing didn’t cause that; it just exposed a gap that already existed.
Why a correct restore can still show you an empty wallet
People restore, see a zero balance, and assume the funds are gone. Usually the new wallet just derived or displayed a different account than the one they meant.
The most common cause is a passphrase that was skipped, mistyped, or entered with different capitalization. A BIP-39 passphrase isn’t part of the twelve or twenty four words; it’s combined with them to derive the seed, and every distinct passphrase, including a stray space, is a distinct wallet. Trezor’s own documentation is blunt about this: the passphrase is never stored on the device and cannot be recovered if forgotten. It has to be entered exactly, every time.
The second cause is a derivation path mismatch. The seed is the root of a whole tree of accounts, not one address, and different wallet software can walk that tree differently. A replacement app might derive the right seed and still fail to check the specific branch your funds actually sit on, especially for older Bitcoin address types or a multi chain setup with several account indexes.
The third cause is a backup standard mismatch. Not every word list is BIP-39. Trezor’s newer twenty word backups use SLIP-39, and the SLIP-39 spec itself says plainly that it’s meant to replace BIP-39, not extend it; the two are largely incompatible. Feeding a SLIP-39 share into software that only understands BIP-39 will not work, no matter how confident the interface looks while you’re doing it.
And if the wallet was multisignature, one seed may only be one signer inside a larger policy. You can hold every private key you’re supposed to and still fail to reconstruct the addresses without the quorum rule, the other signers’ extended public keys, and the wallet descriptor that describes how the whole thing was assembled. Back that descriptor up separately from the seeds themselves. It generally can’t spend anything by itself, but losing it can turn an otherwise clean recovery into a genuine puzzle.
What to write down before any of this happens
You don’t need a forensic binder. You need a record that keeps public configuration separate from secret material.
- Backup format: BIP-39, SLIP-39, or a vendor specific scheme, including word count and share threshold.
- Passphrase status: whether one exists, stored securely and separately if your threat model allows written storage at all.
- Wallet structure: which chains, accounts, address types, and any non default derivation paths.
- A few verified receive addresses, so a future restoration can be checked against something concrete.
- Multisig configuration: the descriptor, quorum, and signer fingerprints, if relevant.
- Software dependencies: the actual project names and repositories you use for altcoins, staking or DeFi, not a download mirror you found once.
- An inheritance note telling a trusted person what exists and where the instructions live, without putting the secret itself in the same place.
That’s the list. It isn’t exciting, and it doesn’t need to be. Don’t store the recovery phrase next to this document, though. One tells you where to look. The other authorizes spending.
If a wallet company actually announces it’s closing
- Don’t rush to type the seed anywhere. The first wave of “recovery” links and support accounts will include scams.
- Confirm the device and the official app still work, using your existing trusted install, not a newly discovered download.
- Verify the backup on the hardware device itself, before wiping, upgrading, or experimenting with anything.
- Record the public configuration: account types, receive addresses, derivation details, multisig descriptors.
- Pick a genuinely compatible replacement, meaning it supports your backup standard and your actual assets, not just a matching word count.
- Restore on trusted hardware, entering the words on the device screen.
- Check addresses against your records before moving anything.
- If the seed was ever typed into ordinary software or an untrusted device, treat it as burned and generate a new one.
A company can promise lifetime support. Whether it still exists in five years is a different question, and the backup is what answers it either way.
Methodology and limitations: this explains recovery architecture in general terms; it isn’t a guarantee that every asset supported by one wallet is discoverable in another, which depends on application support as much as the underlying key standard. I reviewed the BIP-32 and BIP-39 specifications, the SLIP-39 standard, Bitcoin Core’s descriptor documentation, and current recovery guidance from Trezor, Ledger and BitBox for this piece, checked 22 July 2026. For the broader buying framework, see Best Hardware Wallets in 2026. My sourcing and corrections standards are covered in full at How This Research Works.
Disclosure: educational content, not individualized security, legal or financial advice. Never send a recovery phrase to Cryptophia Research, a wallet manufacturer, or anyone claiming to offer support.
