Move Crypto Safely After a Supply-Chain Incident

You've heard something concerning about a hardware wallet, maybe a news report, a forum post, or a manufacturer advisory. Now you're wondering whether your funds are safe and what you should actually do.

That's a reasonable question. The answer depends on one thing you need to figure out first: whether this is a routine wallet migration or a response to a possible compromise. The steps are similar, but the urgency and some of the precautions differ meaningfully. This guide walks you through both.

Before you start: assess the risk

Self-custody means you control the private keys directly. No exchange, no intermediary. Transactions are signed locally on your device and broadcast to the blockchain. That control is the point. It also makes a compromised device a serious problem.

A hardware wallet generates and stores private keys offline, signing transactions internally without ever exposing those keys to an internet-connected environment. Most of the time, that design is exactly what protects you. But supply chain incidents, in which a device is tampered with before it reaches you, can undermine that protection at the hardware or firmware level.

Before you move anything, verify the original disclosure. Initial triage should confirm the affected product and legal entity, the incident dates, the applicable firmware or device population, and whether any confirmed compromise actually exists. Warning signs worth checking include unexpected firmware or software changes, provenance or serial-number mismatches, anomalous account activity, and vendor communications that cannot be authenticated through official channels.

Here's why this matters. If your recovery phrase, the 12- or 24-word backup that can regenerate your keys, may have been exposed, simply transferring your assets to a new wallet on the same device does not resolve the underlying risk. Anyone who holds your seed phrase controls your funds. A migration to a genuinely clean device is the only way to break that exposure path.

If you have no reason to believe your recovery phrase was exposed and the incident does not appear to affect your specific device or firmware version, a standard migration still makes sense as a precaution. The steps below apply either way.

Prepare and verify the destination

Don't send a single satoshi until you've verified where it's going.

A hardware wallet setup generates a public-private key pair within the device. The private key stays on the device; the companion app receives unsigned transaction data. That's the model you're trusting. Before you trust it, confirm a few things:

• Purchase channel. Buy from the manufacturer's official store or an authorized reseller. Verify the device's exact model and confirm it arrived sealed and uninitialized. A device that shows signs of prior activation is a red flag.

   

• Official setup flow. Follow the manufacturer's documented setup process, not a tutorial you found on a third-party site. During setup, generate your recovery words on the device itself. Reject any device or process that offers you a pre-generated phrase. That's a known attack vector.

   

• Asset and network support. If you plan to move USDT, for example, the destination wallet must support it on its intended blockchain network. The same asset can exist on Ethereum, Tron, Solana, and other chains. Sending crypto to the wrong address type or the wrong blockchain can permanently lose funds. Chains are not interchangeable.

   

• Recovery backup. Before any large transfer, secure your recovery information. You'll need it to restore access if the device is later lost, stolen, or damaged.

   

• Test the receiving address. After setup, generate a receiving address on the device and verify it independently through the wallet's trusted interface. Compare it character by character, not just the first and last few.

Step-by-step migration

Work through these in order. Don't skip the test transfer.

1. Generate and verify the destination address. Open the new wallet's app, navigate to the relevant asset, and generate a receiving address. Verify this address on the device itself or through the wallet's trusted interface. Copy it carefully. A single wrong character sends funds to an address nobody controls.

2. Check network compatibility. Confirm you're sending on the correct network. If you hold USDT, for example, it exists on multiple chains (Ethereum, Tron, Solana, and others). Sending crypto to the wrong address type or blockchain can permanently lose funds. The sending platform and the receiving wallet must agree on the network before you proceed.

3. Account for fees. Network fees vary by chain and by congestion. Check the current fee estimate in your sending app before you commit. Most wallets offer fee presets (slow, market, fast) and show an estimate before you confirm.

4. Send a small test amount first. Always perform a test transaction with a small amount before transferring your full balance. The specific amount doesn't matter much. It only needs to confirm the process works. Wait for the transaction to confirm on the blockchain before continuing.

