Why do organisations use HSMs for high-value transactions and identity verification?

Why This Matters for Security Teams

HSMs are used when the key itself is the crown jewel. If a private key can sign payments, issue certificates, approve access, or prove a regulated identity, then software-only storage creates an unacceptable theft path. Hardware-backed protection helps make key extraction far harder, and that matters for transaction integrity, non-repudiation, and audit defensibility under frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls and identity assurance regimes like eIDAS 2.0.

NHIMG research shows that secrets exposure is not a niche problem: 79% of organisations have experienced secrets leaks, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs. That is why HSMs are often chosen for high-value workflows where compromise would be expensive, regulated, or difficult to explain after the fact.

Security teams sometimes assume the main benefit is encryption at rest, but the real value is protecting the private key from export, duplication, and casual administrative misuse. In practice, many organisations only discover the weakness of software-held keys after a signing key, API key, or certificate authority credential has already been abused.

How It Works in Practice

An HSM keeps cryptographic keys inside tamper-resistant hardware and exposes only limited operations such as sign, decrypt, unwrap, or attest. The key material is generated in the module, remains non-exportable, and is usually governed by role separation, dual control, and audit logging. For high-value transactions, systems send the transaction digest or challenge to the HSM, receive a signature, and then verify that signature using a trusted public key path.

For identity verification, the same pattern supports certificates, device authentication, code signing, and strong customer or workforce identity flows. The HSM does not prove the user or workload by itself; it protects the cryptographic root that makes the proof trustworthy. That is why HSMs are often paired with lifecycle controls from the 52 NHI Breaches Analysis and with operational guidance from NIST and the CA/Browser ecosystem.

• Generate keys inside the HSM rather than importing long-lived private keys when possible.
• Use separate keys for signing, encryption, and authentication to reduce blast radius.
• Bind HSM access to tightly scoped administrative roles and explicit approval paths.
• Rotate or re-issue keys on a defined schedule, especially when the key supports regulated transactions.
• Log every key usage event and feed those logs into detection and compliance workflows.

HSMs are strongest when the surrounding identity and secrets architecture is disciplined. They do not fix exposed tokens in code, weak offboarding, or overly broad access to the application that calls the module. These controls tend to break down in highly distributed environments with many ephemeral workloads because operational teams start bypassing the HSM for speed, automation, or compatibility.

Common Variations and Edge Cases

Tighter key protection often increases operational friction, requiring organisations to balance stronger assurance against latency, cost, and deployment complexity. That tradeoff is most visible in cloud-native systems, where teams must decide between dedicated HSMs, cloud HSM services, and software-backed key stores. Current guidance suggests reserving the strongest hardware controls for the highest-value keys, not forcing every secret into the same model.

There is no universal standard for when an HSM is mandatory. For some regulated payment or certificate authority use cases, it may be expected; for lower-risk internal services, a managed secrets platform may be sufficient if keys are short-lived and tightly monitored. The practical question is whether compromise of the key would cause legal, financial, or trust failure that is hard to recover from.

NHIMG’s broader NHI research, including the Top 10 NHI Issues report and the Cisco DevHub NHI breach, shows why key protection cannot be treated as a standalone control. If the workload calling the HSM is overprivileged, poorly monitored, or exposed to third-party automation, attackers can still reach the transaction even when the key never leaves hardware.

In practice, HSMs are most effective when used as part of a broader identity control plane that also covers privilege, rotation, attestation, and offboarding.

Related resources from NHI Mgmt Group

• How should exchanges handle identity verification for high-risk crypto transactions?
• How should organisations use identity verification results in access decisions?
• How should organisations evaluate identity assurance before allowing high-risk transactions or access?
• How should organisations evaluate high-assurance identity verification when onboarding users across Europe?