HSM / PKCS#11 / HSM Capacity Calculator

What you will do: Pick a Small, Medium or Large deployment, switch on enterprise use cases and set each one's transactions per second, choose N+1 or 2N redundancy and the number of locations, then read the three fleet-sizing cards.

Worked example: Keep the Medium preset (about 7,145 TPS) and compare Today, Post-PQC on the existing fleet and Post-PQC on next-gen HSM: each card reads Sufficient, Demand only or Overloaded, with the bottleneck algorithm explained.

Runtime and privacy: The cryptographic exercise runs in this browser. Review the site privacy terms before entering sensitive material; use synthetic inputs for learning and evaluation.

Browse all Crypto Lab tools · Learn with PKI

For your role

Executive / Business Leader: Choose the organisation profile closest to yours and toggle Standards today against Full end-state: the difference in HSM count is the capital question post-quantum signatures raise, before any vendor quote.
GRC / Risk & Compliance: Model transition-window hybrid signing shows the period when both classical and post-quantum signatures run at once; the How we estimated this notes under each workload are the assumptions to record with the figure.
Security Architect: Pick Demand sizing or Inventory sizing, enable the workloads you run (TLS termination, VPN IKE, SSH, DNSSEC, code signing, document signing) with their transactions per second, and choose N + 1 or 2N: the fleet sizing model gives HSMs per location under ML-DSA-65 or SLH-DSA-128s.
IT Ops / DevOps: Start from the Small, Medium or Large organisation profile, set the number of locations and the sizing headroom, and read the per-location capacity formula: the result is the HSM count to put in front of a change board, with Model limits & caveats stating what it does not cover.

Simplified educational model — not a substitute for a consultant-grade capacity analysis. This simulator assumes per-site demand with geo-redundant active-active replication (each location independently sized for the full workload), a single uniform HSM SKU per scenario, peak-window sizing, and best-case PKCS#11 throughput. It does not model latency budgets, per-tenant key isolation, geo-failover, cold-start surges, batching, partition slots, firmware-specific limits, or compliance-driven duty-cycle constraints. Use it to sanity-check ranges and explore trade-offs, not to size a production fleet.

HSM performance numbers are illustrative reference values from public vendor datasheets (Thales Luna 7, Entrust nShield 5c, Utimaco SecurityServer). No vendor currently publishes production ML-DSA hardware-accelerated TPS; that value is an extrapolation. Adjust every parameter to match your measured environment, and engage a vendor or HSM architect for a real deployment.

The calculator answers one specific question: how many HSMs does steady-state throughput require? A real production sizing exercise needs several factors this model deliberately does not capture. Treat the output as a first-order estimate — a starting point for vendor conversations and capacity-planning spreadsheets, not a final BOM.

Distribution & redundancy assumptions

Full workload at every location, not split. This is geo-redundant active-active: each site independently runs the entire per-site workload you configure, not an even division of it across locations. No regional weighting, time-zone shift modelling, or follow-the-sun load curves. If your traffic is unevenly distributed, model your busiest region’s actual volume as the per-site workload rather than an averaged figure.
Redundancy is site-local. N+1 means each site survives one HSM loss; 2N means each site is fully duplicated. Cross-location failover is not modelled — a whole-site outage would require additional capacity at peer sites that this calculator does not size for.
Headroom is a manual slider, not a study. The "Sizing headroom" control (default 100% = size to exact demand) inflates the raw HSM count so true utilization stays at or below the target you pick — but it applies one flat percentage across every algorithm and scenario. Production ops typically target ~70%; a real peak-vs-average study may want different headroom per workload.

Workload modelling

Throughput-based, not latency-based. The model assumes a workload is feasible as long as ops/sec ≤ capacity. It does not model queueing, p99 latency, or HSM session-pool saturation. A 99%-utilized HSM meets throughput but typically misses tail-latency SLOs.
Shared fleet. Any HSM in the fleet is assumed to run any algorithm. Deployments that partition HSMs by use case (e.g. dedicated payment / PKI / KMS HSMs) need separate calculations per partition.
Limited PQC parameter sets. The model uses ML-DSA-65 and ML-KEM-768, plus SLH-DSA-128s selectable for code signing (CNSA 2.0 / SP 800-208 favor hash-based signatures there). ML-DSA-44 (faster), ML-DSA-87 (slower), other SLH-DSA variants, and stateful LMS/XMSS — whose key-state management is itself an HSM constraint — are not modelled.
Two migration horizons, one at a time. "Standards today" applies only algorithm swaps that are standardized/deployed per the PQC Protocol Matrix (hybrid ML-KEM key exchange; PQC signatures only where the RFC is published). "Full end-state" assumes every protocol finishes standardizing — DNSSEC and SSH signature migration are hypothetical there. Real fleets will pass through intermediate mixes the selector cannot express.
No batching / amortization. Op counts assume one HSM call per transaction. Real workloads with batched AES bulk encryption or pipelined PKCS#11 calls scale differently.

