Crypto Exchange Security: Protecting Your Account

Centralized exchanges (CEXes) hold hundreds of billions of dollars in customer cryptocurrency. They are also among the most consistently attacked, persistently compromised, and catastrophically failed financial institutions in history. Unlike a bank, a compromised exchange account has no fraud reversal mechanism, no government deposit insurance, and often no effective customer support pathway capable of acting before your funds are gone.

The history of exchange failures is instructive not because the attacks were technically sophisticated — most weren't — but because the same fundamental failures repeat across a decade of incidents. Understanding those failures gives you a clear picture of what to protect against and, critically, what no amount of individual security hygiene can protect you from when an exchange itself fails.

The History of Exchange Disasters

Understanding why exchange security matters requires confronting what has actually happened, with real numbers.

Mt. Gox: 850,000 BTC, 2011-2014

Mt. Gox was launched in 2010 by Jed McCaleb and acquired by Mark Karpelès in 2011. At its peak in 2013, it handled approximately 70% of all global Bitcoin transactions — the dominant exchange in a period when Bitcoin was growing from under $100 to over $1,000.

Between 2011 and 2014, attackers siphoned approximately 850,000 BTC from Mt. Gox's hot wallets — 750,000 BTC belonging to customers and 100,000 BTC belonging to the company. At the time of the February 2014 bankruptcy filing, this represented approximately $450 million. At Bitcoin prices in early 2026, the value of those coins approaches $80 billion.

The operational security failures were comprehensive:

• Private keys stored in hot wallets without cold storage segregation
• No multi-party authorization required for withdrawals
• Accounting systems maintained in a spreadsheet that allowed discrepancies to accumulate for years
• The exchange was apparently insolvent from ongoing theft for extended periods before the public collapse
• Customer audits and external security reviews were absent or ignored

The recovery process lasted over a decade. In 2024, approximately 142,000 BTC were distributed to creditors through the bankruptcy trustee — representing roughly 17% of the original stolen amount, but worth far more than the original claim value due to Bitcoin's price appreciation. Most creditors received far less than their claims in USD value due to the legal complexity of the proceedings.

The Mt. Gox collapse is often treated as a historical artifact, a product of early crypto naiveté. That framing misses the lesson: identical structural failures — no cold storage segregation, inadequate authorization controls, no external verification — have appeared in exchanges years after Mt. Gox.

Bitfinex: 119,756 BTC, August 2016

Bitfinex, at the time one of the largest Bitcoin exchanges, lost 119,756 BTC (approximately $72 million at 2016 prices) through a breach of their multi-signature wallet system. The technical details were never fully disclosed, but the attack involved compromising the authorization process for transactions in a system where BitGo served as a co-signer.

In an extraordinary response, Bitfinex issued "BFX tokens" representing the haircut applied to all customer accounts and socialized the losses across the entire customer base — reducing every account balance by 36%, regardless of whether individual customers' assets were directly stolen. Customers received BFX tokens that could be redeemed for UNUS SED LEO tokens or converted to equity. This approach, while creative, was essentially imposing a 36% loss on customers who had nothing to do with the breach.

The stolen Bitcoin sat dormant for years. In February 2022, the US Department of Justice announced the seizure of approximately 94,000 BTC connected to the Bitfinex hack — over five years after the theft. IRS-CI traced the funds through a complex transaction graph to wallets under the control of Ilya Lichtenstein and Heather Morgan (known online as "Razzlekhan," a rapper with a public persona). Both were arrested. Both eventually pleaded guilty. The investigation demonstrated chain analysis capability across hundreds of hops over six-plus years.

The residual 25,000 BTC that was not recovered represents approximately $2.3 billion at current prices.

Binance: $570 Million, Multiple Incidents

Binance, the world's largest exchange by volume, has experienced multiple significant security incidents:

May 2019: Hackers stole 7,074 BTC (~$40 million) using a combination of phishing, malware, and API key theft collected over months of preparation. The attack was patient and methodical — collecting compromised user credentials and API keys, then executing a coordinated withdrawal that triggered Binance's risk management controls, but only after the withdrawal had been processed.

October 2022: The BNB Chain bridge (BSC Token Hub) was exploited for approximately $570 million in BNB tokens through a forged proof verification attack on the cross-chain bridge. While technically a bridge exploit rather than a CEX account breach, the incident demonstrated the vulnerability of exchange-affiliated infrastructure.

