Executive Summary
An HSM can keep digital asset keys inside a protected hardware boundary, but it does not provide the operating layer required to manage wallets, transaction policies, approvals, AML controls, blockchain connectivity, broadcasting, and audit records. This article compares HSM, MPC, and multisig; reviews on-premises, air-gapped, cloud, and hybrid HSM deployments; and explains how Utila connects institution-controlled HSM signing to its wallet infrastructure. Banks retain control of their key material while applying governance, compliance, and operational controls across the broader transaction lifecycle.
Bank-Specific Requirements for Operating Stablecoins and Tokenized Deposits at Scale
Stablecoins and tokenized deposits are increasingly becoming part of bank payment, treasury, and settlement strategies. In a recent EY-Parthenon study, 13% of surveyed financial institutions and corporates were already using stablecoins, while 80% of non-users were actively exploring adoption.
Bank-led digital money is gaining traction across jurisdictions, regulatory frameworks, and use cases. At Utila, we have a firsthand view of that momentum through the institutions we support:
In the United States, N3XT, a Utila client, has launched NDD, a bank-issued tokenized deposit designed for real-time dollar settlement.
Augustus, also a Utila client, has received conditional OCC approval to establish Augustus Bank, N.A. as a full-service national bank built around programmable, always-on clearing.
Their approaches differ, but their progress reflects the speed at which stablecoins and tokenized deposits are gaining significant institutional traction.
This firsthand view also helps us appreciate that, despite the momentum and market-wide interest, adoption still presents significant operational challenges. For example. banks must meet regulatory obligations covering asset safeguarding, compliance, and operational resilience. They also need to adhere to internal policies for key custody, segregation of duties, transaction approvals, auditability, and recovery. Interestingly, regulatory uncertainty remains the most commonly cited adoption barrier, identified by 73% of respondents in the cited EY-Parthenon study.
For many banks, a hardware security module offers a familiar way to address key custody. An HSM keeps cryptographic keys inside protected, institution-controlled hardware and can align with established security architecture and regulatory expectations. Its scope, however, ends at key protection and signing. It does not provide blockchain connectivity, transaction policy, AML screening, approval workflows, reconciliation, or the audit record surrounding each transaction.
This article compares HSM, MPC, and multisig as alternative key-management and authorization models. It then examines how banks can connect an existing HSM to Utila’s wallet infrastructure, retaining control of key material while adding the governance, compliance, and operational capabilities required to manage digital assets.
Why Financial Institutions Use HSMs
Banks have used HSMs for established cryptographic functions including payments, authentication, public-key infrastructure, database encryption, and the protection of sensitive financial credentials. Extending that infrastructure to digital asset keys can allow the institution to retain a familiar security boundary while introducing blockchain-based products.
The decision is commonly driven by three requirements:
Control of key location. Some institutions require wallet keys to remain within infrastructure that they operate, either because of internal security policy or because an applicable regulatory or supervisory framework requires on-premises or hardware-protected key storage. The relevant requirements must be assessed for each jurisdiction, licence, and operating entity.
Certified cryptographic controls. HSM certifications can provide evidence that a cryptographic module has been evaluated against a defined standard. FIPS 140-2 and its successor, FIPS 140-3, assess the security of cryptographic modules and their defined hardware and software boundaries. Importantly, certification applies to the module itself. It does not certify the institution’s complete custody process, transaction policy, approval workflow, or the correctness of the payload submitted for signing.
Alignment with existing security operations. An institution may already have procedures for HSM administration, operator credentials, backup, high availability, monitoring, separation of duties, and secure decommissioning. Reusing that estate can reduce the number of new cryptographic control models that security and audit teams must assess.
It’s important to note the regulatory treatment of various HSM setups varies by jurisdiction. For example, Hong Kong’s SFC requires virtual asset trading platforms to hold 98% of client virtual assets in cold storage and cites HSM-based cold storage as an accepted example. Singapore’s MAS guidance emphasizes offline key storage and local control of sufficient key shares. European and US frameworks generally focus on safeguarding, segregation, governance, and operational resilience rather than prescribing one signing technology. The common requirement is demonstrable control over key material and the process through which it can be used, not a universal HSM mandate.
Some institutions also require isolated signing environments. In an air-gapped model, the HSM and associated approval systems have no direct network connection, and signing requests must be transferred through a controlled offline process. The supplied product discussions identify air-gapped, on-premises, and cloud-connected environments as deployment patterns that an HSM integration may need to support.
These controls establish where the signing key resides and under what physical conditions it can be used. The next challenge is governing the business process that leads to a signing request.
HSM Deployment Models
The required deployment depends on the institution’s rules for key location, network connectivity, infrastructure ownership, availability, and disaster recovery. A digital asset platform should accommodate the approved HSM environment rather than force the institution to replace it.
Deployment | Operating model | Key considerations |
On-premises HSM | The institution operates a network-attached or PCIe HSM in its own data centre. | Direct control over hardware, credentials, network segmentation, backup, and access procedures. |
Air-gapped HSM | The signing environment is isolated from internal and external networks. Requests and signatures move through a controlled offline process. | Strong isolation, with additional operational requirements for request transfer, approval latency, transaction expiry, and policy updates. |
Cloud HSM | HSM capacity is provided through a managed cloud service or dedicated cloud deployment. | Responsibility must be defined for tenancy, administration, credentials, availability, backup, and evidence required by the institution’s control framework. |
Hybrid HSM | The institution combines on-premises and cloud HSM infrastructure across workloads, environments, or recovery arrangements. | Applications must consistently route signing activity while maintaining the required key-control and synchronization model. |
Leading HSM vendors support hardware appliances, cloud-hosted services, and hybrid architectures that combine institution-operated infrastructure with managed capacity. The available options vary by vendor, product family, certification level, cryptographic curve, and high-availability model. Institutions should therefore evaluate the approved deployment architecture and required chain coverage before selecting the connector and signing workflow.
Air-gapped deployments introduce additional design requirements because the HSM cannot obtain live policy information, market data, AML decisions, or transaction history. The operating platform must prepare a self-contained signing request, collect the necessary approvals, and transfer sufficient evidence for the isolated system to decide whether the signature should be released.
The institution’s approved deployment model should therefore be established before selecting the connector, policy-distribution process, and signing workflow.
HSM’s Role in Digital Asset Custody
A hardware security module, or HSM, is a dedicated cryptographic processor designed to protect the lifecycle of cryptographic keys. HSMs generate, store, and use keys inside a protected hardware boundary, allowing applications to request cryptographic operations without directly accessing the underlying private key material.
For digital asset custody, the HSM holds the wallet keys that control blockchain addresses. When an authorized application submits a signing request, the HSM performs the cryptographic operation internally and returns the resulting signature. Keys can be configured as non-extractable, meaning they are not exported from the HSM during normal use.
Enterprise HSMs are designed to protect keys against compromise while providing signing, encryption, authentication, audit, access-control, and high-availability capabilities. Some programmable HSMs also support custom validation code that executes inside the protected hardware boundary. This can allow defined authorization and policy conditions to be evaluated before a signature is released, although the available functionality and operating constraints vary by HSM model.
These characteristics make an HSM a suitable root of trust for institutions that require physical control over key material or have already standardized their cryptographic infrastructure around certified hardware.
They do not, however, cover the full scope of a complete digital asset custody model. That depends on how the HSM is connected to users, policies, applications, and blockchain networks. Chain coverage also depends on the cryptographic curves and derivation methods supported by the selected HSM. Secp256k1 is used across Bitcoin and EVM networks, while Ed25519 is used by Solana and other chains. Support for signing does not always imply support for the derivation workflows required to create wallets and addresses efficiently. These capabilities should be assessed against every network the institution plans to operate.
What an HSM Does Not Provide
An HSM is designed to protect keys and perform cryptographic operations. It does not, by itself, provide the operating controls that a bank needs to manage digital assets across teams, legal entities, customers, networks, and products.
Those missing functions typically include:
Wallet and account administration. The institution still needs a system for creating wallets and addresses, separating balances by entity or use case, maintaining an address book, and assigning user access.
Transaction governance. The HSM must be connected to rules governing source wallets, destinations, assets, transfer amounts, initiators, approvers, and administrative quorums. A basic request to sign a payload does not establish whether the underlying transaction is permitted.
Compliance workflows. AML screening, transaction monitoring, risk decisions, and third-party compliance integrations generally rely on network access, historical data, and external services that are unavailable inside an isolated HSM.
Blockchain connectivity. Transaction construction, fee management, chain-specific data, node connectivity, confirmation tracking, and broadcasting must be handled outside the HSM.
Operational records. Treasury, operations, risk, and audit teams require transaction history, approval evidence, policy records, user activity, and reconciliation data around each movement of assets.
At Utila, we have designed an HSM-backed model that gives institutions the benefits of both layers. Wallet keys remain protected within the institution’s HSM, while Utila provides the surrounding operating environment for wallets and addresses, AML workflows, transaction governance, approval processes, transaction history, audit logs, blockchain support, and broadcasting. The HSM produces the wallet signature, while the broader operating experience can remain consistent with other Utila vaults.
Solution
Utila for Banks
Digital asset & stablecoin infrastructure for financial institutions.
The distinction matters because adding more HSM capacity does not resolve workflow fragmentation. Scaling digital asset operations requires the signing infrastructure and the operating layer to function as one controlled process.
HSM vs MPC vs Multisig: Different but Complementing Security Models
HSM, multi-party computation, and multisignature architectures all reduce the risks associated with relying on a private key held in ordinary software. They distribute and enforce control in different ways, however, and should not be treated as interchangeable solutions.
Model | How transaction signing works | Where control is distributed | Primary architectural consideration |
HSM | A complete wallet key is generated or stored inside protected hardware, which produces the signature. | Access to the HSM and the processes that authorize its use. | The institution controls the hardware boundary, but requires software to govern transaction workflows. |
MPC | Multiple parties use separate key shares to jointly produce a valid signature without bringing the full private key together in one location. | Across devices, systems, or organizations holding the shares. | The key-control model can be distributed without relying on one physical signing device. |
Multisig | Several complete private keys produce separate signatures, with the blockchain requiring a defined number of them. | Across the holders of the individual signing keys. | The blockchain and wallet implementation must support the required multisignature structure. |
These models can also be applied at different layers of the same architecture. In one HSM-backed Utila design, wallet keys remain inside the institution’s HSM and sign blockchain transactions there, while an MPC vault-security key governs sensitive administrative actions such as policy ratification, key registration, and changes to approvers. This is one possible allocation of control rather than a requirement of every HSM-backed deployment.
Product
Tokenization
Securely mint, custody, and transfer tokenized assets with our tokenization platform.
The appropriate model therefore depends on the institution’s regulatory obligations, existing security architecture, deployment constraints, and preferred allocation of control.
Combining HSM Key Custody With Utila’s Operating Layer
Utila’s HSM-backed vault architecture is designed for institutions that want to keep wallet keys inside their own HSM while using Utila to govern the surrounding digital asset operation.
Under this model, the institution’s HSM generates or stores the transaction-signing keys. The keys remain non-extractable, and Utila does not receive the institution’s wallet key material. Utila manages wallet administration, transaction construction, policy evaluation, approvals, AML workflows, audit history, blockchain connectivity, and broadcasting. A Utila-provided cosigner running inside the institution's environment receives the approved signing request and communicates with the HSM.
For HSMs that support programmable enforcement logic, the architecture can also include a Utila-supplied validation module inside the protected hardware boundary. The module can evaluate defined transaction attributes, including the source, destination, transferred asset, and required approval evidence, before allowing the HSM to produce a signature.
This creates two enforcement points:
Utila applies the institution’s broader operational policy, including controls that depend on AML services, external data, market information, and transaction history.
The HSM applies a defined subset of controls that can be evaluated using the policy and approval evidence available inside its constrained environment.
The resulting architecture preserves institution-controlled hardware signing while extending the control framework across the broader transaction lifecycle.
Example HSM-Backed Deployment
A representative HSM-backed architecture places the HSM, operator credentials, and signing connector inside the institution’s environment. Utila provides the interfaces and APIs through which transactions are initiated, policies are administered, approvals are orchestrated, compliance checks are performed, and blockchain activity is constructed, broadcast, and recorded.
A transaction can follow this process:
Transaction initiation. An authorized user or internal system creates a transaction through the Utila Console or API. Utila evaluates the relevant policy and determines the required approvals and compliance checks.
Controlled approval. Designated operators approve the transaction through the institution’s approved devices and authentication process. The workflow can enforce role-based approval requirements and prevent the initiator from satisfying controls intended for an independent approver.
HSM signing request. A Utila-provided local connector, operating inside the institution’s environment, receives the approved signing request and passes it to the HSM connector. HSM credentials remain sealed locally and are not transmitted to Utila.
Validation inside the HSM. Where supported and configured, an HSM-resident validation module checks the permitted source, destination, asset, and approval evidence. If the request violates the policy loaded into the HSM, the module refuses to release a signature.
Broadcast and recording. Once the HSM returns a valid signature, Utila submits the signed transaction to the relevant blockchain and records the transaction, approvals, policy evaluation, and resulting status in the platform.
The architecture is designed so that policy and AML evaluation occur before signing, approval evidence accompanies the signing request, the HSM makes the final decision to release the wallet signature, and Utila manages broadcasting and operational records.
The same architecture can be adapted to institution-specific operating practices. An isolated approval workstation, for example, can remain part of the workflow where the approval application and policy-distribution process are configured for that environment. The HSM remains under the institution’s control, while Utila supplies the software components that connect signing to the wider digital asset operation.
Design Your Custody Solution for the Complete Transaction Flow
Selecting an HSM answers an important custody question: where will the private keys be generated, stored, and used? A bank must also determine how transactions are initiated, evaluated, approved, signed, broadcast, monitored, and reconciled.
Utila’s HSM-backed architecture connects institution-controlled signing to a policy-governed digital asset operations platform. Banks can retain their approved hardware boundary while managing wallets, users, approvals, compliance workflows, blockchain connectivity, and transaction records through one operating environment.
Speak with Utila to assess an HSM-backed deployment for your institution, including your existing HSM estate, key-location requirements, approval model, network architecture, required blockchains, and operational control framework.
General inquiries
Contact us
We'll get back soon
Reach out to our team for general inquiries related to product, sales, marketing or support.