HSM throughput data caveats

PQC numbers are extrapolated. No vendor currently publishes production ML-DSA hardware-accelerated TPS. The "next-gen PQC HSM" defaults are derived from FPGA / ASIC prototype benchmarks (NIST PQC reports, Marvell LiquidSecurity 2, Samsung S3SSE2A). Real shipping silicon may land within 1.5–3× of these estimates in either direction.
Classical numbers are vendor datasheet peaks. Sustained TPS in production is typically 60–80% of datasheet peak after PKCS#11 round-trip overhead, session management, and audit logging. Override the sliders with your benchmarked numbers when available.
No network / interconnect overhead. A network HSM adds 1–2 ms of PKCS#11 round-trip latency per call. For ML-DSA at 150 ops/s the network is not the bottleneck; for AES at 25 000 ops/s it can be.

Migration dynamics not modelled

One-time re-keying spike. Migrating certificates, TDE master keys, code-signing roots, and PIN zones to PQC produces a bulk re-signing / re-encrypting event that can run 10× steady-state for hours-to-days. Plan for that separately as a project event, not as steady-state capacity.
Hybrid signature transitions. Only TLS is modelled as a hybrid KEM (ML-KEM-768 + ECDH P-256). The "Transition window: hybrid signatures" toggle above models dual-signing (RSA/ECDSA + ML-DSA on every artifact) for every other use case — but it applies uniformly; real rollouts usually dual-sign some use cases and cut over others.
Audit, backup, and key-import load. HSM firmware updates, partition backups, and bulk key import during provisioning generate short-lived peaks not represented in the steady-state TPS view.

UI behaviour — non-obvious slider interactions

Deployed HSM-per-location sliders do not affect required HSMs. The today / tomorrow / upgraded sliders set what you have deployed. They drive utilization % and the sufficient/overloaded flag, but they do not change requiredRaw or requiredWithRedundancy — those depend only on load and HSM capacity. Dragging the deployed slider cannot "fix" an undersized fleet.
Changing an organisation-profile slider re-seeds every use-case TPS. Org sliders (employees, developers, servers, databases, microservices, payment TPS) feed every use case's TPS via the per-case formula. So nudging "employees" after manually setting a TLS TPS will overwrite that manual value. Per-use-case enabled checkboxes are preserved across the re-seed.
Per-scenario deployed sliders auto-track the computed requirement until you drag one. On first render, today / tomorrow / upgraded snap to perLocationRequired. Once you drag a slider, it stops auto-tracking for that scenario. Clicking a deployment-size preset (small / medium / large) resets all three back to auto-track.
Inventory mode locks the deployed sliders. In Inventory sizing, today and post-PQC classical deployed counts are computed as ⌈ inventory ÷ locations ⌉ and not user-editable; the next-gen scenario's deployed count is sized to the load.
"Deployment size" (small / medium / large) is a preset, not a model parameter. It is a one-shot button that re-seeds organisation params, inventory defaults, and location count. After clicking it, every value can still be tuned individually — the size label does not constrain the calculation downstream.

When in doubt, override the per-algorithm capacity sliders, the per-use-case TPS sliders, and the redundancy mode to match your measured environment — every default in this calculator is exposed as a tunable parameter for exactly this reason.

Deployment profile

Planning mode:

Enter workload → compute required HSMs

Migration horizon:

Every use case fully migrated to PQC — the hypothetical final state

Transition window: hybrid signatures

When on, the post-PQC workload keeps the classical signature (RSA/ECDSA) alongside ML-DSA on every artifact — modelling operators who dual-sign during migration instead of cutting over. Doubles signing load on the "Post-PQC" scenarios.

Our estimate — the aggregate TPS behind each deployment-size preset and use-case profile. Each is worked from stated inputs (users × requests × the resumption ratio, developers × commits × artifacts, connections ÷ key TTL) for a typical small, medium and large estate. These figures are this site’s own modelling, not a value quoted from a standard or report.

Redundancy:

Checked TPS total: 7,145