Binance notably covered the 2019 theft entirely from their SAFU (Secure Asset Fund for Users) insurance fund, a $1 billion reserve maintained specifically for this purpose. This is exceptional — most exchanges do not maintain equivalent reserves.

FTX: $8 Billion in Customer Funds, 2022

FTX was not hacked. It was outright fraud, which is in some ways worse because no amount of individual account security could have protected customers.

FTX founder Sam Bankman-Fried directed FTX customer deposits — funds that were contractually supposed to be held in segregated accounts — to Alameda Research, his affiliated trading firm, to fund proprietary trading, venture investments, political donations, and real estate purchases. FTX users believed their funds were on deposit and available for withdrawal. In reality, Alameda had deployed those funds into illiquid positions.

When the November 2022 Binance-CZ tweet about FTX's financial health triggered a bank run, FTX couldn't process withdrawals because the customer funds didn't exist. The exchange froze withdrawals within days. FTX filed for bankruptcy on November 11, 2022, with over $8 billion in customer funds unaccounted for.

SBF was convicted of fraud, conspiracy to commit fraud, and conspiracy to commit money laundering in November 2023. He was sentenced to 25 years in prison in March 2024. The bankruptcy proceedings have recovered substantially more than expected due to asset appreciation and legal recoveries — customers received approximately 118 cents on the dollar on allowed claims by late 2024, better than initially feared but still involving years of locked funds and significant uncertainty.

The FTX lesson is the hardest one: you cannot protect against exchange fraud through account security measures. The only protection is keeping minimal assets at exchanges, using exchanges that have undergone meaningful external audits, and treating exchange deposits as a liability you are accepting, not safe storage.

How Individual Exchange Accounts Get Compromised

Beyond exchange-level failures, individual accounts are compromised daily through several well-documented attack vectors. Each has a clear defense.

SIM Swap Attacks

SIM swapping is the dominant method for bypassing SMS-based two-factor authentication. The attack involves convincing your mobile carrier to transfer your phone number to a SIM card the attacker controls — after which all SMS messages, including 2FA codes and password reset messages, route to the attacker.

The process that should not work but regularly does:

1. Attacker gathers your personal information: full name, address, last four digits of Social Security Number (in the US, available in data breaches), account details for your carrier (sometimes guessable, sometimes from breach data)
2. Attacker calls your carrier's customer service, impersonating you, claiming their phone was lost or damaged
3. The carrier's verification process — typically just the personal information from step 1 — is satisfied
4. Your number transfers to the attacker's SIM
5. All SMS messages to your number now go to the attacker's phone
6. Attacker uses "Forgot Password" on your exchange account, using SMS verification to reset credentials
7. Funds are withdrawn before you notice your phone has lost cellular service

High-profile victims include: Michael Terpin, who lost $24 million in cryptocurrency to a SIM swap in 2018 (he sued his carrier AT&T and eventually received a $75 million judgment against the attacker); numerous crypto influencers and executives; and the operators of the 2020 Twitter hack, who SIM swapped multiple Twitter employees to gain access to internal tools.

The attack has become so common in the cryptocurrency community that the FCC proposed rules in 2023 requiring carriers to implement stronger authentication for SIM changes. Several states have passed laws increasing penalties for SIM swapping. These measures have not eliminated the attack.

Defense:

1. Remove SMS 2FA from every exchange account immediately. This is the most important single step.
2. Call your carrier and add an account PIN or passphrase that must be verified for any account changes. Write this PIN down somewhere secure.
3. Request a "port freeze" or "SIM lock" — different carriers have different names, but the function prevents any SIM change or number porting without in-person verification at a retail store
4. On carrier accounts: remove linked payment methods that could fund a fraudulent new account and be used to verify identity
5. Consider a Google Voice or VOIP number for any account that requires a phone number but doesn't need to be on your SIM-linked number

Phishing and AiTM Proxy Attacks

Exchange phishing campaigns are sophisticated, persistent, and constantly updating. Attackers register lookalike domains (bìnance.com with Unicode homoglyphs, coinbase-login-verify.com, kraken-exchange-support.net), run Google Ads that appear above legitimate search results for exchange names, and send targeted emails that closely mimic official exchange communications.

The basic credential-harvesting phishing is the least sophisticated variant. More dangerous are Adversary-in-the-Middle (AiTM) proxy attacks using tools like Evilginx, Modlishka, and Muraena. These proxy frameworks sit between the victim and the legitimate exchange, forwarding credentials and session tokens in real time:

Normal login:
Victim → Exchange site → Authenticated session

AiTM phishing:
Victim → Phishing proxy → Exchange site → Authenticated session
                ↓
         Proxy captures:
         - Username/password
         - 2FA TOTP code (used in real time before it expires)
         - Session cookie (used even after 2FA is complete)

The captured session cookie allows the attacker to continue the authenticated session even after the TOTP code expires. The victim successfully logged into their real account — because the proxy relayed everything correctly — and has no indication anything went wrong. Meanwhile the attacker has a valid session that persists for hours.

This attack defeats TOTP-based 2FA (Google Authenticator, Authy) because the TOTP code is intercepted and used in real time before its 30-second validity window expires. The only 2FA method that is technically resistant to AiTM attacks is FIDO2/WebAuthn hardware security keys — because the cryptographic authentication binds to the domain origin, and the proxy domain is not the legitimate exchange domain.

# Check if an exchange you use supports FIDO2/WebAuthn
# Major exchanges with FIDO2 support as of 2025:
# - Coinbase: Yes (Settings → Security → Hardware Security Keys)
# - Binance: Yes (Security → Two-Factor Authentication → Security Key)
# - Kraken: Yes (Security → Two-Factor Authentication → Hardware Key)
# - Gemini: Yes (Security → Two-Factor Authentication → Security Key)
 
# YubiKey 5 series recommended for hardware security keys
# Available from yubico.com — buy only from official store
 
# After adding hardware key:
# 1. Set it as primary 2FA method
# 2. Add a backup hardware key (store in secure location)
# 3. Save recovery backup codes offline (printed, not in cloud)
# 4. Remove SMS 2FA completely
# 5. Keep TOTP as a backup if hardware key is lost (not perfect but better than SMS)

Defense checklist against phishing:

• Bookmark every exchange you use. Navigate exclusively via bookmarks, never from search results, emails, or links in messages
• Use a hardware security key (YubiKey 5 NFC or similar) for 2FA on all exchanges that support it
• Enable anti-phishing codes on exchanges that support them (Binance allows you to set a personal phrase that appears in all legitimate emails from them — any email without your phrase is a phishing attempt)
• Verify URLs character-by-character before entering credentials. The letter ì (with a grave accent) looks identical to i in most fonts but is a different Unicode codepoint

API Key Theft

Most exchanges allow users to generate API keys for automated trading, portfolio tracking applications, and custom tooling. API keys are a significant and often overlooked attack surface.

API key compromise vectors:

Malware on the API key holder's device: Any device where an API key is stored in plaintext (in environment variables, configuration files, or clipboard) is vulnerable to keyloggers, clipboard hijackers, and file system scrapers. A single piece of malware on a trading server can capture all active API keys.

Compromised third-party trading platforms: Several third-party crypto trading bots and portfolio management tools have been breached, exposing the API keys their users trusted them with. Notable examples include the 2019 3Commas hack (disputed; the company blamed user phishing) and multiple smaller platform breaches. When you give an API key to a third-party service, you're trusting that service's security as much as your own.

GitHub repository exposure: Developers who commit code to public GitHub repositories regularly accidentally commit API keys in configuration files, environment files, or hardcoded strings. GitHub's secret scanning alerts catch some of these in real time, but historical commits remain visible if not properly cleaned. GitHub explicitly monitors for patterns matching known API key formats and notifies both the developer and the exchange — but between commit and notification, the key has been public.

Clipboard hijacking: Some malware specifically monitors the clipboard for patterns matching cryptocurrency wallet addresses and API keys, replacing copied content with attacker-controlled values. When you paste what you believe is your API key into an application, you may be pasting an attacker's harvesting endpoint instead.

# Secure API key storage practices for trading automation
 
import os
from cryptography.fernet import Fernet
from pathlib import Path
 
# BAD: Hardcoded API key
# api_key = "abc123xyz789..."  # Never do this
 
# BAD: Plaintext environment variable file committed to git
# .env file: BINANCE_API_KEY=abc123xyz789...
 
# BETTER: Load from environment variables, exclude .env from git
api_key = os.environ.get("EXCHANGE_API_KEY")
api_secret = os.environ.get("EXCHANGE_API_SECRET")
 
# BEST: Encrypt secrets at rest using derived key
 
