Get the hottest Fintech Hong Kong News once a month in your Inbox
Conversations revolving around digital asset finance often return to the blockchain, but Shaun Chen’s concern sits closer to the point where value actually moves.
Behind every digital asset transaction sits a private key, and Shaun, AVP, APJ Advisor – Quantum and AI Security at Thales, sees that key as the authority behind the asset.
When someone compromises a private key, the institution faces more than a security breach because a validly signed transaction can move value before anyone fully understands what went wrong.
Security around those keys helps determine whether digital asset infrastructure can move from experimentation into real commercial activity.
Banks and fintechs may build new models around tokenisation or blockchain-based settlement, but those models still depend on how they generate, store and use private keys.
Shaun makes a clear distinction between ordinary credentials and private keys. A password can be reset, while a compromised private key can authorise the movement of assets, making software-based handling harder to defend as digital asset activity scales.
The risk also changes once institutions move beyond pilots. Controlled projects may run within a narrow environment, while production places more systems around the signing process and puts more pressure on internal controls to hold.
Shaun’s answer points toward hardware-based protection. As he explained,
“The private key does not need to leave the HSM to sign a transaction.”
Institutions trying to secure digital asset keys need that separation because the key can remain inside a protected hardware boundary while the transaction still gets signed.
The Limits of Keeping Private Keys in Software
Software-based key storage may feel convenient during early experimentation because it helps teams move from concept to testing without adding too much operational weight.
Shaun’s point, however, is that production changes the conversation.
Once digital asset activity moves into real commercial use, the surrounding environment becomes harder to control.
Private keys can become exposed when they are handled too closely by software systems, especially when access rights, workloads and operational processes begin to expand.
Loose administrator controls, malware and more targeted cyber attacks can then turn software-based key handling into a serious vulnerability for institutions managing digital assets.
Shaun draws a firm boundary around that risk.
Shaun Chen
“Private keys should not be exposed to software environments.”
His view reframes how institutions should think about securing digital asset keys.
Strong application security remains necessary, alongside a key protection model that prevents private keys from being extracted in usable form when the surrounding software environment comes under pressure.
A storage decision therefore becomes a control decision. If a private key can be taken out of its environment and used elsewhere, the institution has not really secured the authority behind the asset.
Hardware Changes the Security Model
Hardware security modules, or HSMs, address the software exposure problem by moving sensitive cryptographic work into dedicated hardware.
Inside HSM, institutions can generate and use cryptographic keys without handing them over to the wider software stack.
The benefit becomes especially clear in digital asset private key management, where the private key can remain inside the HSM instead of sitting close to the application environment that supports the transaction workflow.
Shaun described the distinction clearly when he said,
“The private key does not need to leave the HSM to sign a transaction.”
Digital asset systems still need to use the key because transactions must be signed before value can move. An HSM allows that to happen without giving the application direct possession of the private key.
When the application sends a signing request, the HSM performs the cryptographic operation inside its secure boundary.
After producing the signature, the HSM returns it to the transaction workflow while keeping the private key inside the device.
In practice, a compromised application environment does not necessarily expose the private key when cryptographic operations remain isolated within the HSM boundary.
Cryptographic authority stays inside dedicated hardware rather than spreading across software environments.
Transaction Signing With the Key Kept Inside
Blockchain transaction signing makes private key protection visible, and Shaun describes the HSM’s role as keeping the key inside its secure boundary while the institution signs the transaction.
A typical HSM-backed flow starts when the hardware module generates the keys.
When a transaction needs a signature, the transaction data moves to the HSM, and the institution can route the request through policy and authorisation checks before the HSM signs it.
After signing, the HSM returns the signed transaction to the application or transaction workflow, which can then submit it to the blockchain network. The private key stays inside the secure boundary throughout the process.
The flow may sound simple, but it addresses one of the biggest risks in digital asset finance.
Blockchain transactions are often operationally difficult, or impractical, to reverse once validly signed and confirmed. An attacker who obtains the private key and signs a transaction may cause damage before anyone detects it.
Shaun’s responses make clear that HSMs play a specific role in this chain. They protect the signing authority itself and keep the most sensitive part of the process away from ordinary software exposure.
Control Over Key Usage Becomes the Real Test
HSMs often get described as secure storage for keys, but Shaun’s answers point to a broader role.
“The goal is not simply to store private keys securely,” he explained.
Banks and custodians also need a clear record of how their systems use those keys.
At the point of signing, the institution needs to know who triggered the request, whether the request followed policy and whether the sequence can be proven later.
HSMs become part of cryptographic key management for digital asset infrastructure when they place those controls around signing authority.
A mature setup can enforce governed access, approval rules and key usage controls while keeping the private key away from the wider software environment.
Such controls matter because they connect digital asset security directly to operational risk and governance. A bank needs to answer questions that go beyond cyber defence.
Who initiated the transaction? Who approved it? Which key did the system use? Did the transaction follow policy? Did the system record the signing event? Can the institution prove what happened later?
Shaun framed this around the need to govern the way an institution uses a private key, rather than treating protection as the end of the story.
As these services involve more teams and counterparties, manual oversight becomes harder to rely on.
This governance becomes even more critical as institutions begin exploring AI-driven financial workflows. When an autonomous agent or algorithmic system initiates a transaction at machine speed, manual oversight is impossible. The institution must rely entirely on the HSM to enforce policy, ensuring that every machine requested action is cryptographically authorized and bounded by strict hardware controls before value moves.
Internal pilots may work with tighter human control, while regulated custody, tokenisation or settlement businesses need systems that can withstand audit, scale and scrutiny.
Audit Trails Become Part of the Trust Layer
Regulated institutions need a clear record of how they use private keys once digital asset activity moves into production.
For institutions operating across fragmented regulatory environments in APJ, this level of control is also a matter of digital sovereignty. By anchoring private keys in dedicated hardware, an institution ensures it retains absolute, sovereign control over its assets and audit trails—regardless of which cloud environments or third-party platforms the surrounding applications run on.
A signing event should show the key involved, the policy behind the approval, the authorised process that triggered it and the context around the decision.
Without that record, an institution will struggle to explain how it controlled the authority to move value.
Shaun’s answer places HSMs within the control plane behind institutional digital asset finance. HSMs provide the cryptographic root of trust and enforce secure key usage policies within a broader governance and transaction control framework.
The custody use case makes the issue easier to see. A custodian safeguards assets for clients, so digital asset custody security ultimately depends on how well the institution protects and governs private keys.
A compromised private key weakens the custodian’s control over the asset.
Tokenisation creates the same pressure around signing authority. As more financial instruments move into tokenised form, the systems behind those assets need stronger controls over actions that create, move or administer value.
Those actions can carry direct financial consequences, so institutions need to govern them with the same seriousness as other high-impact financial operations.
Hardware-rooted trust also gives institutions a model they already understand.
Banks have long relied on HSMs in sensitive financial environments, and tokenised finance extends that model into a newer setting where value can move through programmable systems.
Crypto Agility Moves Into the Planning Room
The conversation does not stop with today’s private key risks.
Digital asset systems still rely on widely adopted cryptographic methods to secure transactions and protect digital identities. While these technologies remain trusted today, financial institutions are increasingly planning for the future as post-quantum security becomes part of long-term strategy.
Quantum computing may eventually threaten some public-key cryptographic algorithms used today.
Moving every digital asset workflow to quantum-safe algorithms will take time because the wider blockchain ecosystem still has to mature around new cryptographic standards.
Shaun’s answer avoids treating post-quantum readiness as an overnight switch.
Institutions should avoid brittle key architectures that become difficult to govern or change later. Digital asset key management should be treated as a long-term trust architecture rather than a one-off implementation.
HSM-based architectures can support crypto agility by centralising key control and giving institutions a governed path to introduce new algorithms, hybrid mechanisms or updated signing approaches as standards mature.
C-level leaders should see the link between current key security decisions and future resilience.
HSMs protect private keys now, while also helping institutions prepare for cryptographic change without rebuilding their trust architecture from scratch.
Securing Digital Asset Keys Becomes a Strategic Decision
Digital asset markets are maturing, and the infrastructure behind them has to keep pace.
Blockchain protocols, custody frameworks and compliance processes will continue to matter, but weak private key protection can still undermine the whole model.
Shaun brings the discussion back to the signing authority behind digital asset finance. Institutions that want to scale these services need infrastructure that protects that authority, governs its use and leaves evidence when questions arise.
HSMs help provide that foundation by keeping private keys inside dedicated, tamper-resistant hardware.
Cryptographic operations can still take place while the keys remain out of software environments, giving institutions a stronger base for governance today and crypto agility over time.
As Shaun put it,
“In digital asset finance, the private key is not just a credential. It is the authority to move value.”
As digital asset finance becomes more institutional, protecting the private key is no longer only a security requirement. It becomes a governance, audit, and resilience requirement.
Featured image: Edited by Fintech News Hong Kong based on an image by mrsiraphol via Magnific.