Why you cannot do without an HSM
In every financial system there is a moment when an encryption key has to be generated, stored and used. The question is: where? If the key sits in a file on disk, anyone with access to the server can steal it. If it sits in memory, it is exposed to a cold boot attack. If it sits in a cloud provider's KMS (Key Management Service), you are trusting the provider not to expose it — by accident or on purpose.
An HSM solves this problem physically. It is a dedicated hardware component — a box that sits in the server room (or in the cloud) — in which encryption keys are generated, stored and used. The key never leaves the HSM. When the application needs to encrypt, sign or decrypt, it sends the data to the HSM, and the HSM performs the operation inside its protected hardware.
What happens when someone tries to open it
A physical HSM (such as Thales Luna 7) includes active anti-tampering mechanisms. If someone tries to open the box, drill into it or change the temperature abnormally, the keys are wiped automatically. This is not a theoretical scenario: in 2017, researchers from the University of Cambridge published an analysis of the protection mechanisms of leading HSMs, and showed that some protections are more effective than others.
A real case: Equifax in 2017
The Equifax breach in 2017 exposed the details of 147 million people — including credit card numbers, dates of birth and more. One of the assessments carried out after the attack was that had HSMs been used more widely, the damage would have been much smaller — because even if the attackers had got into the system, they could not steal the keys themselves.
An important point: an HSM is not a cure-all. But it adds a backstop layer of protection — and if attackers want to steal keys, they have to steal the HSM itself, which is far harder.
FIPS 140-3: what it means in practice
FIPS 140-3 is a NIST standard (it replaced FIPS 140-2) that defines security requirements for cryptographic products. There are 4 levels:
| Level | Main requirements | Typical use |
|---|---|---|
| Level 1 | Approved algorithms, no physical protection | Software, a basic cloud KMS |
| Level 2 | + tamper-evident seals, role-based auth | Mid-sized organisations |
| Level 3 | + tamper-resistant, identity-based auth, physical ports separate | Banks, exchanges, fintech |
| Level 4 | + full environmental protection (temperature, voltage) | Critical infrastructure, the military |
Most Australian financial organisations require Level 3 at minimum. That means the HSM has to resist physical attempts to expose the keys, with identity-based authentication (not just a password), and with the physical interfaces (data vs. management) separated.
PKCS#11: the language of the HSM
PKCS#11 is a standard API that most HSMs support. It defines functions such as C_Sign, C_Encrypt, C_GenerateKeyPair and C_FindObjects. The advantage: your application does not need to know which HSM is attached — it speaks PKCS#11, and every HSM understands it.
The downside: PKCS#11 is a C-based API from the 1990s. It is clunky, full of pointers and not always pleasant to work with in modern languages. Some vendors (such as Thales, with its PKCS#11 and JCE provider) supply wrappers that improve the developer experience.
// Example: signing a document with PKCS#11 (Java)
CK_MECHANISM mechanism = new CK_MECHANISM(CKM_SHA256_RSA_PKCS);
CK_SESSION_HANDLE session = openSession(slotId);
CK_OBJECT_HANDLE privateKey = findPrivateKey(session, keyLabel);
CK_BYTE[] data = document.getBytes(StandardCharsets.UTF_8);
CK_BYTE[] signature = ckm.SIGN(session, mechanism, privateKey, data);CloudHSM versus a physical HSM: what to choose
AWS CloudHSM
A dedicated HSM (FIPS 140-3 Level 3) that runs in your own VPC. You get full control — the keys are not accessible to AWS. The price: about $1,400 a month per instance (as at 2026). It suits anyone who wants an HSM in the cloud without managing physical hardware. The downside: higher latency than a local physical HSM — every call goes over the network.
It is important to distinguish AWS CloudHSM from AWS KMS. KMS is a managed service that spares you all the complexity of HSM management, but it is not FIPS 140-3 Level 3 — it is Level 2. If you are a bank or an exchange, you need Level 3 — which means CloudHSM or a physical HSM.
Azure Dedicated HSM
A physical Thales Luna 7 that Azure allocates to you. FIPS 140-3 Level 3. The price is similar to AWS. The advantage: full compatibility with Azure Key Vault and Azure VNet. The downside: provisioning takes several days — it is not something you switch on in a moment.
Google Cloud KMS with CloudHSM
Google Cloud offers both managed Cloud KMS and Cloud HSM based on Thales. It uses the same VPC isolation model as AWS, with FIPS 140-3 Level 3 compliance.
Thales Luna 7 (on-premises)
A physical HSM in your own server room. FIPS 140-3 Level 3 (Level 4 versions also exist). Price: $15,000-$40,000 per unit, depending on configuration. It suits anyone who needs low latency, full control and compliance with regulation that mandates on-premises deployment.
Entrust nShield
Thales's main competitor. nShield Connect is a physical HSM with FIPS 140-3 Level 3. The advantage: broad support for PKCS#11, JCE and .NET. The downside: less accessible documentation, and the procurement process requires direct contact with Entrust.
HashiCorp Vault with Seal Wizard
If you do not need FIPS 140-3 Level 3, HashiCorp Vault with the seal wizard can be a good compromise. It keeps the seal key outside Vault — in an HSM or in an AWS/Azure KMS — and encrypts the seal key with it. That lets you use Vault for key management without running your own HSM — but if you are under PCI DSS or similar regulation, it is not enough.
The selection and procurement process
If you are choosing an HSM, these are the steps I recommend:
- Defining requirements: FIPS level, throughput (operations per second), number of keys, redundancy (HA pair?), compliance requirements
- Assessing cloud vs. on-premises: if regulation requires on-premises, there is no choice. If not, a cloud HSM can save on operational costs
- Proof of concept: ask the vendor for a trial or a POC. Test throughput, latency and compatibility with your PKCS#11
- HA and DR: a single HSM is a single point of failure. Plan at least 2 HSMs in active-active, with key backup (wrapped) to a DR site
- Key ceremony: the ceremony in which the root key is created. It requires documentation, witnesses and a formal procedure. Do not underestimate it
When you do not need an HSM
An HSM is a heavyweight solution. Not every project needs one. You probably do not need an HSM if:
- Your application is an internal tool that does not handle sensitive financial data
- You are a small startup that is not under regulation yet — HashiCorp Vault with a seal key may be enough
- Your keys are only TLS certificates — Let's Encrypt and cert-manager will do
An HSM is required when:
- You process payments (PCI DSS requires it)
- You are an exchange such as the ASX, a bank or an insurer — APRA's CPS 234 or another regulator will expect it
- You run an enterprise PKI with a root CA
- You sign financial transactions digitally
From experience: I have seen organisations buy an HSM and then not use it because "it is too complicated". If you do not have someone on the team who understands PKCS#11 and PKI, start with Vault, and move to an HSM when you are ready. An HSM that is not used properly is an HSM you pay for without getting any value.