Defending Cold Wallets: Guidelines for Financial Institutions

 

If you’re a bank or an exchange, your cold wallet safeguards assets far more valuable than those in hot wallets, often amounting to billions of dollars. Attackers may thus invest millions to compromise it by funding a team for months, and investing in phishing, exploits, supply chain sabotage, and insider compromise. Attackers don’t need the keys stored in the wallet, they just need access to the signing capabilities, and only once—bitcoins moved to an attacker-controlled address are lost forever, unless the attacker is a very dumb one.

Nation states and so-called sophisticated cyber attackers aren’t the only foes. Physical attacks are another threat, from armed assault to kidnapping and worse (see "They Stole a Quarter-Billion in Crypto and Got Caught Within a Month" and "$100M Ledger Kidnapping: How Crypto Millionaires Became Crime Targets").

You’re also exposed through your suppliers: hardware vendors, cloud providers, auditors, open-source projects. Then there’s the insider threat—the familiar menace of collusion and disgruntled staff. But insider threats are not only intentional; they are more often accidental than intentional, arising from poor security controls, negligence, incompetence, sheer bad luck, or a combination thereof. If your backups don’t work the day you need them, then there’s no external attacker to blame.

This document outlines measures to counter those threats. While not exhaustive, it addresses blind spots often neglected in technology-centric frameworks. Part of the content applies to warmer wallets as well. Our recommendations are grounded in experience; we not only design cold wallets, we also secure our own wallets and help clients do the same.

We assume that you start from a solid foundation: a comprehensive security program, secure execution environments, hardware tokens, a policy engine, multi-party approval workflows, backup measures, and so on. We won’t remind you to run pentests or choose strong passwords—those are table stakes. Our focus is on controls that lie beyond the obvious. We assume a motivated, well-resourced attacker with knowledge of banking operations, including insider recruitment and technical subversion capabilities.

At this point, you might think, “But they haven’t defined what a cold wallet is.” That’s because our readers will know. They will know that if a wallet allows automated transfers via API, or does not use secure hardware, or does not involve airgapped components, or does not require multiple approvals, then this wallet is not cold.

Do not unnecessarily expose information 

The first stage of any offensive operation is reconnaissance, or information gathering. The less an attacker knows about how you operate, the harder their job will be. Minimizing information exposure and consistently applying need-to-know is hard. You must know what information is valuable, who may exploit it, and who may access it. Below, we only give a few examples of information exposure—you should make your own assessment and restrict access accordingly. (When recommending restricting access to information, we sometimes hear the objection, “But security by obscurity is a bad thing”—a telltale sign that the person understands neither security nor obscurity.)

Internal exposure 

Your cold wallet may be configured to require three approvals to validate a transfer: one from a person in group 1, one from a person in group 2, and one from a person in group 3. Do these group members know their fellow group members? The members of other groups? Who else in the organization knows the responsibilities of these people? If the answer is “all the IT department,” then it most probably is not the answer you want. You also need to ensure that the intersection of those three groups is the empty set.

Besides roles and responsibilities, the following information should be restricted to people who need it:

• Workflows and procedures – such as transfer approval policies, role management procedures, and access control measures.

• Custody solution internals – such as architecture diagrams, penetration test reports, and source code.

• Wallets and activities – such as wallet structure, list of addresses, corresponding identifiers or paths, and blockchains used (Layer 1 and 2).

• Contingency plans – such as backup details (secret sharing, location, recovery scripts) and disaster recovery test reports.

Standard information security methods may be used—access control, security zoning, document classification, and so on.

External exposure 

External parties include, for example, clients, auditors, and suppliers. On the one hand, you need to reassure your users and show some transparency; on the other hand, you can’t reveal too much. The trade-off will be different for a private bank than for a retail-oriented exchange.

As of April 2025, the textbook counterexample is a famous “smart account wallet” running on Ethereum as a smart contract, thereby exposing the following information to anyone with an internet connection:

• The exact logic of the wallet and its full source code.

• The multi-signature approval rules and the public keys of the authorized signers.

• The details and timestamps of all transactions performed.

Attackers also know the developers of that wallet’s smart contract, and the author of each change, via GitHub’s open-source code records. They can even run their own programs on the very same platform the cold wallet application ran on—Ethereum. From a security perspective, this is demented—at least for a cold wallet.

On-chain exposure

Even if you don’t use smart on-chain wallets, your activities on public blockchains are logged forever and readable by anyone. The information exposed includes:

• The transactions involving your cold wallet addresses (or just “cold addresses”), including transfers and smart contract interactions.

• The balance held by your addresses at any time, in native coins and other tokens.

• The counterparties you interact with, via their addresses (which may reveal their identity directly or later).

If some of your cold addresses were identified as belonging to your organization, they are likely scrutinized by public and private intelligence organizations—and by criminals. Alas, cold addresses aren’t always difficult to uncover. For example, if clients deposit crypto assets, then you must reveal an address—likely not from a cold wallet. However, funds may later flow from that deposit address into a cold address. Unless you use mixers (unlikely and not recommended) or private transfer technologies, anyone may identify addresses that receive assets from a deposit address.

