A hardware wallet protects the private keys used to sign transactions for your self-custodied assets; an API key for a centralized exchange gives software permission to act on a separate exchange account. Owning or unplugging a hardware wallet does not automatically block orders made with an active exchange API credential. Map custody, transaction signing, account login and API permissions separately, including how each authority ends.
Start by identifying which system will accept the next instruction. A blockchain transaction, an exchange login and an API order can each pass different checks. Protecting one check does not automatically put it in front of the others.
Locate custody before comparing keys
In a self-custody wallet, assets are recorded on the blockchain. The hardware device protects the private keys that authorize transactions from the addresses it controls. Trezor describes signing inside the device and returning the signed transaction to connected software for broadcast; the assets themselves are not physically inside the device. Trezor’s hardware-wallet explanation.
A custodial exchange account has a different custody arrangement. For example, Kraken explains that exchange deposits enter its corporate wallets, with withdrawals handled by its wallet infrastructure. Its exchange and its self-custodial wallet are separate products. A balance displayed in the exchange account does not mean your personal hardware wallet holds the private keys for that balance. Kraken’s exchange and wallet distinction.
When you send assets from a hardware-controlled address to an exchange deposit address, your device approves that outgoing transaction. After settlement and exchange crediting, subsequent trading of the credited balance follows the exchange’s account controls. The signature on the deposit does not require your hardware wallet to approve every later exchange order.
Moving assets in the other direction requires a withdrawal through the exchange and confirmation that the intended address received them. Merely adding a hardware-wallet address to an address book changes neither custody nor existing API authority.
Separate the credentials by what verifies them
Keep a non-secret inventory of these authorities. Record labels and scopes, never the secrets themselves.
| Authority | What accepts the proof | What it can affect | How to review its boundary |
|---|---|---|---|
| Blockchain transaction key | The blockchain’s transaction rules | Assets and contract actions authorized by that key | Identify the address, chain and exact transaction being signed |
| Wallet backup, plus any required passphrase | A compatible wallet can reconstruct the signing keys | Access to the same wallet without the original device | Review backup security separately from the device PIN |
| Exchange account login | The exchange’s account authentication system | The account actions available to that authenticated session | Check authentication, recovery methods and active sessions |
| Exchange API credential | The exchange’s API authentication and permission checks | The accounts, products and actions within its scope | Inspect permissions, restrictions and provider revocation controls |
A wallet backup is especially easy to overlook. Trezor warns that someone with the required backup material can access the wallet without the original device. A device PIN protects the device’s access path; it does not make an exposed backup unusable. Trezor’s wallet-backup guidance.
For a concrete API example, Binance Spot distinguishes TRADE, which covers placing and canceling orders, from USER_DATA, which covers private account information. Its documentation permits separate trading and monitoring keys. These are Binance’s categories, so read another venue’s actual scope definitions rather than copying the labels. Binance Spot request security.
The word “signature” can cause another mix-up. Binance documents HMAC, RSA and Ed25519 request-authentication examples. A signed API request proves something to the exchange API; it is not thereby a blockchain transaction signed by your wallet. The verifier and the delegated permission determine what that signature can do. Binance’s API-signature examples.
An API secret stored by a separate application does not move inside your hardware wallet when you plug the device into the same computer. If a setup claims hardware-backed API signing, identify the supported key type, the signing integration and the confirmation policy. Ordinary wallet setup alone establishes none of those facts.
Hardware login protection is a separate job
Some hardware wallets can also act as security keys for supported service logins. Trezor documents FIDO2 and U2F functionality, with capabilities depending on the model. That is a login-authentication role. It does not automatically require the same device to approve every request from an already-issued exchange API credential. Trezor’s security-key documentation.
Binance.US makes the delegation explicit: enabling API trading can let the credential holder initiate trades without a fresh permission request for each action. Its API-key creation process includes account authentication, but creation and subsequent credential use are different events. Binance.US is a separate provider from Binance. Binance.US API-key guidance.
Do not turn that distinction into a blanket claim that APIs can never have additional authentication. Kraken documents an API-key-specific 2FA setting and warns that third-party compatibility must be checked. The useful test is whether the exact API credential and consuming application enforce an additional control. A hardware device registered for browser login is insufficient evidence. Kraken’s API-key 2FA documentation.
Likewise, changing an exchange login password is not proof that every API credential ended. Check the venue’s documented behavior and inspect its credential inventory. Treat the login and API paths as separate until evidence establishes their relationship.
Follow a deposit and an unwanted order
This hypothetical example uses a cash-only spot account with no borrowing or linked collateral. It is an accounting and permission exercise, not a recommended allocation or a report of an incident.
Start with 8,000 quote-token units in a hardware-controlled wallet and 2,000 at an exchange. Assume the quote token stays worth $1 throughout. The exchange has a monitoring key, R, and a spot-trading key, T. T has no withdrawal or transfer permission. The wallet keys and backup remain secure.
The owner sends 1,000 units to the exchange. Assume the transfer has settled and the exchange credited the correct account. Ignore network fees for this illustration. Then an unwanted but validly authenticated API order buys 100 units of asset X at 20 quote units each, with a hypothetical 0.10% fee charged in quote. There is no extra spread or slippage in the stated fills.
| Step | Self-custody balance | Exchange state | Authority that matters |
|---|---|---|---|
| Before deposit | 8,000 quote units | 2,000 quote units | Wallet key controls the external balance; T can trade the exchange balance |
| Deposit credited | 7,000 quote units | 3,000 quote units | The wallet signed the deposit; T can now trade the larger credited balance |
| Device unplugged | 7,000 quote units | 3,000 quote units | Disconnecting the device does not revoke T |
| Buy fully filled | 7,000 quote units | 998 quote units and 100 X | Exchange accepts T’s authenticated order under its permissions |
| T revoked, X marked at 18 | 7,000 quote units | 998 quote units plus X worth 1,800 | T loses future access once revocation is effective; existing holdings remain |
The purchase notional is 100 × 20 = 2,000. The fee is 2,000 × 0.001 = 2, leaving 3,000 − 2,000 − 2 = 998 in quote. At a mark of 18, X is worth 100 × 18 = 1,800. The exchange account is worth 2,798, and the combined marked value is 7,000 + 2,798 = 9,798, a decline of 202 from 10,000. This excludes any later sale fee.
Nothing had to leave the exchange for the loss to occur. The hardware-controlled balance remained outside T’s authority, while the credited deposit increased the balance it could trade. Revoking T does not reverse the fill, return the deposit or automatically revoke R.
The 3,000 balance is specific to this simplified account. It is not a universal loss cap for a trade-enabled key: margin, borrowing, shared collateral or broader account access change the analysis. The exchange API-permission guide covers those scope questions in more detail.
Unplugging also leaves on-chain delegations intact
Hardware signing has its own persistent-permission problem. A device can protect a private key while the owner uses that key to grant a contract spending authority.
For standard ERC-20 tokens, approve establishes a spender allowance, and transferFrom provides the mechanism for spending under authorization. Once that authority exists, an eligible spender can use it without another owner signature for each transfer. Unplugging the owner’s hardware wallet does not erase the allowance. ERC-20’s approval and transfer specification.
This is why a device confirmation is evidence that an action was signed, not proof that its consequences are harmless. The permit-versus-approval comparison explains how different authorization paths can leave spending authority behind. Identify the token, spender, chain and amount before signing, and inspect current authorization when retiring access.
Also ask whether the spender’s behavior can change. OpenZeppelin’s proxy documentation explains how an implementation can be replaced while the proxy address stays the same. A hardware wallet cannot establish that a familiar address will retain the same logic. Review the relevant upgradeable-contract admin risk separately from your device’s key protection. OpenZeppelin’s proxy upgrade pattern.
Rehearse the action that actually ends access
For an API credential, find the exchange’s official revocation control before connecting software. If that credential is exposed, revoke it through the provider promptly, then inspect accepted orders, fills and positions. Do not assume removing a saved connection also invalidates a copied credential. Use the API-credential incident worksheet for containment and account reconciliation.
For an exchange login, review the provider’s session and authentication controls. For a wallet, distinguish a lost device from exposed signing material. Resetting a device does not remove a copied private key’s authority over the same address. Wallet-key exposure needs its own secure recovery or migration process; exchange API revocation cannot repair it.
Complete these four lines for each connection you intend to use:
- Custody: name the exact exchange account or blockchain address holding the assets. Record when a deposit or withdrawal actually changes that location.
- Signing: identify the message being approved and its verifier. Distinguish a blockchain transaction, a login challenge and an exchange API request.
- Delegation: list what software or contracts can do after that approval. Include permitted products, balances, allowances and any additional authentication.
- Termination: write the official control that ends each permission and the evidence you will check afterward. Keep completed revocation separate from unresolved orders or holdings.
Keep seed phrases and primary wallet private keys out of API-connection forms. Before relying on a hardware wallet to stop an action, name the precise check that would require it. If the exchange accepts the instruction using an API credential alone, that credential needs its own permission limit and revocation route.