def load_encrypted_credentials(encrypted_file: str, master_password: str) -> tuple[str, str]:
    """
    Load API credentials from an encrypted file.
    The master password is entered at runtime, never stored.
    """
    import hashlib
    import base64
 
    # Derive Fernet key from master password + salt
    salt_file = Path(encrypted_file + ".salt")
    if not salt_file.exists():
        raise FileNotFoundError("Salt file not found")
 
    salt = salt_file.read_bytes()
    key_material = hashlib.pbkdf2_hmac(
        'sha256',
        master_password.encode(),
        salt,
        iterations=100000
    )
    fernet_key = base64.urlsafe_b64encode(key_material)
    f = Fernet(fernet_key)
 
    encrypted_data = Path(encrypted_file).read_bytes()
    decrypted = f.decrypt(encrypted_data).decode()
 
    api_key, api_secret = decrypted.split(":")
    return api_key, api_secret
 
 
# API key permission scoping
# Only grant permissions the key actually needs:
TRADING_BOT_PERMISSIONS = {
    "enable_trading": True,
    "enable_withdrawal": False,   # NEVER grant withdrawal to bots
    "enable_futures": False,      # Only if your bot trades futures
    "ip_restriction": "203.0.113.0",  # Your trading server's IP
}
 
# Whitelist specific IP addresses for each API key
# Unauthorized IPs will be rejected even with a valid key

Defense:

• Create separate API keys for each distinct use case (trading bot, read-only portfolio tracker, etc.) with the minimum permissions each requires
• Never grant withdrawal permissions to API keys used by automated systems or third-party platforms
• Configure IP address restrictions on all API keys — only the specific IP(s) of your servers can use the key
• Rotate API keys every 90 days
• Review active API keys monthly and delete any that are no longer in use
• Never paste API keys into websites you don't fully control — use environment variables or encrypted credential stores

Credential Stuffing at Scale

Attackers obtain username/password combinations from data breaches and test them against exchange login pages at scale using automated tools. This is not technically sophisticated — it requires no hacking. It requires obtaining breach data (available for purchase or free download from breach aggregators) and running a credential testing script.

The attack is effective because most people reuse passwords. If your email address and password for a gaming forum breached in 2018 is the same combination you use for your exchange account, the attacker doesn't need to hack the exchange — they just need to know about the forum breach.

Have I Been Pwned (haveibeenpwned.com) indexes over 13 billion compromised accounts from thousands of breaches. Your email address is almost certainly in there. The question is whether the corresponding passwords are unique.

Defense:

• Use a password manager (Bitwarden, 1Password) to generate and store unique 24-character random passwords for every exchange account
• Use a unique email address for each exchange if possible — create name+exchange@gmail.com aliases that all route to your main inbox
• Enable login notifications — every new login to your exchange account should trigger an immediate email or push notification
• Review your active sessions in exchange account settings regularly and revoke any unrecognized sessions

The Complete Exchange Security Checklist

Run through this for every exchange account you hold funds in. This is not a suggestion — it's a minimum baseline:

Authentication

□ Password: unique, 24+ characters, generated by password manager
  (NOT a memorable password you created — a random string)

□ SMS two-factor authentication: DISABLED on all accounts
  (SMS is vulnerable to SIM swap; remove it entirely)

□ Hardware security key (YubiKey 5 NFC or Google Titan Key):
  configured as PRIMARY 2FA on every exchange that supports FIDO2

□ TOTP authenticator app (Aegis on Android, Raivo OTP on iOS):
  configured as BACKUP 2FA (not SMS, not email)

□ Authenticator backup codes: printed and stored physically offline
  (NOT in cloud notes, email drafts, or digital photos)

□ Hardware key backup: a second registered hardware key stored
  in a separate secure physical location

□ Session review: all active sessions reviewed, unrecognized
  sessions revoked

Account Hardening

□ Withdrawal address whitelist: ENABLED
  Only pre-approved addresses can receive withdrawals.
  New addresses require 24-48 hour waiting period before activation.

□ Time-lock on new withdrawal addresses: ENABLED
  (48-hour delay before a newly added address can receive funds)

□ Anti-phishing code: CONFIGURED
  A personal phrase that appears in all legitimate emails from the exchange.
  Any email without your phrase is phishing.
  Available on Binance, OKX, and several others.

□ Login notifications: ENABLED for every login
  Email or push notification immediately on any new session

