Crypto Exchange Identity and Key Security Guide

At a crypto exchange, whoever can produce a valid signature controls the money, so identity security and key security are the same problem. A stolen password at a bank starts a fraud investigation; a stolen signing session at an exchange can empty a wallet in one irreversible transaction. This guide covers how exchanges and custodians should protect wallet keys (HSM, MPC and multisig), the signing workflow and transaction verification, developer and cloud access, insider risk and the North Korean recruitment lures aimed at staff. It also maps the main regulatory hooks in the EU (MiCA, DORA) and New York (NYDFS). It is written for security architects, wallet engineering leads, CISOs and compliance teams at exchanges, brokers and custodians.

Key takeaways

The signing interface is part of the key. The Bybit theft in February 2025 did not break a key or a multisig contract: signers approved a tampered transaction shown to them as routine, so verification must happen on a device the attacker does not control.
No custody model removes the human approver. HSM, MPC and multisig each move risk around; all three still depend on the identities, devices and policies of the people and services that approve a transaction.
Developer and cloud identities are wallet-adjacent. A developer's cloud session or a CI token that can change wallet software, front-end code or policy engines deserves the same protection as a signer's credential.
Staff are targeted by name. The FBI has warned that North Korean actors research crypto employees and deliver malware through fake job offers and coding tests; treat recruitment approaches as an attack channel.
Regulators now expect evidence. MiCA makes crypto-asset service providers liable for losses from ICT incidents, DORA applies to them, and NYDFS requires a cybersecurity programme with a named CISO and annual reporting.

Threat model: how exchanges actually lose funds

Most large exchange losses involve an identity or a device, not a cryptographic break. The table summarises the recurring paths and the controls that interrupt them. ATT&CK IDs are from ATT&CK v20.

Attack path	Typical technique (ATT&CK)	What it gives the attacker	Primary controls
Fake recruiter or investor contacts an engineer and sends a coding test	T1566.003 Spearphishing via Service, T1204.002 Malicious File	Malware on a workstation with repository, cloud or wallet tooling access	Coding tests only on isolated non-company devices, application allowlisting, out-of-band identity checks
Session tokens stolen from a developer or administrator	T1539 Steal Web Session Cookie, T1550.001 Application Access Token	Cloud console or SaaS access without needing a password or MFA	Short session lifetimes, device-bound sessions, alerts on token use from new locations
Cloud account misuse to alter wallet software or a signing front end	T1078.004 Cloud Accounts, T1195.002 Compromise Software Supply Chain	Ability to change what signers see or what the signer software sends	Two-person change control on wallet code, artifact signing, integrity monitoring
Hot wallet key read from a server or backup	T1552.004 Private Keys	Direct signing of withdrawals	Keys in HSM or MPC, never in files or environment variables
Insider abuse or bribery of support and operations staff	Valid accounts used outside their purpose	Customer data for social engineering, or approvals on withdrawals	Least privilege, separation of duties, behavioural monitoring
End state for all of the above	T1657 Financial Theft	Irreversible on-chain transfer, then laundering across many addresses	Transaction policy engine, velocity limits, rapid blocklisting with analytics partners

Two live NHI Mgmt Group case studies show the extremes. In the BitMart hot wallet hack, a single stolen private key was enough. In the Bybit hack, the keys and the multisig were intact and the attacker went after the software the signers trusted. See the Lazarus Group Threat Actor Profile for the actor behind many of these cases.

Wallet key custody: HSM, MPC and multisig compared

Exchanges usually run a tiered model: a small hot wallet for automated withdrawals, a warm tier for rebalancing, and cold storage for most customer assets. The custody technology differs per tier, and each has a different identity attack surface.

Approach	How control is split	Strengths	Identity risks to manage
Hardware security module (HSM)	One key held inside tamper-resistant hardware; policy and operator roles decide who may use it	Key never leaves the module; FIPS 140-3 validation gives an independent assurance level; mature for hot wallet automation	Whoever controls the application or API credential that calls the HSM can sign; operator and administrator roles must be split and quorum-protected
Multi-party computation (MPC) or threshold signing	Key shares held by separate parties or servers; a threshold must cooperate to sign; the full key never exists in one place	Removes the single key as a target; chain-agnostic; shares can be refreshed without changing the address	Share holders authenticate to a coordinating service, which becomes a high-value identity; policy engine credentials and co-signer devices must be protected
On-chain multisig (smart contract wallet)	M of N independent keys must sign; the contract enforces the threshold on-chain	Threshold is publicly verifiable; each signer can use a hardware wallet	Signers depend on a user interface to build and display transactions; general-purpose contracts allow powerful operations such as delegatecall; signer laptops are targets
Offline cold storage (air-gapped)	Keys generated and used on offline devices under ceremony	Smallest network attack surface	Ceremony participants, transport of unsigned and signed transactions, and physical access controls become the identity layer