Sizing headroom (target utilization)

100% (no headroom)

Distributed topology

Each location runs the full per-site workload independently — multi-location deployments add geo-redundancy (one site can fail without affecting others). Each site also has its own local HA (N+1 or 2N) on top of raw demand.

Number of locations

1 location

These sliders describe what one location experiences. Adjusting any of them re-derives the per-site TPS for every use case using the formulas in each use case's "How we estimated this" panel. Multi-location deployments replicate this load at every site for geo-redundancy.

Employees

10,000

Developers

1,000

Servers / infra nodes

2,000

Databases

Microservices

200

Payment peak TPS

500 TPS

Enterprise use cases

Check a use case to add its load to the fleet requirement.

Network & Infrastructure

TLS / HTTPS termination

Web tier and API gateway TLS handshakes. 1 server signature + 1 hybrid KEM (ML-KEM-768 + ECDH P-256) per handshake. Assumes full-handshake offload to the HSM (both the certificate signature and the ephemeral KEM); keyless-TLS designs that only offload the signature would charge substantially less HSM load.

Post-PQC ops (end-state): ML-DSA-65 + ML-KEM-768 + ECDH P-256

KEM: RFC · productionSig: RFC Ed Queue

Transactions / sec5,000

VPN / IPsec IKE

Site-to-site and remote-access IKEv2 tunnel negotiation. 1 hybrid KEM (ML-KEM-768 + ECDH, RFC 9370 multi-KE) + 2 AUTH (mutual) per setup.

Post-PQC ops (end-state): ML-KEM-768 + ECDH P-256 + ML-DSA-65

KEM: RFC Ed Queue · productionSig: RFC Ed Queue

Transactions / sec100

SSH user / host authentication

Privileged access and machine-to-machine SSH. 1 signature + 1 hybrid KEM (ML-KEM-768 + classical ECDH, as in mlkem768x25519) per session. Assumes a centralized SSH CA / bastion architecture where host keys and session KEM are HSM-resident, not per-server local keys.

Post-PQC ops (end-state): ML-DSA-65 + ML-KEM-768 + ECDH P-256

KEM: RFCSig: I-D

Transactions / sec200

DNSSEC zone signing

Authoritative DNSSEC zone and RRset signing. 1 signature per record on zone re-sign.

Post-PQC ops (end-state): ML-DSA-65

Sig: I-D · pilot

Transactions / sec100

PKI & Signing

Code signing (CI/CD, containers)

Release artifact, container image, and SBOM signatures. 1 signature per build.

Post-PQC ops (end-state): ML-DSA-65

Sig: RFC

PQC signature:

Transactions / sec20

Document / PDF signing (eIDAS)

Advanced / qualified electronic signatures on documents. 1 signature per document.

Post-PQC ops (end-state): ML-DSA-65

Sig: RFC

Transactions / sec5

PKI CA issuance / OCSP

Certificate issuance and OCSP response signing. 1 signature per cert or OCSP reply.

Post-PQC ops (end-state): ML-DSA-65

Sig: RFC

Transactions / sec20

Data Security & Cloud

Database TDE (Oracle / SQL Server)

Transparent data encryption. AES-256 DEK unwrap per key rotation + RSA master key wrap.

Post-PQC ops (end-state): AES-256 + ML-KEM-768

KEM: RFC · production

Transactions / sec200

KMS envelope encryption

Cloud KMS pattern — AES-256 key wrap for data keys, ECDH for recipient delivery.

Post-PQC ops (end-state): AES-256 + ML-KEM-768

KEM: DRAFT · pilot

Transactions / sec1,000

Payments

Payment / PIN translation (PCI, EMV)

PIN block encrypt and MAC for cardholder transactions. Mostly symmetric, occasional RSA. Modelled here on a shared general-purpose fleet; in practice PIN translation runs on a dedicated payment-HSM segment (payShield-class), sized separately.

Post-PQC ops (end-state): AES-256 + ML-KEM-768

No published standard

Transactions / sec500

Fleet sizing & sufficiency

Today

Classical HSM

Sufficient

Demand

✓ met · 2.00×

2 / 1 HSMs (per loc)

Availability (HA)

✓ met · 1.00×

2 / 2 HSMs (per loc)

Capacity / requirement1.00× (100%)

Marker at 1.0× = HA target. Below 1.0× = HA gap (demand may still be met).

Per location

2 HSMs

1 raw demand + 1 HA

Deployed / loc

2 HSMs

Fleet 47% util