□ Withdrawal notifications: ENABLED for all withdrawal requests

□ Security change notifications: ENABLED for password changes,
  2FA changes, withdrawal address changes

□ Account login history: REVIEWED
  No unrecognized IP addresses or locations in login history

□ IP address restrictions: CONFIGURED if available
  Some exchanges allow restricting account access to specific IPs

Email Account Securing

The email account linked to your exchange is the master key — password reset emails go there, security notifications go there, and any attacker who controls your email can often control your exchange accounts.

□ Exchange email account: secured with hardware security key 2FA
  (Same or higher security as the exchange itself)

□ Recovery phone number: REMOVED from exchange email account
  A phone number on your Google/Microsoft account is a SIM swap
  vector into your email, which is a vector into your exchange

□ Recovery email: points to a separate secure account,
  not a shared or work account

□ Email account password: unique, 24+ characters, in password manager

API Keys

□ All unused API keys: DELETED
  Unused keys with withdrawal permissions are ticking time bombs

□ Active keys: REVIEWED for permissions
  Withdrawal permission disabled on all keys not explicitly
  requiring it (most trading bots do not need withdrawal access)

□ IP allowlist: CONFIGURED on all active keys
  Each key restricted to specific IP addresses

□ Key age: ANY key over 90 days should be rotated

□ Keys in repositories: CHECKED
  Search your GitHub/GitLab repos for exchange domain names,
  API key format patterns, or key prefix strings

Operational

□ Exchange balance minimized:
  Only funds needed for active trading positions

□ Regular withdrawal schedule to self-custody cold storage:
  Weekly or monthly, depending on trading activity

□ Exchange accounts not linked to public social media:
  Don't post screenshots showing your exchange username,
  don't use your real name in exchange profiles if avoidable

□ Exchange evaluations performed:
  Proof-of-reserves audit status checked (see below)
  Cold storage ratio reviewed
  Insurance coverage understood

Self-Custody vs. Exchange Custody: The Real Tradeoff

"Not your keys, not your coins" is accurate but incomplete. The statement is used to argue that self-custody is always superior to exchange custody. In practice, both have failure modes that can destroy your holdings.

| Risk Category | Exchange Custody | Self-Custody | |---------------|-----------------|--------------| | Exchange fraud or insolvency | High (FTX, Mt. Gox) | None | | Exchange hack | Medium (Bitfinex, Binance) | None (for cold storage) | | Account compromise via phishing | Medium (depends on your security) | Low (no account to phish) | | Regulatory freeze or seizure | Medium (jurisdiction-dependent) | Low (unless hardware seized) | | Seed phrase loss | None | Catastrophic (permanent loss) | | Seed phrase theft | None | Catastrophic (permanent loss) | | Physical disaster destroying backup | None | High (without distributed backup) | | Inheritance failure | Low (bank-style legal process sometimes works) | High (heirs may not have access) | | Smart contract interaction error | None | Medium (for hot wallet DeFi users) | | User error (wrong address) | Low (exchanges sometimes block) | High (irreversible) |

The calculus is not "exchange = dangerous, self-custody = safe." It's "each model has a different failure profile, and your risk management must address both."

The practical tiered approach:

Tier 1 — Long-term cold storage: Hardware wallet (Ledger Nano X, Trezor Safe 5, or Coldcard for Bitcoin). Seed phrase on stamped metal (Cryptosteel Capsule, Bilodl, or similar) in two physically separate locations. Never connects to any DeFi protocol. Never uses browser extensions. Air-gapped for signing if possible. This holds 80-90% of total holdings.

Tier 2 — Medium-term / DeFi: A second hardware wallet, funded from Tier 1 as needed. Used for protocol interactions. Token approvals reviewed and revoked after each session. Balance kept to what you could survive losing entirely. This holds 10-15% of holdings.

Tier 3 — Exchange accounts: Only what you need for active trading and near-term liquidity. All security controls from the checklist above applied. Withdrawn to cold storage after trading is complete. 5-10% of holdings maximum.

The dollar threshold for moving to cold storage is whatever amount you would genuinely be devastated to lose permanently. For most people, that threshold is much lower than they currently behave — meaning most people have too much on exchanges relative to their actual loss tolerance.

Evaluating an Exchange's Security

Not all exchanges present equal risk. Before keeping funds on any exchange, investigate:

Proof of Reserves: Does the exchange publish cryptographic proof that customer deposits are held 1:1? Merkle tree-based proof of reserves allows customers to verify that their specific balance is included in the exchange's total reserve commitment without trusting an audit firm's word. Kraken pioneered this. After FTX, many major exchanges implemented it. Exchanges that do not publish proof of reserves should be treated with heightened suspicion.

To verify your inclusion in a Kraken proof of reserves:

# Kraken proof of reserves verification (example process)
# 1. Download the audit data file from Kraken's proof-of-reserves page
# 2. Find your account ID in the Merkle tree leaves
# 3. Verify the hash path from your account balance to the root hash
# 4. Verify the root hash matches the auditor-signed attestation
 
# Example using kraken-por-verifier:
# pip install kraken-por-verifier
# kraken-por-verifier verify --account-id YOUR_ACCOUNT_ID --proof-file audit.json

Cold Storage Ratio: What percentage of customer funds does the exchange hold in cold storage? Reputable exchanges hold 95%+ in offline cold storage, minimizing the exposure of a hot wallet breach. Exchanges that don't disclose this figure should be assumed to have unfavorable ratios.

Insurance: Does the exchange carry insurance covering theft from cold storage? Coinbase maintains a crime insurance policy covering a portion of digital currency held in their online storage. Gemini has insurance through a Lloyd's of London syndicate. Most exchanges have no meaningful insurance. "SAFU fund" equivalents (Binance's self-insurance reserve) are better than nothing but are not externally verified insurance products.

Audit and Attestation: Has the exchange been audited by a reputable external firm? Post-FTX, the industry moved toward real-time attestation by firms like Mazars, Armanino, and KPMG. Exchanges that resist audits or only publish internal reports have something to hide.

Regulatory Status and Jurisdiction: Is the exchange registered with financial regulators in a jurisdiction with meaningful oversight and enforcement? A Cayman Islands or Seychelles incorporation is not equivalent to FinCEN registration and a BitLicense from NYDFS. Regulation doesn't guarantee safety — regulated banks have failed. But regulatory registration creates disclosure requirements, audit trails, and legal accountability that offshore unregistered exchanges entirely lack.

Incident History and Response: How has the exchange handled past security incidents? An exchange that experienced a breach, disclosed it immediately, reimbursed all affected customers, and made demonstrable security improvements is more credible than an exchange with a clean public history — because clean history often means no public disclosure of incidents that occurred.

The exchange you choose is a counterparty you're trusting with your funds. That trust should be proportional to the evidence supporting it — not to the marketing copy on their website or the trading fee discounts they offer.

What to Do When an Exchange Freezes or Fails

If an exchange you hold funds on announces problems:

1. Attempt to withdraw immediately: Not in panic, but promptly. Exchanges in financial distress often close withdrawals suddenly. The faster you withdraw, the more likely you are to be in the group that succeeded before the freeze.

2. Document everything: Take screenshots of your account balance, open positions, and any communications from the exchange. This documentation is essential for any bankruptcy claim.

3. File a claim in bankruptcy proceedings if they begin: Exchange bankruptcies (FTX, Mt. Gox, Celsius, Voyager) have all had formal bankruptcy proceedings where customer creditors could file claims. The process is slow and the recovery percentage varies. File the claim regardless of how small your expectation of recovery is — not filing forfeits any claim entirely.

4. Check for class action litigation: When exchanges fail fraudulently, class actions are common. You don't need to do anything actively in most cases — plaintiffs' attorneys file on behalf of all similarly situated customers. But checking that you're aware of ongoing litigation ensures you don't miss a settlement notice.

5. Report fraud to appropriate authorities: FTX-scale fraud warrants reporting to the SEC (tips.sec.gov), FBI's IC3 (ic3.gov), and the CFTC (cftc.gov/tips) in the US, or equivalent agencies in your jurisdiction. These reports contribute to the investigative record that leads to prosecutions.

The least satisfying truth about exchange security: the most consequential exchange failures (FTX, Mt. Gox) were not preventable by individual account security measures. No phishing-resistant MFA saved FTX customers. The only protection against exchange-level fraud and insolvency is keeping minimal assets on any exchange and maintaining the bulk of holdings in self-custody where the failure of an exchange counterparty is irrelevant.

Set up the account-level security controls because they protect against the attacks that happen every day to individual accounts. And keep your exchange balances minimal because they protect against the failures that happen every few years and wipe out everyone indiscriminately.