NIST is standardising this space: its First Call for Multi-Party Threshold Schemes (NIST IR 8214C) was finalised in January 2026, so expect threshold signature schemes to gain formal evaluation criteria over the next few years. For key lifecycle basics (generation, backup, rotation, destruction) see the Cryptographic Key Management Guide.

Choosing between them

Hot wallet with high withdrawal volume: HSM or MPC with an automated policy engine. Multisig with human signers does not scale to thousands of withdrawals a day.
Cold and warm treasury movements: MPC or multisig with human approvers on separate hardware, plus independent transaction verification (see next section).
Smaller exchanges: a qualified third-party custodian may be safer than building in-house key infrastructure, but the exchange still owns the approval identities, API keys and withdrawal policies it uses with that custodian. Under NYDFS custody guidance, a new sub-custody arrangement is a material change requiring prior approval.
Large exchanges: mix models so that no single vendor, technology or administrator group can move all assets. Diversity of failure modes matters more than any one choice.

Signing workflow and transaction verification

The Bybit case shows why the signing workflow, not the key store, is often the weakest point. According to Sygnia's interim findings as reported by The Block, the attacker compromised a Safe{Wallet} developer's machine, reached the Safe AWS environment and replaced JavaScript in an S3 bucket serving the web interface. The code activated only for Bybit's wallet, was found cached on every signer host and was swapped back to a clean version two minutes after the theft. NCC Group's technical analysis explains what changed in the signed transaction: the destination became an attacker contract, the calldata wrote to the wallet proxy's storage, and the operation type changed from call (0) to delegatecall (1), which let the attacker replace the wallet's implementation and drain it. The signatures were valid because they covered the tampered data.

Controls that would have broken the chain

Independent verification on the signing device: use hardware signers that clear-sign typed data, and require signers to confirm destination, value, calldata, nonce and operation on the device screen. Safe's own guidance says operation must be 0 for a normal call, a value of 1 means delegatecall and needs expert review, and if any field cannot be verified the signer should not sign.
Offline hash comparison where devices cannot clear-sign: compute the Safe transaction hash, domain hash and message hash with an offline tool and compare them to what the device shows before signing.
A second, independent transaction builder: construct or decode the transaction on a separate, hardened system (different code base, different network) and compare. A compromise of one interface then cannot fool every signer.
Policy engine before broadcast: NCC Group recommends an internal service that checks every transaction against policy before submission, and a role that controls who may submit signed transactions on-chain. Block delegatecall, contract upgrades and owner changes on treasury wallets unless a separate change process has approved them.
Purpose-built contracts: where possible use wallet contracts that only support the operations treasury actually needs, rather than general-purpose contracts with arbitrary delegatecall.
Front-end integrity: serve signing interfaces from infrastructure the exchange controls, pin scripts with Subresource Integrity, and alert on changes to static assets used by signers.

Signers themselves are identities to manage. Keep a register of every signer and co-signer key, which device holds it, who holds the device and who can revoke it. Require phishing-resistant MFA on the workstations and accounts signers use (see the Phishing-Resistant MFA Guide), use dedicated signing devices that are not used for email or browsing, and rehearse removing a signer within hours when someone leaves or a device is lost. The Crypto Wallet Security Guide covers wallet hygiene in more depth.

Developer workstations, cloud and CI/CD access

In most exchange compromises the first identity lost belongs to an engineer, not a signer. Anyone who can change withdrawal services, policy rules, wallet software or the front end can redirect funds without touching a key.

Tier the engineering estate: separate the repositories, pipelines and cloud accounts that touch wallet services from general product development. Fewer people should hold standing access to the wallet tier than to anything else in the company.
No standing production access: grant cloud administrative roles just in time, with approval and short expiry. See the JIT Access Guide.
Short and bound sessions: the Bybit chain ran through a developer's cloud access. Keep console and CLI sessions short, require re-authentication for sensitive actions, and alert when a session token is used from a new device or network. See the AWS Security Guide for platform settings.
Machine identities in pipelines: use workload identity federation instead of long-lived cloud keys in CI, scope deployment roles per environment and require two-person review for changes to wallet code and infrastructure definitions.
Hardened workstations: application allowlisting (which the FBI recommends for crypto firms), no local administrator rights, and separate devices or virtual machines for untrusted code.
Software supply chain: pin and review dependencies of wallet and front-end code. The Ledger Connect Kit compromise shipped a wallet drainer through a former employee's unrevoked publishing access, and the Solana web3.js compromise did the same with a key stealer.

