Digital asset security has two opposing failure modes. A compromised signing credential can allow assets to move irreversibly, while an overcomplicated security setup can leave the legitimate owner unable to recover them.
Good security therefore has to balance four objectives: preventing compromise, preserving legitimate access, enabling recovery, and controlling how transactions are authorized.
A wallet does not ordinarily contain the digital asset itself. Blockchain-based assets remain represented onchain. Wallet software or hardware manages the keys, key shares, or signing credentials that allow transactions to be authorized. NIST IR 8301 similarly frames token custody around wallet and key management rather than treating the wallet as a physical container for the asset.
The right security architecture depends less on finding the “most secure wallet” and more on understanding what could realistically fail.
Start With the Threat Model
Different threats require different controls. Remote compromise can involve malware, browser extensions, compromised devices, credential theft, or unauthorized remote access. Phishing and social engineering can trick a legitimate user into revealing credentials or signing a malicious transaction.
Physical risk includes device theft, coercion, fire, flood, or destruction of recovery material. Recovery failure can occur without an attacker at all, for example when a device is lost, a passphrase is forgotten, a keyholder becomes unavailable, or an employee leaves.
Institutions face an additional problem: a transaction can be cryptographically valid but organizationally unauthorized. A compromised administrator, malicious insider, incorrect beneficiary, or colluding signers may satisfy the technical signing process while violating policy.
Third-party custody introduces another category of risk, including provider compromise, operational outages, insolvency, sub-custodian dependencies, frozen withdrawals, or weak recovery processes.
A useful digital asset risk management process starts by identifying which of these failures would cause the greatest harm, then choosing controls that address them.
Hot, Warm, and Cold Storage Address Different Risks
Hot and cold storage are better understood as operational architectures than as specific products. A hot signing environment is online or readily connected. It can support frequent transactions and rapid access, but that connectivity creates a larger remote attack surface.
Cold storage keeps signing credentials offline or strongly isolated from network-connected systems. This reduces exposure to many remote attacks, but it can increase operational complexity and make recovery or urgent access more difficult.
Some institutions also use “warm” as an intermediate term for controlled environments that are not continuously exposed but can be brought online through restricted processes. The exact definition varies, so it should not be treated as a universal technical standard.
A hardware wallet can participate in either a cold or connected workflow depending on how it is used. Hardware device and cold-storage architecture are therefore not synonyms. For institutional designs, Kenson’s specialist research on Institutional Wallet Structures: Hot, Cold, and Multi-Layered Custody Explained examines wallet segmentation in greater depth.
Hardware Wallets Reduce Key Exposure, Not Every Security Risk
Hardware wallets can isolate private keys or signing operations from a general-purpose computer or smartphone. Depending on the device, transaction details can also be reviewed on a separate trusted display before approval. That architecture can reduce exposure to malware that attempts to copy private keys from ordinary software environments.
It does not make the overall security problem disappear. A hardware wallet cannot automatically protect against a compromised recovery phrase, a user approving a malicious transaction, phishing, physical coercion, an incorrect destination address, poor backup design, or compromised recovery procedures.
Institutional hardware-isolated signing goes considerably further than choosing a consumer device. It can involve HSMs, secure enclaves, role separation, approval policies, and controlled signing workflows. Kenson covers those architectures separately in The New Standard for Institutional Control: Hardware-Isolated Signing.
Recovery Material Can Be More Important Than the Device
For conventional seed-based self-custody, losing the device does not necessarily mean losing the assets. Losing or exposing the recovery material can be far more consequential.
Private keys, mnemonic or recovery phrases, optional passphrases, wallet backups, and MPC key shares are related but different concepts. Not every wallet uses the same recovery architecture.
For a conventional seed-based wallet, the recovery phrase should not be handled like an ordinary document. Current wallet guidance warns against screenshots, photographs, email, cloud drives, or other easily copied digital versions. Trezor’s recovery guidance is one implementation-specific example of this approach.
A sound backup design has to solve two problems simultaneously. Theft asks whether an unauthorized person could obtain enough recovery material to take control. Loss asks whether the legitimate owner could still recover after device destruction, fire, relocation, incapacity, or another disruption.
That means considering physical durability, confidentiality, redundancy, geographic separation, and recovery testing together. More copies are not automatically safer. Each additional backup location may improve disaster resilience while creating another place from which sensitive material can be stolen.
Optional wallet passphrases create a similar trade-off. They may strengthen a recovery architecture, but forgetting the passphrase can also make legitimate recovery impossible. Manually cutting a seed phrase into arbitrary fragments should not be confused with protocol-supported threshold backup schemes.
Account Authentication and Blockchain Signing Are Different Controls
Custodial exchanges, custodian portals, email accounts, password managers, and administrative systems depend on conventional account authentication. These systems should use unique credentials, appropriate password management, and MFA.
Not all MFA methods provide equal protection. CISA recommends phishing-resistant authentication, particularly FIDO/WebAuthn, where supported. SMS-based authentication can still provide an additional barrier where stronger alternatives are unavailable, but it is more exposed to phishing, SIM-swap, and account-recovery attacks.
MFA protects conventional accounts, not a self-custody private key. Account authentication and blockchain transaction signing should remain separate control layers.
Phishing Can Bypass Otherwise Strong Security
Many digital-asset attacks do not require stealing the private key directly. Instead, the attacker persuades the legitimate user to perform the harmful action. Common examples include fake customer-support representatives, lookalike domains, malicious wallet interfaces, account-recovery impersonation, urgent transfer requests, and signing prompts that authorize token movement or contract permissions.
- Never disclose recovery material to supposed support personnel.
- Independently verify support channels and inspect domains before connecting a wallet.
- Review transaction details before signing and treat unexpected signing requests as suspicious.
- Use separate verification channels for high-risk institutional instructions.
Kenson’s Protecting Against Phishing and Social Engineering Attacks examines this attack class separately.
Multisig and MPC Distribute Transaction Authority Differently
Multisignature and multiparty computation are often grouped together because both can reduce reliance on one credential, but they use different architectures.
A multisig wallet uses multiple independent private keys and requires a defined threshold of signatures, such as two of three or three of five, before a transaction is valid. This can distribute authority across people, devices, or locations. Its effectiveness still depends on signer independence, backup separation, threshold choice, recovery planning, and blockchain support.
MPC or threshold-signature systems distribute cryptographic shares among participants or systems that jointly produce a valid signature. In properly designed threshold architectures, the complete private key does not need to be reconstructed in one location during signing. MPC should not simply be described as cutting an existing private key into encrypted fragments, because implementations and recovery models differ.
Neither technology automatically guarantees security. Multisig can create coordination and signer-availability problems. MPC can introduce implementation, service-provider, recovery, and infrastructure dependencies.
Kenson’s Multi-Signature Protocols: Strengthening Institutional Wallet Governance provides deeper coverage of institutional threshold controls.
Security Controls for Individuals
Individual security should remain simple enough to operate and recover reliably. A practical workflow is:
- Identify whether remote compromise, physical theft, recovery failure, or third-party dependency creates the greatest risk.
- Separate assets needed for frequent activity from assets that rarely move where appropriate.
- Consider hardware-isolated signing when the value and threat model justify it.
- Protect recovery material offline and against both theft and physical destruction.
- Protect custodial accounts, email, and related services with strong authentication.
- Verify destinations and transaction details before signing.
- Maintain a recovery process that can actually be followed after device loss.
- Reassess the design after major changes to devices, residence, custodians, or access arrangements.
The goal is not maximum complexity. A security system that the legitimate owner cannot reliably operate or recover may create a different form of loss.
Institutional Security Requires Governance Around the Wallet
Institutional custody adds failure modes because authority spans teams, systems, service providers, and approval processes.
A strong digital asset custody architecture should distinguish custody, control, and access. Custody concerns who holds or manages signing credentials. Control concerns who is authorized to approve movement. Access and execution concern who can initiate or carry out an approved action. These roles should not automatically collapse into one administrator.
Institutional digital asset internal controls may include wallet segmentation, least-privilege access, role-based permissions, segregation of initiation, approval, and execution, multisig or MPC thresholds, hardware-isolated signing, destination allowlists, transaction limits, logging, signer rotation, personnel controls, recovery testing, and business continuity.
NIST’s Cybersecurity Framework 2.0 similarly treats cybersecurity as a lifecycle covering governance, identification, protection, detection, response, and recovery rather than protection alone.
For deeper institutional architecture, see Wallet Architecture Fundamentals: Why Control, Custody, and Access Are Not the Same Thing.
How to Evaluate a Third-Party Custodian
Third-party custody reduces some self-custody responsibilities but introduces counterparty, operational, legal, and dependency risks. Due diligence should examine several layers.
- Legal entity and jurisdiction: Which company actually provides custody, and which laws and contractual terms govern the relationship?
- Regulatory status: What licenses or authorizations apply, and what do they actually cover?
- Asset segregation: Are customer assets separately accounted for from corporate assets? If omnibus wallets are used, how are customer interests reconciled?
- Signing architecture: Does the provider use HSMs, multisig, MPC, cold storage, or another model? Who can authorize withdrawals?
- Access and transaction controls: What MFA, role separation, approval workflows, withdrawal restrictions, and monitoring controls exist?
- Sub-custodians: Does another provider ultimately control some assets or infrastructure?
- Security assurance: What independent audits, testing, incident disclosures, certifications, or vulnerability-management evidence is available?
- Continuity and recovery: How would the provider respond to key failure, outages, compromised infrastructure, or disaster?
- Insurance: What specific incidents and assets are covered, and what exclusions, limits, conditions, and deductibles apply?
- Insolvency and customer rights: How are customer assets characterized under the agreement and relevant law if the provider fails?
- Exit and portability: Can assets be withdrawn or transferred without relying on one irreplaceable provider?
New York Department of Financial Services guidance issued in September 2025, which applies within its own regulatory jurisdiction, emphasizes customer-asset segregation, separate accounting, clear beneficial-interest records, and due diligence around sub-custody arrangements. NYDFS custody guidance provides one regulatory example, not a universal rule for every organization.
Third-party review should continue after onboarding. NYDFS third-party service-provider guidance emphasizes due diligence, contracting, ongoing oversight, continuity, downstream providers, and termination planning across the relationship lifecycle.
Kenson’s Third-Party Dependency Risk: Securing the Infrastructure You Do Not Control examines dependency risk beyond custody alone.
Recovery Is Part of Security
Security planning should assume that something eventually becomes unavailable. The event may be a lost device, inaccessible backup, suspected seed compromise, failed signer, employee departure, custodian outage, or physical disaster.
A useful high-level recovery sequence is: contain → verify → rotate or restore → validate → resume. If a signing credential may have been compromised, restoring access without addressing that compromise can simply recreate the exposure.
Recovery therefore needs documented responsibilities, alternative access paths, communication procedures, and testing before an incident occurs.
Kenson’s Building a Recovery Playbook for Wallet, Network, and Custody Failures addresses the operational workflow in greater depth.
Match Controls to the Threat
| Threat | Individual controls | Institutional controls |
| Remote compromise | Hardware signing where appropriate; patched devices; limited online exposure | Isolated signing; endpoint controls; least privilege; transaction policy |
| Phishing/social engineering | Domain verification; no seed disclosure; phishing-resistant MFA on accounts | FIDO/WebAuthn; independent verification; employee training; approval separation |
| Physical loss/disaster | Durable offline recovery backup; appropriate geographic redundancy | Distributed recovery systems; separated signing components; continuity testing |
| Backup/recovery failure | Tested recovery process; documented continuity plan | Threshold recovery; signer substitution; key/share rotation; tested recovery procedures |
| Insider or authorized misuse | Transaction and destination verification | Segregation of duties; multisig/MPC; allowlists; limits; policy approvals; audit logs |
| Third-party failure | Understand custody terms and withdrawal options | Custodian/sub-custodian due diligence; contractual controls; alternative providers; exit plan |
This framework is not a security score. It is a way to connect likely failure modes with controls designed to address them.
Strong Security Is a Balance of Failure Modes
Every security control introduces a trade-off. Cold storage reduces online exposure but can slow access. More backups improve resilience but create more locations to protect. Multisig reduces unilateral authority but complicates signer coordination. MPC reduces single-key dependence but adds implementation or provider dependencies. Third-party custody reduces self-custody burdens while adding counterparty and insolvency risk.
The strongest design is therefore not necessarily the one with the most controls. It is the architecture that addresses the most important threats while preserving usable recovery, operational continuity, and accountable authorization.
That principle is central to digital asset operational risk management and institutional digital asset readiness.
Explore the Kenson Investments Knowledge Centre for deeper educational research into custody, wallet architecture, signing controls, recovery, and digital asset infrastructure. Organizations assessing operational controls or custody dependencies can also contact Kenson Investments for additional information.
Disclaimer: The information provided on this page is for educational and informational purposes only and should not be construed as financial advice. Crypto currency assets involve inherent risks, and past performance is not indicative of future results. Always conduct thorough research and consult with a qualified financial advisor before making investment decisions.
The crypto currency and digital asset space is an emerging asset class that has not yet been regulated by the SEC and US Federal Government. None of the information provided by Kenson LLC should be considered as financial investment advice. Please consult your Registered Financial Advisor for guidance. Kenson LLC does not offer any products regulated by the SEC including, equities, registered securities, ETFs, stocks, bonds, or equivalents.