Total fleet

2 HSMs

1 × 2

HSMs / location (slider)

RSA-20480%

ECDSA P-25614%

ECDH P-25628%

AES-1282%

AES-2563%

Bottleneck: ECDH P-256

Post-PQC (existing fleet)

Classical HSM

Sufficient

Demand

✓ met · 1.02×

50 / 49 HSMs (per loc)

Availability (HA)

✓ met · 1.00×

50 / 50 HSMs (per loc)

Capacity / requirement1.00× (100%)

Marker at 1.0× = HA target. Below 1.0× = HA gap (demand may still be met).

Per location

50 HSMs

49 raw demand + 1 HA

Deployed / loc

50 HSMs

Fleet 97% util

Total fleet

50 HSMs

1 × 50

HSMs / location (slider)

ECDH P-2561%

ML-DSA-6574%

ML-KEM-76822%

AES-2560%

Requires vendor firmware update (PKCS#11 v3.2) for ML-KEM. Some classical HSMs cannot run ML-KEM without hardware replacement.

Bottleneck: ML-DSA-65

Post-PQC (next-gen HSM)

Next-gen PQC HSM

Sufficient

Demand

✓ met · 1.50×

3 / 2 HSMs (per loc)

Availability (HA)

✓ met · 1.00×

3 / 3 HSMs (per loc)

Capacity / requirement1.00× (100%)

Marker at 1.0× = HA target. Below 1.0× = HA gap (demand may still be met).

Per location

3 HSMs

2 raw demand + 1 HA

Deployed / loc

3 HSMs

Fleet 41% util

Total fleet

3 HSMs

1 × 3

HSMs / location (slider)

ECDH P-2562%

ML-DSA-6523%

ML-KEM-76815%

AES-2560%

Bottleneck: ML-DSA-65

PQC readiness verdict

Your current fleet of 2 HSMs across 1 location is sufficient for today's classical workload. Migrating to PQC on that same hardware would need 50 HSMs total — 25× more than today. Upgrading to next-gen PQC hardware brings that back down to 3 HSMs (17× fewer than staying on classical hardware).

How TPS becomes HSM count

Aggregate (per site) — sum every enabled use case's TPS × ops-per-transaction, by algorithm. TPS values describe what one site experiences; result is ops/sec per algorithm at a single location.
Bottleneck — divide each algorithm's load by its HSM capacity; round up. The slowest algorithm sets the floor. In the worst current scenario (Post-PQC (existing fleet)), the bottleneck is ML-DSA-65 at 5,545 ops/s ÷ 150 ops/s = R = 49 HSMs to serve one location's demand.
Replicate per location — each of L = 1 location independently runs the full per-site workload (geo-redundant active-active). No load splitting: every site carries R = 49 HSMs of demand. Multi-location adds geo-HA (any single site can fail entirely).
Add local availability headroom — on top of the raw demand count, each location gets its own N+1 or 2N spare. The raw count alone meets TPS demand; local redundancy keeps that site serving traffic when an HSM there fails.

N + 1 — tolerate 1 failure

Per-location HSMs = raw + 1 = 49 + 1 = 50 HSMs. The +1 is an idle spare; demand is met by the 49 active HSMs. Lose one and the remaining 49 still cover 49 HSMs' worth of demand.

Total fleet = 1 × 50 = 50 HSMs

2N — fully redundant active-active

Per-location HSMs = raw × 2 = 49 × 2 = 98 HSMs. Two parallel sets of 49 HSMs both serve traffic; lose an entire set and the other still carries 100% of demand.

Total fleet = 1 × 98 = 98 HSMs

Key invariant — TPS demand is met by the raw count alone (49 HSMs/location). Redundancy (N+1) adds 1 spare per location to maintain availability under failure. Sufficiency status in each scenario card below reports both: Demand met (deployed ≥ raw) AND HA met (deployed ≥ raw + redundancy).

Per-location distribution

Each of 1 location independently serves the full per-site workload (geo-redundant active-active). Region labels are cosmetic.

Loc 1

Today

Deployed:2 HSMsDemand needs:1 HSM · 2.00×HA target:2 (N+1: +1 spare)Capacity:20,000RSA-2048 ops/sSpare HSMs:1

Post-PQC (existing fleet)

+42

Deployed:50 HSMsDemand needs:49 HSMs · 1.02×HA target:50 (N+1: +1 spare)Capacity:500,000RSA-2048 ops/sSpare HSMs:1

Post-PQC (next-gen HSM)

Deployed:3 HSMsDemand needs:2 HSMs · 1.50×HA target:3 (N+1: +1 spare)Capacity:300,000RSA-2048 ops/sSpare HSMs:1

HSMs required vs deployed

Deployed
Required (HA target)
Required (demand)

Workload per algorithm (ops / sec)

Classical
PQC

TPS per HSM is expressed in the industry-standard RSA-2048 ops/sec base unit. Every other algorithm shows its cost ratio against that anchor (the number of RSA-2048-equivalent ops one operation of that algorithm consumes). Tune each slider to match your vendor's benchmarked TPS.

Classical HSM

General-purpose network HSM without PQC hardware acceleration. ML-DSA and ML-KEM run in firmware (software fallback). ML-KEM requires a vendor firmware update with PKCS#11 v3.2 support; some models may not support it without hardware replacement.

Per-HSM throughput (base unit)

10,000 RSA-2048 ops/s

All other algorithm rates shown below as cost ratio × this baseline.

Reference class: Thales Luna 7 PCIe / Entrust nShield 5c / Utimaco SecurityServer Se Gen2 public datasheets. RSA-2048 ~10k ops/s, ECDSA P-256 ~20k ops/s (vendor datasheets). ML-DSA software fallback ~150 ops/s (NIST PQC evaluation reports). ML-KEM-768 software estimate ~500 ops/s (lattice KEM operations; no vendor publishes this figure). SLH-DSA-128s firmware fallback ~2 sign/s (hash-based signing is orders of magnitude slower than lattice; extrapolated from SUPERCOP/liboqs-class benchmarks).

RSA-2048 — ops/sec · 1× (base unit)10,000

ECDSA P-256 — ops/sec · 2.0× faster than RSA-204820,000

ECDH P-256 — ops/sec · 1.0× RSA-2048 cost10,000

ML-DSA-65 — ops/sec · 67× RSA-2048 cost150

ML-KEM-768 — ops/sec · 20× RSA-2048 cost500

SLH-DSA-128s — ops/sec · 5000× RSA-2048 cost2

AES-128 — ops/sec · 2.5× faster than RSA-204825,000

AES-256 — ops/sec · 2.0× faster than RSA-204820,000

Next-gen PQC HSM

Next-generation HSM with dedicated ML-DSA / ML-KEM hardware accelerator. Newer silicon delivers higher classical TPS than legacy HSMs; PQC ops ~16–24× faster than classical software fallback.

Per-HSM throughput (base unit)

100,000 RSA-2048 ops/s

All other algorithm rates shown below as cost ratio × this baseline.

Illustrative estimate — no vendor publishes production ML-DSA or ML-KEM HW-accel TPS as of 2026-04. ML-DSA-65 extrapolated from NIST PQC FPGA/ASIC prototype benchmarks. ML-KEM-768 extrapolated from Samsung S3SSE2A eSE (18× hardware speedup vs software, CES 2026 Innovation Award) and Marvell LS2 HSM (FIPS 140-3 Level 3 module, certificate #4703; PQC coverage via separate CAVP algorithm certifications — the module certificate itself lists no PQC algorithms). SLH-DSA-128s ~40 sign/s assumes dedicated hashing acceleration — still ~200× slower than accelerated ML-DSA.

RSA-2048 — ops/sec · 1× (base unit)100,000

ECDSA P-256 — ops/sec · 1.0× RSA-2048 cost100,000

ECDH P-256 — ops/sec · 1.0× RSA-2048 cost100,000

ML-DSA-65 — ops/sec · 13× RSA-2048 cost8,000

ML-KEM-768 — ops/sec · 8.3× RSA-2048 cost12,000

SLH-DSA-128s — ops/sec · 2500× RSA-2048 cost40

AES-128 — ops/sec · 2.5× faster than RSA-2048250,000

AES-256 — ops/sec · 2.0× faster than RSA-2048200,000

Also sizing certificate storage and TLS bandwidth for the migration?

Cert Capacity Calculator HSM & PQC Operations module

Try it

Switch a scenario from Standards today to Full end-state with ML-DSA-65. What moves the HSM count?

Next step

Turn it into a plan: Infrastructure Modernization Planner

This tool practises the PKI module, phase 6 (Infrastructure & Performance); Infrastructure Modernization Planner produces a deliverable of that phase.

Next in HSM / PKCS#11

Hybrid KEM + ECDH Envelope Encryption

HSM / PKCS#11 / HSM Capacity Calculator

Related content