Exchange API Keys: A Secure Handover Playbook for Account Buyers

When most buyers think about taking ownership of a verified exchange account, they think about passwords, two-factor authentication, and recovery options. Those matter. But the API key surface is almost always the most overlooked attack vector in the handover, and it is the surface most likely to cause expensive surprises in the days and weeks after the trade closes. An old API key with the wrong permissions, left lingering in someone else's automation, can drain an account long after every other credential has been rotated.

This article is a step-by-step playbook for handling API keys during and after a verified-account handover. It is written for buyers who are inheriting accounts from previous owners, but the same principles apply to anyone who manages multi-venue trading infrastructure.

Why API keys are different

Passwords get rotated and the rotation kills any old session. API keys do not work the same way. Each key is an independent credential, scoped to specific permissions, often whitelisted to specific IP addresses, sometimes linked to specific sub-accounts, and active until explicitly revoked. A seller who created twenty API keys over the life of an account leaves twenty independent attack surfaces. Rotating the password does not touch any of them.

Worse, API keys are often the credential most likely to have been leaked through carelessness during the seller's tenure - shared with a third-party bot, pasted into a screenshot, dropped into a public Github repo by accident, stored in plaintext on a compromised laptop. The new owner inherits whatever state the seller left behind, including any keys that may have been compromised but not yet exploited.

Step one: inventory every key before rotation

The first action after taking control of an account is to log into the API management page and screenshot every existing key, its label, its permissions, its IP whitelist (if any), and its creation date. Do this before you change anything. The inventory is your audit trail for what was inherited, and it is what you reference if anything strange happens in the next few weeks.

Step two: revoke every existing key

Once you have the inventory, revoke every existing API key. All of them. No exceptions. Do not preserve "the bot key" or "the analytics key" because you assume they are still needed. If a previous workflow required an API key, recreate that key fresh under your own control with appropriate permissions. The friction is small. The security gain is enormous.

Revocation should be immediate and complete. On most exchanges, the revoke button is in the same UI as the keys themselves. On a handful of exchanges, revocation requires email or SMS confirmation, so make sure your control of those channels is established before you start.

Step three: scope new keys to the absolute minimum

When you create new API keys, apply the principle of least privilege ruthlessly. A read-only key for analytics does not need trading permissions. A trading key does not need withdrawal permissions. A withdrawal key (if you genuinely need one, and you usually do not) should be IP-whitelisted to a single static IP and rate-limited as aggressively as the exchange allows.

Most exchanges expose granular permission flags: read account, read orders, read positions, place orders, cancel orders, withdraw, transfer between sub-accounts, futures vs spot, margin enable, lending enable, options enable. Default to read-only and only escalate when a specific workflow requires it. Each escalation is a security decision worth pausing on.

Step four: enable IP whitelisting

IP whitelisting is the single highest-leverage security control on most API keys. A key that only works from one static IP address is dramatically harder to abuse if it leaks than a key that works from anywhere. For automated infrastructure, this is usually easy - your server has a static IP and you whitelist it. For more dynamic setups, a small bastion or NAT gateway gives you a stable egress IP at minimal cost.

Some exchanges allow IP whitelisting on every key; others restrict it to certain key types or higher account tiers. Where it is available, use it. Where it is not available, treat the key as more sensitive and rotate it on a more aggressive schedule.

Step five: store keys in a real secret manager

Once new keys are created, store them in a real secret manager - AWS Secrets Manager, HashiCorp Vault, Doppler, 1Password Secrets Automation, or equivalent. Do not paste them into a .env file that lives in a git repo. Do not store them in a notes app. Do not message them to yourself on Telegram. The number of leaked exchange keys we have seen recovered from each of these locations is depressing.

Step six: log and monitor

Every exchange exposes some form of API activity log. Pull those logs into your own monitoring system or, at minimum, set calendar reminders to review them weekly for the first month after handover. Alerts for unusual activity - first-time IP, first-time withdrawal, unusual order size - are cheap to set up and disproportionately valuable.

Step seven: schedule rotations

API keys are not "set and forget." Build a rotation schedule into your operations - quarterly at a minimum, monthly for higher-value or higher-permission keys. The rotation discipline limits the blast radius of any key that quietly leaks between rotations, and it keeps your overall key inventory healthy. Most teams that have had a serious key compromise discover, in the post-mortem, that the leaked key had been alive for years without rotation.

Common mistakes

Three mistakes show up over and over. First, preserving the seller's API keys "to keep the bot running." Second, creating new keys with full permissions because that is the default. Third, storing keys in plaintext somewhere convenient. Each of these is the kind of shortcut that feels harmless until it is catastrophic.

A fourth, subtler mistake is failing to disable any sub-account that was tied to a seller's previous workflows. Sub-accounts can have their own keys, their own permissions, and their own balances. Walk through the sub-account list during handover and audit each one. If a sub-account is not in your plan, archive or close it.

Why this matters for verified-account buyers

Verified accounts carry value precisely because they unlock high limits, fiat rails, and advanced products. That value is exactly what makes their API keys attractive targets. A buyer who runs a proper handover playbook inherits the upside without inheriting the latent risk. A buyer who does not is, in effect, running on someone else's security posture - and that posture is rarely as good as it should be.

Final word

API key hygiene is the unsexy work that quietly distinguishes the operators who never lose money to credential mishaps from the ones who eventually do. Spend the forty-five minutes during handover to inventory, revoke, recreate, scope, whitelist, store, monitor, and schedule. The discipline pays for itself many times over the first time anything goes wrong - and even when nothing goes wrong, you sleep better.

Treat every key like it is going to leak tomorrow. Most of them never will. The few that do will not matter, because you scoped them properly to begin with.