In digital asset custody, control of an asset is control of the private key that authorises its movement. That is why the core of any bank custody architecture is the place where those keys are generated, stored and used. In most institutions, that place is a hardware security module, or HSM.
When a bank prepares its infrastructure, the discussion often centres on whether the HSM should be a physical appliance in its data centres or an HSM deployed in its cloud. It is a relevant decision, but it should be framed correctly: when properly configured, both offer the same level of protection for the keys. What changes is the way they are operated, not the security.
What an HSM does in digital asset custody
An HSM is a device designed to generate and protect cryptographic material and to perform operations with it without that material ever leaving the module. In digital asset custody it fulfils several functions:
- Key generation: the private keys for client addresses or the institution’s own addresses are generated inside the HSM, using its own source of entropy.
- Storage: keys remain inside the module, or encrypted under keys known only to the module. They are never exported in plain text.
- Signing: when an asset needs to be moved, the transaction is sent to the HSM, which signs it internally and returns only the signature.
- Access control: the use of each key is subject to roles, credentials and, where appropriate, approval quorums.
HSMs are typically certified to standards such as FIPS 140-3 or Common Criteria. Which model and which certification level are used is the bank’s decision, in line with its security policies and its supervisor’s expectations.
Physical HSM on the bank’s premises
A physical HSM is an appliance that the bank procures, installs in its data centres and operates with its own teams. Many institutions already run these devices for payments, key management or electronic signatures.
Its main characteristics:
- Direct control: the bank manages the hardware, its location, physical access and initialisation ceremonies.
- Familiar processes: security teams usually have prior experience, established procedures and audits.
- Procurement and maintenance: it requires purchasing, installation, firmware updates, hardware replacement and capacity planning.
- Redundancy: high availability requires several modules, normally across more than one data centre, with secure key replication between them.
HSM deployed in the bank’s cloud
A cloud HSM is a module, dedicated or managed, that runs on a cloud provider’s infrastructure but within the environment contracted by the bank. In the dedicated model, the bank has hardware assigned exclusively to it; in the managed model, the provider operates the underlying infrastructure while the bank retains cryptographic control.
Its main characteristics:
- The bank still controls the keys: administration and usage credentials belong to the institution. The cloud provider operates the hardware but cannot use the keys.
- Elasticity: capacity can be expanded with shorter provisioning times.
- Geographic redundancy: it is easier to distribute modules across several regions, within the limits set by the bank’s data-residency policy.
- Fit with the existing architecture: it integrates naturally if the systems that orchestrate operations already run in the institution’s cloud.
The same level of protection, different ways of operating
The property that matters in custody is that the key never leaves the HSM and that every signature is produced inside the module, under credentials and policies controlled by the bank. That property holds for both a physical HSM and one deployed in the cloud, provided that both are properly configured: controlled initialisation, separation of roles, rigorous credential management, encrypted backups and audit logs.
The choice should therefore not rest on the idea that one model is more secure than the other. The criteria that usually decide it are different:
- Architecture: where the systems that build and submit transactions run, and how many network hops there are to the HSM.
- Operations: which teams will administer it, with which procedures and with what prior experience.
- Latency and volume: the expected number of signatures and the response times the client experience demands.
- Existing contracts: whether the institution already has physical HSMs with spare capacity or a framework agreement with a cloud provider.
- Supervisory expectations: how the supervisor has already assessed the bank’s outsourcing of cloud services.
- Data residency: the jurisdictions in which modules and their backups may be located.
It is also possible to combine both, for example with physical HSMs for the highest-value keys and cloud HSMs for operational addresses, provided the policies are consistent across them.
Signing policies, limits and audit
The type of HSM does not change the control logic that surrounds each signature. That logic is defined in layers that work the same way in both models:
- Signing policies: which keys may sign which types of operation, to which destinations and for which amounts.
- Limits: thresholds per operation, per client and per period, above which additional approval is required.
- Quorums and approvals: sensitive operations, such as movements between the institution’s own addresses or configuration changes, that require several authorised people.
- Audit logs: every signing request, approval and outcome is recorded so that it can be reviewed internally and by the supervisor.
This separation allows the bank to change or extend its HSM deployment without redefining its control model.
Why it matters that keys stay inside the bank
When keys are generated and held in the bank’s own HSMs, there is no third-party custodian in the chain of control over client assets. The institution is directly responsible for safeguarding, and can demonstrate it with its own records.
This is consistent with DORA (Regulation (EU) 2022/2554), applicable since 17 January 2025, which requires financial entities to manage the risk arising from their technology providers and to retain control over their critical functions. Reducing the number of third parties able to act on the assets simplifies that management and the dialogue with the supervisor.
Before deciding, the bank should answer a few questions:
- Does the institution already operate HSMs, and do they have capacity for this new use?
- Where will the systems that build and submit transactions run?
- What signing volume and response times are expected?
- What does the data-residency policy require for modules and backups?
- Which teams will administer the modules, and how will their duties be segregated?
- What has the supervisor communicated about the use of cloud services?
At Finhattan we deploy custody infrastructure on the HSMs the bank chooses, physical or in its cloud, with no access to the keys. More detail is available in security and control and the solution.
If your institution is considering this step, we can work through it with your team via our contact page.