Insider risk and the fake recruiter threat

Exchanges concentrate liquid, irreversible value, which makes insiders and impersonated insiders a first-order risk. Two patterns dominate.

Bribed or malicious staff

The Coinbase insider breach involved support agents who were paid to pass customer data to criminals, who then used it to impersonate the exchange to customers. No wallet key was touched: the stolen asset was customer data that made impersonation convincing. Controls: limit what support tooling shows (mask balances and contact data unless a ticket needs them), log and review bulk lookups, rotate staff away from high-value queues, and run screening proportionate to the role. See the Insider Threat Programme Guide.

North Korean recruitment and fake workers

The FBI's September 2024 warning describes North Korean actors who study crypto employees on professional networking sites, pose as recruiters or known contacts, build trust over long conversations and deliver malware through "pre-employment tests" or debugging tasks. Indicators include requests to run code on a company device, insistence on unusual video-call software and pressure to move to another messaging app. The FBI recommends verifying identities through a separate channel, keeping keys and seed phrases off internet-connected devices, doing coding tests only in a virtual machine on a non-company device, and requiring MFA plus approvals from several unconnected networks before moving company funds. The same actors also apply for jobs under false identities; see the Insider Threat from Fake IT Workers Guide. The JumpCloud breach shows North Korean operators using an identity platform to reach crypto customers downstream.

Role	Main identity risk	Minimum control set
Wallet signer or key share holder	Tricked into signing, or device compromised	Dedicated signing device, on-device verification, quorum, rapid revocation
Wallet and infrastructure engineer	Recruitment lure, session theft, malicious change	JIT access, two-person code review, hardened workstation, isolated testing
Customer support	Bribery, data harvesting	Masked data, lookup monitoring, case-bound access
Treasury and operations	Social engineering of approvals	Out-of-band confirmation, velocity limits, separation of request and approval
Contractors and new hires	False identity, excessive early access	Identity proofing at hire, staged access, no wallet-tier access in probation

Regulatory obligations: MiCA, DORA and NYDFS

Requirements differ by licence, but all three regimes expect documented control of keys, access and incidents.

Regime	Who it covers	Identity and key relevance
EU MiCA, Regulation (EU) 2023/1114	Crypto-asset service providers (CASPs) in the EU; full application from December 2024, with grandfathering under Article 143(3) until 1 July 2026 or an authorisation decision, according to ESMA	CASPs providing custody need a custody policy and client agreement and must keep client assets separate and unencumbered; recital 83 states they should be liable for losses resulting from ICT incidents, including cyber attacks and theft
EU DORA, Regulation (EU) 2022/2554	Financial entities including CASPs authorised under MiCA (Article 2(1)(f))	ICT risk management, access control and strong authentication, major incident reporting, resilience testing and third-party risk. See the DORA Guide
NYDFS 23 NYCRR Part 200 (BitLicense)	Virtual currency licensees in New York	Section 200.16: cybersecurity programme, written policy approved at least annually by the board, a designated CISO, annual report to DFS, annual penetration testing, quarterly vulnerability assessments and audit trails
NYDFS 23 NYCRR Part 500	DFS-regulated entities	MFA, access privilege reviews and CISO reporting obligations. See the NYDFS Part 500 Guide
NYDFS custody guidance	BitLicensees and limited purpose trust companies holding customer virtual currency	Segregation on-chain and in internal ledgers, no commingling, reconciliation of books to on-chain records on request, prior approval for new sub-custodians (the January 2023 letter was superseded by updated guidance in September 2025)

Check the current text and supervisory guidance for your licence before relying on this summary: MiCA technical standards are still being adopted and transitional arrangements vary by member state.

Rolling out the controls

