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

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.

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.

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

1. 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.
2. 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.
3. 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.
4. 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.
5. Purpose-built contracts: where possible use wallet contracts that only support the operations treasury actually needs, rather than general-purpose contracts with arbitrary delegatecall.
6. 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.

Regulatory obligations: MiCA, DORA and NYDFS

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

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

1. 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.
2. 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.
3. 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.
4. 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.
5. People controls: brief engineers and signers on recruitment lures, set up a no-blame route to report approaches, and isolate coding tests.
6. 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.

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

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

• FBI: North Korea Responsible for $1.5 Billion Bybit Hack (I-022625-PSA)
• FBI: North Korea Aggressively Targeting Crypto Industry with Well-Disguised Social Engineering Attacks
• EUR-Lex: Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA)
• EUR-Lex: Regulation (EU) 2022/2554 on digital operational resilience (DORA)
• Cornell LII: 23 NYCRR 200.16 Cybersecurity program
• NIST: Multi-Party Threshold Cryptography project
• Safe: How to verify Safe transactions on a hardware wallet
• NCC Group: In-depth technical analysis of the Bybit hack

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.