CyphrQ
Menu

Crypto Custody Security for Businesses: Wallets, Keys and Signing

How businesses keep crypto keys safe: hot, warm and cold wallets, multisig vs MPC, blind signing, key ceremonies, withdrawal controls and monitoring.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

11 min read

Crypto custody security is the set of controls that decide who can move a business's crypto, and how. In practice: keep most funds offline, require several independent approvals, make sure signers can see what they sign, split and test backups, separate duties, limit where withdrawals can go, and watch every wallet.

None of this is new. Dubai's Virtual Assets Regulatory Authority (VARA) writes most of it into its rulebooks, and the CryptoCurrency Security Standard (CCSS) turns it into numbered controls. This post is part of our Crypto Security coverage. It is security guidance, not investment or legal advice.

Why do attackers go after crypto custody instead of the blockchain?

Because the people and systems that approve transactions are easier to fool than the cryptography. Bybit lost "approximately $1.5 billion USD in virtual assets" in February 2025, in a theft the FBI attributes to North Korea (FBI IC3). Our Bybit case file covers how that happened. The short version for this post: the wallet design worked, and the signing process did not.

After a theft, recovery depends on other people. In the Bybit announcement the FBI asks node operators, exchanges, bridges and analytics firms to "block transactions with or derived from addresses TraderTraitor actors are using to launder the stolen assets".

The FBI used the same name, TraderTraitor, years earlier. A 2022 joint advisory from the FBI, CISA and the US Treasury lists its targets: crypto exchanges, DeFi protocols, play-to-earn games, trading companies, crypto venture funds, and individuals holding large amounts of crypto or valuable NFTs (CISA AA22-108A). Intrusions start with spearphishing aimed at system administration and DevOps staff, often dressed up as a recruitment offer.

What is the difference between hot, warm and cold crypto wallets?

A wallet is really a set of private keys. The key, not the coins, is what you protect. The categories describe how reachable the keys are.

Type Where the keys are Typical use Main risk
Hot On an internet-connected system Small balances for day-to-day withdrawals Remote compromise of the server or its credentials
Warm Online, but signing needs extra approval or a delay Topping up the hot wallet Approval process bypassed or rushed
Cold Offline, in hardware or secure storage Most of the funds Signing ceremony manipulated; lost or badly stored backups

"Warm" is industry shorthand. None of the official sources I read defines it, so ask any provider what it means by the word.

VARA does not prescribe a split. Its Custody Services Rulebook requires a "risk-based analysis to determine the method of Virtual Asset storage" (Rule III.C.1.b), and says transfers between wallet types should be "subject to internal controls and audits performed by an independent third-party auditor" (III.C.1.c). It also says keys stored online or in one physical location must not be "capable of conducting a Virtual Asset transaction" unless physical access alone is not enough to transact (III.C.2.b). All three are in the VARA Custody Services Rulebook.

Should a business use multisig or MPC to protect crypto keys?

Both remove the single key that can empty a wallet. They do it in different places.

  • Multisig (multi-signature) is enforced by the blockchain or a smart contract. The wallet needs M approvals out of N keys, for example 2 of 3.
  • MPC (multi-party computation) splits one key into shares held by different parties or devices. The shares work together to produce a signature, and the full key is never meant to exist in one place. On-chain it usually looks like an ordinary single signature.

NIST's definition of "split knowledge" in SP 800-57 Part 1 Rev. 5 describes the idea behind key shares: if k shares are needed, "knowledge of any k – 1 key shares provides no information about the key other than, possibly, its length" (NIST glossary). I did not find an official standard specific to MPC wallets, so treat a vendor's MPC claims as claims to test.

What the rulebooks say about quorums:

  • VARA says firms "should consider using multi-signature approaches where appropriate" and reserves the right to require them (Rule III.C.2.d, Custody Services Rulebook).
  • VARA's technology guidance suggests minimum multi-signatures for high-value operations, with the number of signers M "greater than the total number of signatories (N) divided by two (2)", plus geographic distribution and separation of duties between signers (Schedule 1, B.5, VARA Technology and Information Rulebook). Schedule 1 is guidance, not a binding rule.
  • The CCSS v9.0 matrix says "wallets that manage the bulk of customer's funds must implement a multi-signer mechanism" (rationale to 1.02.1.1). It also asks for at least one redundant key for recovery (1.02.2.1) and keys stored in different locations (1.02.3.1).