Inventory (weeks 1 to 4): list every wallet, its custody technology, signer set and threshold; every service and person who can initiate, approve or broadcast a transaction; and every identity that can change wallet code, policy rules or signing interfaces. This inventory is the scope of everything else.
Close the single points (weeks 2 to 8): move any key found in files, environment variables or backups into HSM or MPC; remove standing cloud admin rights from engineers; enforce phishing-resistant MFA for signers, engineers and administrators.
Add independent verification (weeks 4 to 12): introduce on-device checks and a second transaction decoder for treasury moves. Run in parallel first: have signers record what the independent check shows for each transaction, then make a mismatch a hard stop.
Policy engine in monitor mode, then enforce: start by logging transactions that would break policy (new destination, delegatecall, amount over threshold), tune false positives with treasury for two to four weeks, then block. Keep a documented break-glass path with dual approval for genuine emergencies.
People controls: brief engineers and signers on recruitment lures, set up a no-blame route to report approaches, and isolate coding tests.
Rehearse: run a signer-compromise drill and a "front end tampered" drill each year. Rollback for each control is a documented, approved exception, not a silent disable.

Detection and measurement

Signals to log: every transaction request, approval and broadcast with the identity and device behind it; policy engine decisions; changes to signer sets or thresholds; changes to static assets of signing interfaces; cloud console and CLI sign-ins for wallet-tier accounts; bulk customer lookups by support staff.
Alerts that matter: delegatecall or upgrade operations on treasury wallets, signer approvals from new devices, session tokens reused from new networks, wallet code deployments outside change windows.

Metric	What good looks like
Treasury transactions with independent verification recorded	100%
Engineers with standing production access to the wallet tier	Trending to zero
Time to revoke a signer or key share after departure or device loss	Hours, measured in drills
Privileged identities on phishing-resistant MFA	100% of signers, engineers and administrators
Policy engine exceptions per month and their approval trail	Low, each with dual approval
Staff reporting suspicious recruitment approaches	Rising after training, a sign of awareness

Common failure patterns

Trusting the screen: multisig signers approved what a web interface showed, as in the Bybit hack. A threshold of honest signers using the same compromised interface is a threshold of one.
Keys reachable from a server: hot wallet keys in configuration files or memory of general-purpose hosts, the pattern behind the BitMart hot wallet hack.
Unrevoked access after people leave: publishing tokens and repository rights that outlive employment, as in the Ledger Connect Kit compromise.
Support tooling that shows too much: broad customer data in support consoles, exploited through bribery in the Coinbase insider breach.
Running the coding test: engineers executing a recruiter's repository on a work laptop, the exact delivery route the FBI describes.
Treating third-party wallet software as out of scope: the exchange's own infrastructure was not breached at Bybit, according to Sygnia, yet the exchange carried the loss.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Key generation, storage and use	SC-12, SC-13	PR.DS-01	8.24 Use of cryptography
Signer and administrator identities	IA-2, AC-2	PR.AA-01	5.16 Identity management, 8.5 Secure authentication
Quorum and separation of request and approval	AC-5, AC-6	PR.AA-05	5.3 Segregation of duties, 8.2 Privileged access rights
Wallet software and front-end integrity	SI-7	GV.SC-07	8.32 Change management
Staff screening and insider risk	PS-3	GV.RR-04	6.1 Screening
Monitoring of approvals and privileged activity	AU-6	DE.CM-03	8.16 Monitoring activities

Practitioner checklist

Maintain a live register of every wallet, custody model, signer, key share, threshold and the device each key lives on.
Remove every private key from files, environment variables and backups outside HSM or MPC.
Require on-device verification of destination, value, calldata, nonce and operation type before any treasury signature, with a second independent decoder.
Block delegatecall, upgrades and owner changes on treasury wallets through a policy engine unless separately approved.
Enforce phishing-resistant MFA and dedicated devices for signers, and just-in-time access for wallet-tier engineers.
Require two-person review for wallet code, policy rules and signing front ends, and monitor their static assets for change.
Run coding tests and untrusted repositories only in isolated environments on non-company devices, and train staff on recruitment lures.
Mask customer data in support tools and alert on bulk lookups.
Drill signer revocation and front-end tampering scenarios at least yearly.
Map controls to MiCA, DORA and NYDFS obligations for each licence held and keep the evidence current.

Standards and references

Related NHI Mgmt Group resources: Web3 and Crypto Security Guide · Cryptographic Key Management Guide · Privileged Access Management Guide · Insider Threat and Identity Guide · Lazarus Group Threat Actor Profile. This guide summarises regulatory obligations and is not legal advice.

Crypto Exchange Identity and Key Security Guide: Wallet Keys, Signing and Insider Risk