6 October 2026 · 3 min read
Crypto exchange security, where the losses actually come from
Published incidents are rarely clever cryptography. They are keys, approvals and operations. The controls that matter, in the order they matter.
Read the write ups of the large exchange losses and a pattern appears. The matching engine is almost never the problem. Key management and the withdrawal path almost always are.
That should change what you spend your security budget on.
The order that matters
1. Key custody. Where private keys live, who can reach them, and what it takes to move funds. A hot and cold split with only operational float online, multisig before anything leaves cold storage, and nobody holding a single key that moves everything.
2. The withdrawal path. Limits per user and per period, an approval step above a threshold, two person approval above a larger one, risk flags on new destinations, and an audit trail of who approved what.
3. Admin access. Separate roles for support, finance and engineering. Two factor on every admin account, no shared logins, and a record of every action.
4. The boring infrastructure. Patched server, firewall, fail2ban, SSH keys instead of passwords, backups that have actually been restored once.
5. Application security. Input validation, rate limits, session handling. Necessary and far down the list, because it is almost never the thing that empties an exchange.
Most published exchange losses are an operations story wearing a technology costume. The attacker did not break the cryptography, they got to the people and processes around the keys.
What we build in by default
- Address derivation per user, no shared deposit addresses
- Confirmation thresholds per chain, configurable, with reorg reversal
- Hot and cold split with a sweep policy in the console
- Withdrawal approvals with limits and a full audit trail
- Role separation in the admin panel
- A reserve report, so the question "do you hold what you owe" has an answer
More detail on the approval side sits in what belongs in an admin panel.
What costs extra, honestly
- A third party audit of the custody and withdrawal code. Worth it before you hold meaningful balances.
- A penetration test against the live deployment.
- Hardware signing or a custody provider, if balances justify it.
- Bug bounty, once there is something worth finding.
None of those are padding. All of them are optional at launch and sensible before you are holding other people's savings.
The question to ask any vendor
Not "is it secure". Ask: if an attacker had your admin password right now, what could they move, and what would stop them. A good answer is specific and short. A vague answer is the answer.
Questions
How do crypto exchanges actually get hacked
Overwhelmingly through key management and the withdrawal path rather than clever attacks on trading logic. Compromised admin access, keys reachable from an internet facing machine, and approvals that one person can grant.
What is a hot and cold wallet split
Operational float stays online in a hot wallet for payouts; the rest sits in cold storage that requires multisig to move. It limits what a single compromise can take.
Do I need a security audit before launch
Before holding meaningful balances, yes, focused on custody and withdrawals. At day one with small float it is reasonable to launch with strong controls and audit before you grow.
What should the withdrawal approval process look like
Limits per user and period, manual approval above a threshold, two people above a larger one, risk flags on new destinations, and an audit trail. Automate within limits, never beyond them.
Is two factor enough for admin accounts
It is the minimum, not the control. Role separation and two person approval above a threshold are what stop a single compromised account from emptying the venue.
Does the matching engine need securing
It needs to be correct, which is a different problem. Security spend belongs on keys, approvals and admin access, because that is where the published losses come from.