Hardware Security Modules (HSM)
Private keys stored securely
An HSM is a hardened cryptographic module that protects private keys and performs cryptographic operations (e.g., signatures, decryption) within a hardware boundary. In high-assurance PKI, the general rule is: CA keys and especially critical private keys are generated inside the HSM and do not leave it.
Use cases in PKI/CLM
- ✓Root/Issuing‑CA KeysProtects the trust anchor; root ideally offline, issuing online with HSM-based key custody.
- ✓Code‑SigningHSM keys and dual-control processes reduce misuse risk.
- ✓TLS for central gatewaysLB/WAF/API gateways: key custody and audit evidence are often regulatory requirements.
- ✓Document / identity signaturesTraceable key usage and reliable audit artifacts.
Selection checklist
Assurance
Certifications, physical security, role models, and audit capability.
Integration
Integration with CA software, signing services, gateways, vaults, and CI/CD pipelines.
Operations
HA/cluster, backup/restore, key rotation, emergency procedures, and monitoring.
Crypto‑Agility
Algorithm mix, migration capability, and (where relevant) a PQC roadmap.
HSM vendors (selection) & feature comparison
This comparison is intentionally vendor-agnostic and highlights typical, publicly communicable characteristics. Details depend on model and firmware and should be validated during procurement using specific certification IDs and data sheets.
| DIMENSION | THALES | ENTRUST | UTIMACO | SECUROSYS |
|---|---|---|---|---|
| Product lines (examples) | Luna (GP), payShield (Payment) | nShield (GP) | CryptoServer (GP), Atalla (Payment) | Primus (E/X/S/CyberVault) + CloudHSM |
| Deployment options | Network Appliance, PCIe, USB (Entry/Dev) | Network Appliance, PCIe, USB (Entry/Dev) | Network appliance, PCIe (depending on series) | Network Appliance, CloudHSM (Hosted) |
| Tenant capability / isolation | Partitioning / virtual HSMs via roles and policies. | Logical isolation via domain / Security World concepts and RBAC. | Slot / partition concepts depending on model/SDK; common in regulated environments. | Multi-tenant options depending on model/series; separation via domains/policies. |
| Sizing category (rough) | Medium → large (broad portfolio, model-dependent). | Small → large (broad GP coverage, strong integration). | Medium → large (assurance/performance tiers, model-dependent). | Small → large (tiers + CloudHSM option, model-dependent). |
| HA & resilience | HA pairs/groups, failover & load sharing (design-dependent). | Failover/load balancing via domain design and client configuration. | Redundancy via appliances/hosts; often N+1 in CA designs. | Cluster patterns (failover/load balancing) + CloudHSM options. |
| Key migration | Backup/restore, cloning, and wrapped export/import – policy-dependent. | Migration often easiest within a domain / Security World (backup/restore). | Backup keys / wrapped export-import depending on policy/model. | Wrapped export/import depending on policy; define an exit plan early. |
| Costs (typical, rough) | On-prem CAPEX + support; hosted/managed depending on offering. | On-prem CAPEX + support; often project/integration-driven. | Strongly dependent on model/certification (GP vs. payment/high assurance). | On-prem CAPEX; CloudHSM OPEX/subscription. |
Sizing guidelines (small / medium / large)
Your number of certificates is primarily a CLM metric (inventory, renewals, deployments). An HSM is typically sized based on cryptographic load (signatures/s, concurrency, algorithm mix) and HA/DR targets. The values below are guidance only; reliable sizing requires measurements.
| ENVIRONMENT | CERTIFICATE INVENTORY (CLM) | ISSUANCE / ROTATION (PEAK) | HSM LOAD (PEAK SIGN OPS/S) | TYPICAL TARGET ARCHITECTURE |
|---|---|---|---|---|
| Small | < 50k | < 5k certificates/day | < 200 | 1–2 HSMs (N+1), few tenants/partitions |
| Medium | 50k – 500k | 5k–50k certificates/day | 200–2,000 | 2–4 HSMs (cluster/HA), segmentation by environments/teams |
| Large | > 500k | > 50k certificates/day | > 2,000 | Multiple clusters/regions, clear tenant separation, DR design |
Required sizing inputs
Peak issuance (certs/min), algorithm mix (RSA/ECC), concurrency, RTO/RPO, tenants/partitions, and key policies (is export/cloning allowed?).
HA clusters, migration & runbooks
- ✓N+1 as a minimum standardFor critical trust domains: at least two HSMs per domain (failover/load sharing).
- ✓Cluster / fleetHA groups, load balancing, and service redundancy; in cloud scenarios often multi-AZ/region patterns.
- ✓Key backupsBackup HSM, quorum/M-of-N, operator cards, or wrapped backups. Test restores regularly.
- ✓MigrationUsually easiest within one vendor ecosystem; cross-vendor only with export under wrapping/policy.
- ✓RunbooksClearly document key ceremonies, rotation, break-glass, DR failover, as well as audit artifacts and roles.
Costs: typical drivers (CAPEX vs. OPEX)
On‑Prem (CAPEX)
Acquisition (appliance/PCIe/USB) plus annual support. Account for HA (at least N+1), backup hardware, and audit evidence.
Cloud/Hosted (OPEX)
Hourly/monthly pricing models. Cost drivers include HA units/regions, tenancy options, logging/compliance features, and transaction load (model-dependent).
Guidance
In many projects, on-prem general-purpose HSMs are in the five-digit range per device (plus support). CloudHSM/hosted models are often OPEX-driven. Actual pricing depends on performance tier, certifications, tenancy, and SLA.
What would you like to do next?
XELANED specialists are available to support your next steps at any time. Together, we prioritize topics, clarify dependencies, and choose an approach that fits your environment both technically and organizationally.
Knowledge building
In a compact workshop, we clarify goals, the current state, and the next steps.
Project planning
We discuss scope and dependencies and create a reliable implementation plan.