Who is accountable when a crypto exchange account is taken over through recovery abuse?

Why This Matters for Security Teams

Recovery abuse is not just an account security issue. It is an identity assurance failure that can turn a single social-engineering event into full customer takeover, especially when recovery paths can re-bind phone numbers, email addresses, or devices with weak verification. For exchanges, the question of accountability matters because the blast radius includes funds movement, KYC data, and downstream fraud claims, not just the compromised login.

Current guidance suggests that recovery controls should be treated as high-risk authentication journeys, with explicit ownership across IAM, fraud, security operations, and customer support. That aligns with the control emphasis in the NIST Cybersecurity Framework 2.0 and the broader lifecycle governance described in Ultimate Guide to NHIs.

The practical mistake is assuming the last team to touch the ticket owns the incident, when in reality the accountable party is the control owner responsible for the recovery design, evidence, and review loop. In practice, many security teams encounter this only after an attacker has already completed a recovery chain and moved assets out of reach.

How It Works in Practice

Accountability should be mapped to the recovery control, not to a single operational queue. If a takeover occurs through SIM swap, email compromise, help-desk override, or weak re-verification, the root cause usually sits in one of three places: policy design, execution of the policy, or monitoring after the event. Security owns the standard, IAM owns the identity binding logic, fraud owns behavioral and transaction anomaly detection, and customer operations often owns the manual exception path.

That division only works when each team has defined decision rights and evidence requirements. Practitioners usually need:

• A named control owner for account recovery, with documented approval authority.
• Step-up verification for high-risk recovery actions, especially device or factor changes.
• Event logging that captures who approved the reset, what proof was accepted, and whether the account was re-bound.
• Fraud review triggers for recovery events followed by withdrawal, address change, or new beneficiary setup.
• Post-incident review that checks whether policy failed, staff bypassed policy, or tooling allowed unsafe exceptions.

That structure is consistent with the governance emphasis in Ultimate Guide to NHIs, even though this scenario involves human account recovery rather than machine credentials. The same governance principle applies: if a control can be reassigned, bypassed, or reset without strong assurance, ownership must be explicit and auditable. Where organisations still rely on blended support workflows and informal overrides, accountability becomes diffused and evidence quality collapses. These controls tend to break down when recovery is handled through outsourced support or cross-border operations because exception handling is harder to standardise and review.

Common Variations and Edge Cases

Tighter recovery assurance often increases friction for legitimate users, so organisations must balance user supportability against takeover resistance. There is no universal standard for this yet, but best practice is evolving toward risk-based recovery, where the more sensitive the account or transaction, the stronger the re-verification and the narrower the exception path.

Edge cases change accountability in important ways. If a third-party call centre performs recovery, the exchange still remains accountable for the control outcome, but the vendor becomes a delegated operator. If the compromise followed a KYC document spoof or synthetic identity, fraud may own the detection gap while IAM owns the binding weakness. If the user was restored correctly but an attacker retained a trusted device, then the fault may lie in session and device revocation rather than in the initial reset.

Security teams should also distinguish between policy failure and control failure. A policy can be sound on paper, yet still fail if support staff can override it without verification or if logging is too weak to prove what happened. The strongest operational pattern is to treat recovery as a high-risk change event, with mandatory review and evidence retention. That approach lines up with the lifecycle discipline in Ultimate Guide to NHIs and the identity governance outcomes in NIST Cybersecurity Framework 2.0.

Related resources from NHI Mgmt Group

• Who is accountable when SMS MFA fails and an account is taken over?
• Who is accountable when an account takeover succeeds through support-channel abuse?
• Who is accountable when a help desk scam leads to account takeover?
• Who is accountable when cloud recovery depends on automated pipelines?