Neither design helps if every signer approves the wrong transaction. That is the next problem.

What is blind signing, and why is it the weak point in crypto custody?

Blind signing means approving a transaction whose real content you cannot read on a screen you trust. You see a summary, a hash or a friendly label, and you sign.

The Bybit case is the clearest example. The signers saw what looked like a routine transfer, and the transaction did something else. Adding more signers adds nothing if they all read the same tampered screen.

The controls are about seeing the transaction independently:

  • VARA's guidance asks for "clear procedures for signers to verify and validate transactions" and "immediate halting of the signing process when errors are reported" (Schedule 1, B.6).
  • CCSS control 1.05.8.1 says "Verification of fund destinations and amounts is performed via Approved Communication Channels".
  • Decode and check the transaction on a second tool that did not propose it, ideally the signing device's own display.
  • Never approve because of a call or a video meeting alone. Voices and faces can be faked, as my guide to deepfake scams explains.

How should a business run a crypto key ceremony and store backups?

A key ceremony is the scripted, witnessed event where keys or key shares are created. Done well, it leaves evidence that no one person ever held, or could quietly copy, the key.

CCSS v9.0 asks for "a detailed runbook" covering every generation step, with participants signing off after each step, and says each participant "must independently generate their own discrete key material" (1.01.3.2). It also says the generation mechanism "conforms to NIST SP 800-90A", NIST's random number generator standard (1.01.3.1). VARA's guidance adds hardware security modules (HSMs) "where possible", "separation of duties during key generation" and "comprehensive audit logging of all generation activities" (Schedule 1, B.1).

Backups are where good ceremonies quietly fail. VARA's binding custody rules (III.C.2.c) say:

  • backups go "in a separate location from the primary key and seed";
  • they are encrypted at least as strongly as the primary;
  • "the mnemonic back-up seed phrase is broken into at least two (2) parts";
  • backups that together could authorise a transaction "must not be stored in a single point of access".

CCSS adds geographically separate storage (1.03.3.2) and tamper evidence (1.03.5.1). VARA's guidance asks for "regular testing of key backup and recovery procedures" (Schedule 1, B.3). An untested backup is a hope, not a control.

How does separation of duties work for crypto withdrawals?

Separation of duties means no single person can create, approve and execute a movement of funds. In crypto it has to cover key creation too.

VARA asks custodians to consider whether people who create seeds or keys "should be prohibited from cryptographically signing any transaction" (III.C.2.a) and to "mitigate the risk of collusion between all authorised parties or signatories" (III.C.2.e). It requires "a separate team to handle the VASP's Custody Services only" (III.B.7). Its guidance asks for "multiple levels of approval for new wallet creation" (Schedule 1, B.2).

A simple role split for a small team:

Role Does Must not
Requester Raises the withdrawal with a business reason Approve or sign it
Approver Checks the reason, destination and amount Hold a signing key for the same wallet
Signers Verify independently, then sign Create the keys they sign with
Reviewer Reconciles balances and reviews logs Change addresses, limits or quorums

Do allowlisted withdrawal addresses and limits stop crypto theft?

They narrow it. An allowlist means the wallet or platform will only send to addresses approved in advance. None of the official sources I read uses the word, so treat this as my recommendation rather than a rule.

VARA's guidance covers the limits side: "tiered withdrawal limits", "cooling periods for large transactions", "graduated approval requirements based on transaction value" and "behavioural analysis to detect anomalous withdrawal patterns" (Schedule 1, D.2).

Two cautions. First, the allowlist itself becomes the target, so adding an address should need two people and a waiting period. Second, an allowlist checks where funds go in a normal transfer. It does not catch a transaction that changes the wallet's own logic, which is what the Bybit case files describe.

What should crypto custody monitoring watch for?

Watch the keys and the chain, not just the servers. VARA's guidance says logging should "include all wallet and key operations" with "real-time alerting for security events" (Schedule 1, B.13), and asks for "automated detection of anomalous transactions in real-time" during signing (B.6). CCSS 2.02.4.1 asks for monitoring of relevant blockchain state, confirmed and unconfirmed.

Screen inbound funds and counterparties against addresses law enforcement publishes. The FBI's Bybit announcement lists Ethereum addresses linked to the laundering.

Going deeper: for security and IT teams