To make cold addresses harder to identify, you may distribute funds across many different addresses in an uneven way: instead of having exactly 100 BTC on each cold address, have addresses with (say) 3 BTC, 12.5 BTC, 50 BTC, 24 BTC, etc.

Beyond hiding addresses, you should hide your on-chain activities. For example, do not disclose names or identifiers tied to your organization in any blockchain transaction. Similarly, do not test the smart contract of a future tokenized product by naming your token “MYBANK test token” on a public testnet. To assess your exposure, run proactive blockchain counterintelligence tests—internally or externally—to see what attackers would see.

Finally, assume that all public blockchain nodes record your IP address and its association with on-chain addresses. Avoid connecting directly to the network from your organization’s IP range. A mobile hotspot can be useful to anonymize location without having to resort to, for example, the Tor network.

OPSEC

Operational security is about reducing security risk in the day-to-day operations of the cold wallet. We’ll briefly cover some of the most salient aspects.

Communication

Do not use cleartext communication channels when planning transfers from a cold wallet. That means not using SMS, Telegram, or email to tell your colleagues that you need to move 100 bitcoins to address XYZ in two days. In-person discussions or end-to-end encrypted channels should be used instead. Signal may be fine—as long as you don’t include journalists, the U.S. Secretary of Defense, or family members in your group.

Hardware equipment 

Consider using dedicated devices for cold wallet operations. If your cold wallet solution relies on a client application running on Windows, macOS, Linux, iOS, or Android, then you may use different platforms for different users. This reduces the risk of a platform-specific exploit being used to target all your users.

Dedicated devices should not reduce security or increase exposure, however. An employee carrying two separate devices may be identified as a cold wallet operator. Also, do not add a big sticker reading “cold wallet laptop” to your machine or on the front door of your cold operations room. Likewise, avoid carrying a cold wallet hardware token on your keychain at all times. This could reveal to prying eyes that you have specific access or responsibilities.

Note that a secure data center ceases to be secure when someone with access can be blackmailed into granting it to a criminal third party. Having a secure, certified, and audited data center does not exempt you from ensuring that physical access to systems there is not sufficient to perform transactions.

Location and time 

When interacting with a cold wallet via a computer, mobile device, or hardware token, the following sensitive information may be visible to an observer:

• On screen: configuration details, amount transferred, addresses involved.

• Off screen: passwords and PINs entered on a keyboard or other interface.

You must therefore avoid places where people or devices could be watching. In an office, be mindful of vantage points from surrounding buildings and avoid rooms with windows facing adjoining structures. You do not need a SCIF, but avoid open-space offices, public places, or locations with surveillance cameras. If you do use a SCIF-like room, check that nobody has placed a cable to a screen to receive notifications from a mobile device left outside.

To make your operations less predictable to attackers, vary locations and timings. For example, avoid establishing a routine cold wallet transfer every Tuesday at 10 a.m. in office 37B, especially if the office’s windows face a hotel.

Social interactions 

If you have access to information about the cold wallet or its backups, do not mention it to anyone who doesn’t need to know: colleagues, clients, spouses, charming encounters who offer you a drink at conferences, or online social networks such as LinkedIn—where entering “Cold wallet admin” or “Backup recovery testing” in your job description is unwise (believe us, we’ve seen these things).

Refrain from bragging about the ultra-high security of your cold wallet or the number of commas in the assets under management, especially in public. This is just a way of saying “please hack us,” or worse, inviting “physical attention” from criminals.

Conversely, avoid hinting at potential security defects or incidents to anyone not explicitly authorized. This kind of information inevitably leaks, gets amplified, and becomes distorted. (It is also, quite often, a sackable offense to put your employer into disrepute.)

Insider threat and personnel security 

To manage the risk of malicious insiders, you must go beyond minimal background checks. Simply reviewing debt and criminal records is insufficient. Jointly with human resources, security staff should assess insider risk using more advanced information and methodologies, while respecting applicable laws and individuals’ privacy. For example, you may use the established Critical Path Method (see "Application of the Critical-Path Method to Evaluate Insider Risks"). We also recommend the CISA’s "Insider Threat Mitigation Guide".

Also, what happens when someone involved in cold wallet operations leaves the company? Which credentials must be revoked? Which keys must be rotated? What access and information did they have, exactly? You must be prepared to answer these questions and execute the relevant procedures at short notice, especially in the case of a “bad leaver.”

Against other threats to individuals (armed assault, kidnapping, blackmail, etc.), offer concrete guidelines and training material to help minimize risk for employees. Include such threats in your contingency planning program, covering awareness, testing, and communication. For example, you may collect emergency personal contacts for those at highest risk.

Backups management 

