Financial institutions entering digital asset custody face a challenge that has no equivalent in traditional finance: the asset itself is a cryptographic key. Whoever controls that key controls the asset. This means institutional custody is, at its core, a key security problem. Traditional banking infrastructure relies on custody standards, segregated accounts, audit trails, regulatory oversight, and physical security. Digital assets require these standards to be adapted to an environment in which the asset itself is a cryptographic key.
A digital asset is not simply a ledger entry that banking systems can insure or reconcile. It is controlled through a private cryptographic key. Whoever controls that key can control the asset. Institutional custody, therefore, depends on securing the private key against theft, loss, and compromise. Everything else, including transaction infrastructure, reporting systems, and compliance frameworks, depends on this foundational requirement.
For banks managing significant digital asset positions, this often leads to a clear conclusion: hardware security modules (HSMs) are essential. HSMs transform key management from a software security problem (vulnerable to software exploits, insider theft, and operational errors) into a physical security problem (vulnerable only to physical theft or destruction, both of which are detectable). This transformation fundamentally changes how banks can implement custody.
At the same time, Multi-Party Computation (MPC)-based key management has emerged as an alternative, and some institutions adopt hybrid MPC-HSM architectures to balance operational flexibility with enhanced security. However, this article focuses on HSM-backed custody as the foundational security layer that many banks rely on, particularly in regulated markets where auditable hardware security is often preferred by regulators and institutional risk frameworks.
This guide explains why institutional-grade digital asset custody for banks defaults to HSM-backed infrastructure, how HSMs actually work, and why alternative approaches consistently prove inadequate at institutional scale.
How do HSMs secure private keys at the hardware level?
A hardware security module is a physical device that generates, stores, and uses cryptographic keys while keeping them protected outside the device. Inside an HSM:
Key material remains protected within the device. Keys are generated and immediately encrypted. Operations on keys happen inside the HSM. The decrypted key never appears in accessible memory. This reduces the risk of theft because the key is not exposed in an unencrypted form outside the device.
Operations are Logged and Authenticated. Every key use is logged with the initiator, time, and authorised action. This audit trail provides institutional visibility for regulatory examination and incident investigation.
Tamper protections can help detect physical compromise. FIPS 140-2 Level 3 and Level 4 (and the newer FIPS 140-3 equivalent) certified HSMs incorporate active tamper-detection mechanisms, including monitoring for physical probing, abnormal voltage, temperature fluctuations, and other environmental anomalies. If tampering is detected, the HSM can automatically zeroize (erase) sensitive cryptographic material, preventing attackers from extracting private keys.
Access can be segregated. Using a key (signing transactions) differs from managing keys. HSMs enforce this separation, so administrative access does not automatically allow transaction authorisation.
For banks, HSMs address the custody problem at the architectural level. The device helps protect keys even if surrounding systems are compromised.
Why Software-Only Approaches Fall Short?
Banks sometimes consider software-based key management to reduce costs. The approach is initially attractive because it can more easily fit into existing infrastructure. However, problems emerge quickly.
Software-based keys require the underlying computer system itself to be protected. Any compromise, breach, malware, or insider access can expose the key. The expected cost savings diminish once the bank realises it must protect those systems to a comparable standard.
Regulatory review often surfaces the deeper issue. Regulators ask: how do you prevent insider theft? Software systems respond: we have access controls and audit logs. This answer is insufficient. Regulators typically want assurance that keys are never exposed in plaintext form, where they can be stolen. HSMs are designed to provide that assurance in a way that software alone usually cannot.
Banks managing large digital asset positions often find that HSM costs are small relative to the risk of key compromise.
Building HSM Architecture for Institutional Custody
Banks deploying HSM-backed custody implement specific architectural patterns:
- Primary and backup HSMs in separate locations: A single HSM can become a single point of failure. Banks deploy redundant HSMs across geographically separated data centres, typically with operational separation at the personnel and provider level.
- Threshold cryptography for key recovery: Key material is split into multiple shares. No single share reveals the key, but enough shares can be combined to recover it. A typical configuration: split into five shares, any three reconstruct the key. This reduces insider-risk exposure while preserving recovery options. HSM-backed environments are combined with threshold-based key management using Shamir’s Secret Sharing (SSS) or Threshold Signature Schemes (TSS). This approach ensures that no single administrator can unilaterally reconstruct or use the key, thereby strengthening governance and reducing the risk of a single point of failure. Banks with limited digital asset operations may use HSM-as-a-service.
- Segregated Key Material: Banks maintain separate keys for different operations. Routine trading keys should be separate from emergency asset movement keys. This limits damage if one key category is compromised.
- Real-Time Compliance Integration: Before the HSM signs any transaction, sanctions checks, AML validation, and regulatory compliance must be cleared. The HSM can be configured to enforce policy controls at the device level.
Choosing Between HSM-as-a-Service and On-Premise Solutions
Banks face a choice between operating HSMs directly or using HSM-as-a-service. On-premises HSMs provide direct physical control but require institutional capabilities, dedicated security personnel, proper facilities, and backup systems. HSM-as-a-service simplifies operations but shifts part of the control model to third parties. Banks with limited digital asset operations may use HSM-as-a-service.
Numerous banking institutions evaluate HSM products from various providers, including Thales, Securosys, Utimaco, and Entrust, all of which manufacture HSM devices that have undergone rigorous certification processes and offer solutions that meet high security standards and regulatory requirements. The choice is often influenced by several factors, primarily certification levels, deployment options, integration capabilities, performance, and support from the institution in question.
The HSM-as-a-Service model enables institutions to leverage certified HSM infrastructure while avoiding hardware management. It simplifies operations, accelerates deployment, reduces infrastructure costs, and provides key protection solutions for clients. This is particularly valuable for those institutions that are only entering the market or conducting business on a small scale.
Regulatory requirements in various locations also shape decisions regarding infrastructure deployment. Thus, in the APAC and Middle East regions, regulators may require that certain sensitive cryptographic materials or their supporting infrastructure not leave the borders of one’s country of operation. Hence, banks consider only suppliers capable of ensuring regional deployment, taking into account their security capabilities.
Liminal addresses these requirements through its HSM Vault offering, developed in partnership with Securosys, enabling institutions to deploy certified HSM-backed custody infrastructure while supporting regional compliance, governance, and enterprise security requirements. This enables banks to benefit from managed HSM infrastructure without compromising on institutional-grade security or regulatory expectations.
Implementing HSM Key Management for Banks
Proper HSM key management requires three core controls.
- Key generation under documented standards: Keys should be generated using approved algorithms such as RSA-4096 or ECDSA P-256, with certified randomness and full documentation of the process.HSMs used for institutional digital asset custody should carry at least FIPS 140-2 Level 3 certification (or the equivalent FIPS 140-3 certification). Some regulators and institutions may require Level 4 certification, which provides additional protection against environmental attacks. When evaluating HSM vendors, banks should verify the device’s certification status and ensure it meets applicable regulatory and internal security requirements.
- Key rotation schedules: Banks should rotate keys on a defined schedule, typically quarterly or semiannually, depending on their risk profile and policy. Rotation requires generating new keys, updating dependent systems, and securely destroying old keys.
- Access control and audit: HSM operations should require authentication from multiple authorised parties. All access should be logged in the HSM or adjacent control systems, creating strong audit trails for review and examination.
HSM-Backed Custody in Practice
For banks implementing digital asset custody, Liminal Custody provides HSM-backed infrastructure designed for institutional operations across Asia-Pacific and the MENA region.
- Private keys remain protected within the HSM: With Liminal HSM Vault, they are generated and securely stored within the HSM environment, never leaving the system in plaintext. Cryptographic operations are executed within the secure hardware boundary, eliminating the risk of key exposure or unauthorised extraction.
- Data authenticity and integrity through BLS: Liminal integrates the BLS (Boneh-Lynn-Shacham) digital signature algorithm to help ensure data authenticity and integrity. BLS signatures offer cryptographic verification that data originates from an authorised source and has not been altered, adding another layer of assurance to institutional digital asset operations.
- Institutional key management and governance: Secure custody needs more than protecting private keys. Liminal combines HSM-backed key protection with access controls, approval workflows, and policy-based governance to help banks control who can initiate, approve, and execute digital asset transactions.
- Execution of transactions under policy control: Organisations have control over policies and multi-level approvals, enabling them to satisfy their governance obligations before allowing any transaction to be executed, thereby reducing their reliance on processes that require human intervention and helping to avoid illicit asset movements.
- Detection and operations management: The reports and audit trail for a transaction provide security and compliance teams with visibility into custody activities and authorisation processes, enabling them to support internal governance and comply with regulatory requirements.
Why are banks choosing HSM Infrastructure?
Banks choose HSM-backed custody because private key security cannot be fully delegated to software. HSMs provide a dedicated physical security boundary that limits key exposure to theft and compromise in ways software controls alone cannot replicate.
For banks operating in regulated markets, HSMs also provide auditable controls around key generation, storage, access, and cryptographic operations. As regulatory expectations for institutional digital asset custody mature across APAC and MENA, HSM-based key management is increasingly becoming a baseline security expectation rather than a differentiating feature.