5. Verify receipt on a block explorer. A blockchain explorer lets you verify a transfer independently using the destination address or transaction hash. Paste the destination address into the relevant explorer (for example, Etherscan for Ethereum assets, or the equivalent for your chain) and confirm the test amount arrived. This step is not optional.

6. Transfer the remaining balance. Once you've confirmed the test transfer, repeat the process for the remaining amount. Keep the same network, destination address, and fee logic. Verify each transaction on the explorer before moving on to the next asset.

7. Note the transaction hash for each transfer. You'll need these for the post-transfer verification step. Most wallet apps record transaction history including amount, fees, and status, with a link to the block explorer.

Here's the honest issue with multi-asset migrations: each asset on each network is a separate transaction. ETH and ERC-20 tokens both live on Ethereum, but each token transfer is its own transaction with its own fee. Plan for that before you start.

After the transfer

Verification doesn't end when the transaction is broadcast. Once a transaction confirms on the blockchain, the receiving wallet app should reflect the updated balance. For example, if you moved ETH and an ERC-20 token, confirm both on the block explorer. Cross-check that balance against the block explorer independently. The app and the explorer should agree. If they don't, investigate before moving additional funds.

Token approvals. If the old wallet interacted with any decentralized applications, it may have granted on-chain token approvals that remain active. Switching devices or uninstalling the wallet does not revoke those allowances. Review and revoke any unnecessary approvals on the correct network using a reputable approval management tool before retiring the old wallet.

Secure the old device. Keep the old device powered off until the new wallet setup and access are fully verified. Then factory-reset or retire it using the device manufacturer's official instructions. After resetting, verify that only the initial setup screen remains before disposal or transfer.

Protect your recovery material. Never store a seed phrase online, in cloud storage, in email, or in a chat. Never share it with anyone, including support staff. If the old phrase may have been exposed, treat it as compromised regardless of whether you've completed the migration.

How Tangem's Design Reduces Specific Attack Vectors

Tangem Cold Wallet is a self-custodial hardware wallet that stores private keys offline on an NFC-enabled physical card. Several design choices are directly relevant to supply-chain risk. They are not guarantees, but they structurally reduce specific attack vectors.

No updatable firmware. Firmware is factory-installed and non-updatable. Tangem states it cannot be modified after production. This eliminates remote-exploit vectors that depend on malicious firmware updates. That matters when supply-chain tampering can include firmware modification.

Seedless-by-default setup. The recommended setup does not generate a seed phrase. Two or three cards share the same private key and serve as backups. This removes the recovery-phrase exposure path entirely from the default model. You can choose to generate a 12- or 24-word BIP39 phrase instead. That choice reintroduces seed-phrase vulnerability alongside the recovery option.

No USB, no Bluetooth, no battery. The card connects only via NFC, with a 0-5 cm tap range for signing. There's no port for a malicious cable, no wireless radio for remote exploitation, and no firmware-update channel to compromise.

App authenticity check. The app verifies the authenticity of the card and its firmware before any operation to protect against counterfeit devices. The Tangem app also warns users if a card was activated before they received it. That is a direct signal of potential supply-chain interference.

Independent audits. The product documentation lists independent security audits by Kudelski Security in 2018, Riscure in 2023, and Cure53 in 2026. The wallet app for iOS and Android is open source on GitHub.

The risks that remain are real. Without a seed phrase, losing all backup cards permanently removes access to funds. There is no recovery path. The card design also requires physical proximity for every signing operation, which means NFC range is a practical constraint. Phishing, malicious approvals, and user error are not eliminated by hardware design. The secure element certified at Common Criteria EAL6+ protects the key material, but an attacker who obtains your card and your access code still has a meaningful asset.

No wallet design is unhackable. These choices reduce specific vectors. Understanding which ones helps you decide whether the trade-offs fit your situation.