Backups are the last resort if all your network is down, if all your HSMs fail, and if key people die in a helicopter crash. Backups are crucial to implement the always–never principle of cold wallets: unauthorized transactions must never be possible, authorized transactions must always be possible. In comparison, the cold wallet infrastructure must only prevent unauthorized transactions; it can tolerate failure, but backups cannot. Backups must always work now and decades from now. This is why backup management is hard.

When helping clients preparing key ceremonies, where backups are created, they often ask us for the best practices regarding points such as:

• Storage media: USB drives, smart cards, sheets of paper, CD-ROMs, parchment palimpsests, or a combination thereof?
• Number of shares and quorum parameters: 2 out of 3? 3 out of 5?
• Storage container: Standard banking security envelope? Paper envelope?
• Tests: How often should you test backups recovery?

We reply that there is no single right answer—the answer depends on your internal procedures, risk appetite, and infrastructure. But whatever specific tools and parameters you choose, you must adhere to these key principles:

• Redundancy and quorum: Split backup data into multiple parts, or shares, such that 1) the loss of one share does not prevent recovery and 2) a minimum number of shares is necessary to reconstruct the key. This is typically implemented with threshold secret-sharing cryptographic mechanisms.
• Access control: Restrict access to backups to authorized personnel only and ensure segregation of duty. Access to the backup storage facilities must be logged and monitored (for example by staff of bank safes).
• Tamper evidence: Ensure that any attempt to access or modify backup data is detectable. This may be done with handwritten signatures of participants on the container bearing a unique ID, and storing a photo as evidence, which should be verified during periodic integrity tests.
• Geographical distribution: Store shares in different locations. For example, an exchange may store shares in safes in different banks located in different cities.
• Regular testing: Verify the integrity and recoverability of your backups, for example once a year. The methodology and software used should be recorded as part of the test report.
• Software and hardware compatibility: Technology must be ready and tested to perform a transaction from the backups. To prevent vendor lock-in, you should not depend on a single vendor to provide software or hardware. For example, compatibility with open standards and open-source software tools is recommended.

In addition, a backup escrow or “dead man’s switch” should be defined, in case parties authorized to access backups are incapacitated or compromised.

Cyber and airgaps 

The pure technical, cyber-security best practices applicable to critical systems such as a cold wallet are well known. For example, about:

• Access control: MFA, RBAC, SoD, logging and monitoring, etc.
• SSDLC: Code reviews, quality and security tests, signed commits, and of course supply-chain attack mitigation and SBOM.
• Cryptography, where one should not only worry about what is used but also how, and more importantly, how keys are managed. 
• Isolation and hardening of computing environments, via virtualization technologies and TEEs of various types, which may or may not rely on hardware-level roots of trust (for a quick overview, see "TPMs, TEEs, and Everything In Between: What You Actually Need to Know").

We won’t elaborate either on key management, in particular the indispensable key ceremony. You may refer to §3.3 and §3.4 of CMTA’s "Digital Assets Custody Standard (DACS)" for specific recommendations.

Instead, we’ll comment on the notion of airgap. Airgapped cold wallets are more secure than non-airgapped ones, of course, but what does that even mean?

Airgapped means physically isolated: no cables, no wireless, no indirect connection, nothing that could allow data transfer, permanently or temporarily, even if blocked logically (e.g., via firewall or software data diodes, container isolation, proxy systems). But saying a system is airgapped means nothing unless you specify relative to what, isolated from what. In cold wallet contexts, “airgap” usually refers to isolation from any network that includes systems likely to be compromised, such as internet-connected devices.

Vendors sometimes claim their wallet is airgapped because the key-signing components are isolated, but even then, blockchain interactions (e.g., fetching nonces, broadcasting signed transactions) require some form of information flow. Techniques like manual input of hashes or signed transaction data reduce certain risks but create usability and security trade-offs, especially if transaction verification is weakened (as in the case of “blind signing”).

In practice, you can thus achieve partial and temporary airgapping, which risk-wise may be sufficient if properly designed. For example, by manually connecting hardware modules required to create the signature request attestation (which Taurus-PROTECT does by default), or by logically connecting the component performing the signature and policy engine checks (via its network or container interface).

Conclusion 

When the loss of a 256-bit string implies the irreparable loss of billions in value, you need greater security than for most of your organization’s activities. Otherwise, the probability of a catastrophic loss is only a matter of time.

Until recently, criminals have focused on the sub-par security of many “web3” projects like bridges, DeFi platforms, layer 2 protocols, and obscure exchanges. But while the low-hanging fruits get picked, legitimate institutions manage greater volumes of cryptocurrency, and attackers develop more elaborate tactics to target them.

Smaller organizations that do not have the resources to manage a proper cold wallet—and that sometimes don’t even have backups—often hold large amounts of assets. Over time, losses from malicious insiders or accidents accumulate—and often go unreported.

We hope that this guide will contribute to more secure cold wallets and fewer loss-of-funds incidents.

Acknowledgments: We thank Arrigo Triulzi for his feedback on a draft of this article.