Standards and rule IDs I read. NIST SP 800-57 Part 1 Rev. 5 (split knowledge, via the NIST glossary); I could not read the full PDF. CCSS v9.0 aspects 1.01 to 1.06 and 2.01 to 2.04, named on C4's key material page. VARA Custody Services Rulebook Part III, and Technology and Information Rulebook Schedule 1. The CCSS page text came through flattened, so I quote control IDs but not which level each sits at. Confirm levels in the live matrix.

Threat model. The attacker is often state-linked, funded and patient. Per AA22-108A, TraderTraitor apps are cross-platform Electron applications posing as crypto trading or price-prediction tools. An update function downloads a payload, mainly the Manuscrypt remote access trojan. Post-compromise activity is tailored to the victim and has sometimes been completed within a week. The attacker needs a foothold on any machine in the signing path: a signer's laptop, a DevOps workstation, or a third party's front end. The prize is one valid quorum signature on a transaction the signers did not mean to approve.

Controls with specifics.

  • Signing environment. CCSS 1.05.2.2 says key material is isolated from other operating systems and application processes. Use dedicated signing devices with no email, browsing or chat.
  • Access. CCSS 1.05.1.1 requires an identifier plus at least two distinct factor types for operational key material.
  • Quorum. Set M greater than N/2 (VARA Schedule 1, B.5), spread signers across locations, and exclude key creators from the quorum where VARA III.C.2.a applies.
  • Software supply. AA22-108A recommends application allowlisting and verifying that software, especially cryptocurrency applications, comes from a reputable or primary source. Apply that to wallet apps, browser extensions and signing tools.
  • Independent decode. Before the final signature, decode calldata and destination on a second, independently built tool. Treat any delegate call or change to wallet owners, thresholds or modules as a stop-and-escalate event.
  • Key compromise. CCSS 2.04.1.2 asks for a documented Key Compromise Policy, using roles rather than names, and 2.04.2.1 asks for it to be tested at least annually.

Detection and evidence.

  • Alert on any change to signers, thresholds, allowlists or withdrawal limits, and require a second person to acknowledge it.
  • Alert on a signing request outside business hours or above the tier limit.
  • Alert on a new device or location for any signer.
  • Alert on outbound transfers to addresses not seen before.
  • Alert on failed authentication bursts against signing systems (VARA Schedule 1, C.2).
  • Keep signed runbooks from every ceremony. Keep reconciliation records too: VARA III.D.5 asks for a full transaction audit trail for at least eight years.
  • Test controls by running a withdrawal drill with a deliberately wrong destination. Measure whether signers catch it.

Two documented examples. The FBI attributes "approximately $1.5 billion USD in virtual assets" stolen from Bybit to North Korea (FBI IC3). In 2022 the FBI, CISA and Treasury warned that the same activity targets admin and DevOps staff with fake job offers (CISA). Together they describe the pattern: compromise a person or supplier, then abuse a legitimate signing flow.

What to ask a custodian or wallet vendor.

  1. What is the quorum on each wallet, and where is each signer?
  2. How does a signer see the decoded transaction, and on which device?
  3. Who can change allowlists, limits and signers, and what delay applies?
  4. When was backup recovery last tested, and can I see the evidence?
  5. Which CCSS level, or which regulator's custody rules, are you assessed against, and by whom?

What should your business do about crypto custody security this quarter?

  1. Write down every wallet, its balance band, its quorum and who holds each key.
  2. Move funds above daily needs out of hot wallets, with a documented reason for the split.
  3. Require independent transaction verification before every high-value signature.
  4. Split seed backups, store them apart, and run a recovery test.
  5. Put allowlists, limits and a delay on address changes.
  6. Add wallet and key events to your alerting, and rehearse a key compromise. My guide to breach notification deadlines helps with the reporting side.

If you deal with EU firms, my MiCA explainer covers the safekeeping rule for client assets.

Learn more

Key takeaways

  • Crypto custody security is about keys and approvals, not the blockchain.
  • Keep most funds offline and make online keys unable to move funds alone.
  • Multisig and MPC both remove the single key. Neither stops a quorum from signing a manipulated transaction.
  • Blind signing is the gap: verify every high-value transaction on an independent tool or device.
  • VARA requires backups stored apart, equally encrypted, with seed phrases split into at least two parts.
  • Keep key creators, approvers and signers separate, and test backup recovery and compromise plans.

Sources