Crypto exchanges sit at the intersection of two threat models: traditional fintech (with everything that implies about API security, internal access, and compliance) and crypto-native (with everything that implies about key management, on-chain surveillance, and the impossibility of un-doing a transaction).
MiCA, DORA, and the various national PSAN/VASP regimes raise the bar for documented security across the EU. Modern attackers raise the bar for the actual security underneath the documentation. This piece covers what we look for when we run a security review for an exchange, and what teams need to have in place, operationally and on paper.
Custody: hot, warm, cold
The architecture exchange operators converge on, and the one we recommend, looks like this:
Cold storage holds the vast majority of customer funds. Air-gapped, multi-sig or threshold MPC, geographically distributed signers, hardware-wallet operations only. Touched on a defined schedule for replenishment, never on demand.
Warm storage holds the operating buffer. Several days of expected withdrawal volume. Signed by a smaller threshold, faster to mobilise, but still through hardware-backed signing.
Hot wallets hold the immediate operational float. Signed automatically by HSM- or KMS-backed services, with strict programmatic policies, per-transaction caps, per-hour caps, address whitelists where possible.
The relevant question is not "is this architecture good?", it is "what is the worst-case loss?" A drain of the hot wallet should be a bad day. A drain of the warm should be a serious incident. A drain of the cold should be impossible without compromise of multiple independent organisations.
We design and review these architectures during a Wallet Setup engagement, and we monitor them continuously through Wallet Surveillance.
The withdrawal pipeline
The most-attacked endpoint in any exchange is the withdrawal flow. It is also the hardest to secure because it must remain fast enough to deliver a competitive product.
The questions we ask in a Penetration Testing engagement:
- What is the path between a user pressing "withdraw" and a transaction being signed? How many systems sit between request and signature?
- Where is the signing key? What is the trust boundary?
- Can a compromise of the user-facing API result in a withdrawal? Can a compromise of internal admin tooling? Of CI/CD? Of a single engineer's laptop?
- What rate limits apply, in what dimensions (per user, per IP, per address, globally)?
- What out-of-band confirmations exist for new withdrawal addresses?
- What automatic anomaly detection runs, and what does it page on?
- How fast can a withdrawal be paused once an anomaly is detected?
The exchanges that have lost customer funds usually had one of these answers wrong, not all of them. The defense is layered: every step that could fail should also be backstopped by another step.
API surface and internal access
Exchanges accumulate APIs faster than they accumulate API reviews. REST, WebSocket, FIX, internal admin panels, partner endpoints, market-maker gateways. Each is a potential entry point.
Common findings in our pen-test reports:
- Insecure direct object references on internal admin tooling, where a moderately privileged user can act on accounts they should not see.
- Tenant isolation bugs in white-label or sub-account setups, one tenant's transactions visible or actionable from another.
- Authentication on internal endpoints weaker than on customer-facing ones, on the assumption "internal traffic is trusted."
- Rate-limit gaps that allow account enumeration or credential stuffing at scale.
- Secrets in CI/CD that survived a since-deprecated workflow and remain valid.
- API key permissions that are coarser than they should be, a read-only key that turns out to also let the holder move funds.
Each of these has been a real finding in real engagements. None of them are exotic. They are what you find when a competent attacker spends a week looking, which is what we do, in advance, so the next one to look does not find them.
On-chain monitoring
Exchanges' on-chain footprint is enormous and high-stakes. Hot, warm, cold, deposit addresses for every customer, internal sweep wallets, market-maker rebalancing flows. Each has a profile that, when it deviates, is a signal worth investigating.
Wallet Surveillance for an exchange covers:
- Deposit address sweeps that look unusual (volume, destinations, timing).
- Hot-wallet outflows that diverge from baseline, even by a small amount.
- Cold-wallet activity at all (any activity is, by design, an event).
- Multi-sig proposals queued before they execute.
- Approvals to unfamiliar contracts, sometimes the leading indicator of an internal compromise.
- Interactions with sanctioned addresses (OFAC SDN list, Tornado-tainted addresses), a compliance and a security signal.
The monitoring is continuous; the response is human. A real analyst on the other end of the alert is the difference between a tooled-out dashboard and an actual security function.
Incident readiness
An incident at an exchange is existential. Customer funds lost is not a recoverable position, financially, reputationally, or regulatorily.
The minimum readiness:
- A pause path for the withdrawal pipeline, held by a small group on call, with a published response SLA.
- A standing communications procedure, drafts pre-approved with legal and counsel, ready to fill in.
- A relationship with an Incident Response firm, on retainer, with response SLAs commensurate with the value at stake.
- A trace-and-recovery capability, either in-house or contracted, that can produce an on-chain narrative within hours of an incident.
- A regulator and law-enforcement contact list, by jurisdiction.
These are not optional. MiCA and equivalent regimes increasingly require documented evidence of each, and the regulators ask for it during examination, not only after incidents.
MiCA-specific notes
For exchanges operating in the EU, MiCA introduces specific operational expectations:
- Custody segregation. Customer funds not commingled with exchange operating funds. Documented, auditable, on-chain where possible.
- ICT risk management under DORA, overlapping heavily with security controls. A SOC 2 Type II or ISO 27001 program is increasingly the de facto evidence.
- Outsourcing controls. Third-party providers (custody partners, market-maker integrations, KMS providers) require contractual and operational controls.
- Incident reporting with defined timelines to competent authorities. A team that does not have a reporting pipeline at hour zero will miss the deadline.
- Travel Rule compliance for transfers above thresholds, including coordination with other regulated entities.
Exchanges getting authorisation today benefit from clearer rules of the road than the prior patchwork of national rules. The regulatory ramp-up is real, and the security controls underneath it are most of the work.
What good looks like
The exchanges that do not appear in incident reports tend to share a profile:
- Custody architecture that an external reviewer would describe as boring. No exotic schemes, no clever shortcuts, no trust assumptions stated in slide decks instead of contracts.
- An API surface that has been beaten on regularly by external testers, with findings tracked, fixed, and re-tested.
- Continuous on-chain monitoring with a human analyst on the other end.
- Documented operational procedures the team can execute under pressure, because they have rehearsed.
- A standing relationship with an incident-response firm.
- Compliance documentation that reflects the actual operations, not aspirational ones.
None of these are exciting. All of them compound, year over year, into the kind of security posture that does not produce headlines.
The exciting alternative is the one that produces headlines. Pick.