They should combine stronger identity verification, step-up authentication, tight recovery controls, and administrative access governance. The goal is to reduce the number of ways a stolen account, compromised operator, or abusive insider can move funds or change records without detection. Security only scales when identity, transaction approval, and privilege controls are designed together.
Why This Matters for Security Teams
Crypto exchanges sit at the junction of identity abuse, payment fraud, and high-value privilege. A single compromised login can become a drained wallet, a manipulated beneficiary, or a silent change to recovery settings if controls are split across product, fraud, and infrastructure teams. Current guidance suggests treating account takeover as an identity and transaction-risk problem, not only an authentication problem. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which matters because exchange operations depend on automation, internal services, and privileged workflows as much as end-user access.
That is why strong controls need to cover onboarding, step-up authentication, device and session trust, recovery, and privileged admin actions together. The control baseline in NIST Cybersecurity Framework 2.0 and the identity safeguards in NIST SP 800-53 Rev 5 Security and Privacy Controls both support that layered approach. In practice, many security teams discover takeover paths only after fraud has already moved through recovery or admin workflows, rather than through intentional testing of the full account lifecycle.
How It Works in Practice
At scale, exchanges reduce takeover risk by combining strong identity proofing, adaptive authentication, and transaction governance. For user accounts, that means risk-based step-up when behaviour changes, such as a new device, unusual geography, high-velocity trading, or a withdrawal to a new address. For operators and support staff, it means separate privileged access, phishing-resistant authentication, just-in-time elevation, and explicit approval for sensitive actions. The practical lesson from Ultimate Guide to NHIs — Key Challenges and Risks is that identities behind the scenes often carry more standing power than teams expect, so service accounts, API keys, and internal automation also need ownership, rotation, and monitoring.
- Use strong KYC and recovery checks to prevent SIM-swap, mailbox takeover, and social engineering from bypassing the login flow.
- Require step-up for withdrawals, address changes, API key creation, and session resets.
- Split duties so support can assist without unilaterally moving funds or disabling controls.
- Track device reputation, session anomalies, and impossible travel signals, then feed them into fraud decisions.
- Inventory and govern non-human identities used by trading, wallet, risk, and customer support systems.
For attack-pattern visibility, teams should map common abuse to the techniques described by MITRE ATT&CK, especially credential theft, valid-account use, and abuse of remote services. The operational target is not perfect prevention but rapid containment, so suspicious actions are blocked, queued, or manually approved before value leaves the platform. These controls tend to break down when account recovery, customer support, and transaction execution sit in separate systems that do not share the same risk signals.
Common Variations and Edge Cases
Tighter fraud controls often increase customer friction and support load, requiring exchanges to balance conversion against loss prevention. That tradeoff is most visible for VIP users, cross-border customers, and high-volume traders, where aggressive challenge rates can create abandonment or false positives. Best practice is evolving here: there is no universal standard for how much step-up is enough, so current guidance suggests tuning controls by account value, behaviour history, and jurisdiction rather than using one static policy for everyone.
Edge cases also matter. Account takeover can begin outside the exchange through email compromise, mobile number hijack, or malware on a trader’s workstation, then surface only when the user attempts a withdrawal. Recovery flows deserve special scrutiny because they are a frequent bypass path, especially when help desks can override authentication too easily. Exchanges using bots, market-making tools, or treasury automation should also treat those agents as high-risk non-human identities and apply the same governance discipline described in Top 10 NHI Issues and the identity lifecycle practices in Ultimate Guide to NHIs — Why NHI Security Matters Now.
The biggest failure mode is assuming that MFA alone solves fraud. In reality, stronger authentication must be paired with transaction approval, recovery hardening, admin governance, and monitoring of both human and non-human identities, especially where APIs can move funds or mutate account state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-04 | Adaptive authentication and identity proofing reduce takeover risk. |
| NIST SP 800-63 | IAL2 | Stronger proofing helps prevent fraudulent account creation and recovery abuse. |
| NIST Zero Trust (SP 800-207) | AC-6 | Least privilege limits what a stolen account or insider can change. |
| OWASP Non-Human Identity Top 10 | Exchange automation and API keys are non-human identities that need governance. | |
| MITRE ATT&CK | T1078 | Valid account abuse is a common pattern behind takeover and fraud. |
Inventory, rotate, and restrict service accounts and keys that can move funds or alter state.
Related resources from NHI Mgmt Group
- How should organisations reduce MFA-related account takeover risk?
- How can organisations reduce account takeover risk without hurting user experience?
- How should retailers reduce login friction without increasing account takeover risk?
- How should security teams use browser controls to reduce account takeover risk?
