HSM-as-a-Service vs On-Prem HSM: A 2026 Decision Matrix

What Hasn't Changed About HSMs Since 2019

The fundamentals of a hardware security module have not moved in seven years. A device that generates, stores, and operates on private keys inside tamper-evident, tamper-responsive silicon is still the only credible root of trust under PCI DSS 4.0 requirement 3.6, eIDAS 2.0 qualified trust service obligations, FIPS 186-5 signature provisioning, and Common Criteria EAL4+ protection profiles for cryptographic modules.

The HSM is the anchor where the math of public and private keys meets the physics of a sealed boundary, and that anchor is still load-bearing for every PKI deployment a CISO will sign off on in 2026.

What did move is the certification baseline. The FIPS 140-2 validation program closed to new submissions on 1 April 2022 and stopped accepting updates on 21 September 2026, with all 140-2 certificates moving to the historical list by 2027. Every greenfield procurement in 2026 must specify FIPS 140-3 Level 3 at a minimum, aligned with ISO/IEC 19790:2012 and ISO/IEC 24759:2017.

Level 3 mandates identity-based authentication, physical tamper response that actively zeroizes plaintext key material, and an environmental failure protection envelope. Level 4 adds detection of voltage and temperature attacks across the full operating envelope, which matters for embassies, defense programs, and tier-1 payment switches but is overkill for a SaaS signing service. CC EAL4+ with the EN 419 221-5 protection profile remains the European reference for qualified electronic signatures under eIDAS 2.0 Article 29a.

The interfaces have not moved either. PKCS#11 v3.0 remains the lingua franca for native applications, with KMIP 2.1 covering remote key management between HSM and orchestration plane. JCE/JCA, Microsoft CNG, OpenSSL engines and providers, and PKCS#11 URIs still cover 95 percent of integration paths.

If a vendor proposes a proprietary REST-only interface with no PKCS#11 fallback, that is a 10-year lock-in trap, not a modernization story. The point of the 2026 procurement is no longer which interface to standardize on — it is who operates the box behind that interface, and where the box physically lives.

The HSMaaS Category in 2026

HSM-as-a-Service, or HSMaaS, is no longer a single product category. It is at least four distinct delivery models, and conflating them is the most common mistake on a CISO's first procurement matrix.

The first is dedicated single-tenant cloud HSM. AWS CloudHSM (cluster-based, FIPS 140-3 Level 3, Marvell LiquidSecurity 2 hardware, $1.45 per HSM-hour in eu-west-1), Azure Dedicated HSM (Thales Luna Network HSM 7, FIPS 140-2 Level 3 at roughly $4.85 per hour with 140-3 Level 3 migration tracked through 2026), and Google Cloud HSM (Marvell-based, FIPS 140-3 Level 3, billed per key-version and per operation) all give the customer exclusive access to a physical partition. The provider racks the appliance, runs power and networking, and the customer holds the partition crypto-officer credentials.

AWS and Google explicitly cannot recover keys; Azure operates the same way for Dedicated HSM SKUs.

The second model is multi-tenant managed key services. AWS KMS, Azure Key Vault Premium, and Google Cloud KMS expose key operations over an API while keys remain inside provider-operated FIPS 140-2 Level 3 (transitioning to 140-3) HSM clusters shared across customers. This is the cheapest tier — fractions of a cent per operation — and the right answer for application-layer envelope encryption. It is the wrong answer for a regulated certificate authority root.

The third model is sovereign-cloud HSM. Thales Luna Cloud HSM, Atos Trustway DataProtect on Bull Sequana, Utimaco u.trust 360 hosted by sovereign operators, and Yubico YubiHSM 2 in a managed colocation contract address jurisdictions where data residency is hard law: SecNumCloud in France, BSI C5 in Germany, NIS2 Annex I sectors, DORA Article 28 third-party ICT rules. The provider is contractually local, the substrate is auditable, and the legal regime does not include the US CLOUD Act.

Pricing sits between dedicated cloud HSM and on-prem capex.

The fourth model is hybrid custody: root keys stay on-prem in a customer-operated HSM, issuing or subordinate keys are projected into a cloud HSM for elastic signing, and a key-wrapping protocol (typically PKCS#11 C_WrapKey with AES-256 KEK or an RFC 5649 padded wrap) moves material under cryptographic control. This is where most regulated CAs land in 2026 — the offline root never moves, the online issuing CA scales horizontally on cloud HSM, and the audit trail is unified.

Decision Dimensions

A 2026 HSM procurement reduces to six dimensions. Treating any of them as a checkbox guarantees a bad decision, because every dimension is a continuous trade against the other five.

Latency is the first filter. An on-prem nShield Connect XC or Luna Network HSM 7 on a 10 GbE fabric returns an ECDSA P-256 signature in 0.8 to 1.4 ms with the application a hop away. The same operation against AWS CloudHSM from an EC2 instance in the same VPC and availability zone runs 2 to 4 ms; across regions, 40 to 90 ms. Azure Key Vault Premium with HSM-protected keys typically returns in 8 to 25 ms because the call traverses a regional control plane.

For a TLS terminator fronting 200,000 handshakes per second, the difference between 1 ms and 8 ms is the difference between two appliances and twenty. For a code-signing pipeline that signs one binary per minute, latency is irrelevant. Measure your actual operation profile before the architecture diagram.

FIPS level and certification depth is the second filter. FIPS 140-2 Level 3 was acceptable through 2025 and remains valid until the certificate moves to the historical list, but new builds must specify 140-3 Level 3. Level 4 is required for some defense workloads under CNSSP-15 and for a small number of central-bank settlement systems. CC EAL4+ with EN 419 221-5 is mandatory for qualified trust service providers under eIDAS 2.0. PCI PIN HSMs add PCI PTS HSM v4 on top of FIPS.

If you operate a certificate authority intended for browser trust under the CA/Browser Forum Baseline Requirements, the root key generation ceremony has to occur in a 140-3 Level 3 device with a documented, witnessed key generation transcript.

Key custody is the third and most political dimension. On-prem, the customer's crypto officers hold the only quorum that can export, clone, or destroy a key — typically a 3-of-5 m-of-n smartcard set with a documented escrow procedure. Dedicated cloud HSM gives the customer the same quorum but the appliance lives in someone else's data center. Multi-tenant KMS gives the provider operational custody with cryptographic separation; the provider cannot read the key, but the provider can refuse to let you use it if a sanction, subpoena, or billing dispute occurs.

For sovereignty-sensitive workloads, custody is the question. BYOK and HYOK patterns exist precisely because legal teams cannot get comfortable with provider-side custody.

Operational cost is the fourth. A Thales Luna Network HSM 7 lists at roughly $35,000 to $55,000 per appliance, with a typical two-node HA pair and a third unit for offline root coming to $130,000 to $180,000 in hardware. Annual support runs 18 to 22 percent. Add rack, power, cooling, two crypto-officer FTEs, audit costs, and a 5-year amortization, and the total cost of ownership lands between $90,000 and $140,000 per year for a small CA.

AWS CloudHSM at $1.45/hour for two nodes is roughly $25,400/year before data transfer and operator time. The cloud number looks better until you account for cross-region replication, premium support tiers, and the fact that the customer still needs a crypto officer who understands the box.

Past 20 million operations per month, dedicated cloud HSM and on-prem converge; past 100 million, on-prem is cheaper if the team already exists.

Compliance and data residency is the fifth. NIS2 Annex I essential entities must demonstrate operator control over cryptographic material. DORA Article 28 makes the cloud HSM provider a critical ICT third party with concentration risk reporting. eIDAS 2.0 qualified signature creation devices must be certified to EN 419 221-5. The EU Cyber Resilience Act demands a cryptographic asset inventory feeding the PSIRT process.

SecNumCloud, BSI C5, ENS High, and the German IT-Grundschutz catalogs each define geographic and operator-nationality constraints that quietly disqualify most hyperscaler HSM offerings outside their sovereign-cloud SKUs. See the PKI regulatory compliance guide for the full obligation map.

Disaster recovery and high availability is the sixth. On-prem HA is a solved problem with vendor clustering — Luna HA groups, nShield Security World, Utimaco cluster mode — typically two production units plus one DR unit in a separate fire zone, with a documented quarterly failover test.

Cloud HSM HA is the CSP's problem until it is not: AWS CloudHSM cluster mode replicates across AZs but not across regions without customer-orchestrated key replication. Cross-region DR for CloudHSM requires an additional cluster, a key-export workflow under a wrapping KEK, and an out-of-band restoration runbook. Sovereign cloud HSM providers typically offer in-country dual-site replication with a contractually committed RPO of 0 and RTO of 15 minutes.

Scenario Walkthroughs

Abstract decision matrices fall apart at the first procurement meeting. Four concrete scenarios cover most of the 2026 decision space.

Scenario A — Tier-1 bank issuing 50 million payment certificates per year. The bank operates an EMV-CA and a 3-D Secure issuing infrastructure with a steady 1,600 issuance operations per second peaking at 4,500 during card-reissue events. PCI PTS HSM v4 is mandatory, FIPS 140-3 Level 3 is mandatory, and the cryptographic boundary must support both RSA-2048 (legacy EMV) and ML-DSA-65 (planned for 2028 EMV refresh).

On-prem wins. A four-node Thales payShield 10K cluster across two data centers, with a documented offline root in a Class III vault, costs roughly $1.4 million up front and $280,000/year operationally, but it removes CSP concentration risk under DORA Article 28 and keeps the PIN translation flow inside the bank's regulated perimeter. The economics of dedicated cloud HSM only work at this scale if the bank already runs core payments in the cloud, which most tier-1 incumbents do not.

Scenario B — IoT manufacturer signing 200 million device certificates over 10 years. A vehicle manufacturer or industrial OEM provisions IoT device certificates at factory burn-in. Throughput is bursty: 80,000 certs/hour during a production run, near-zero between runs. ECDSA P-256 keys, 20-year cert validity, no PIN handling, no regulatory mandate beyond the EU Cyber Resilience Act CRA Article 13.

Cloud HSM wins decisively. AWS CloudHSM or Azure Dedicated HSM scales to the burst, costs nothing during idle periods, and the BYOK pattern lets the customer keep the issuing CA root on-prem while delegating subordinate issuance to elastic cloud capacity. Total 10-year TCO is roughly $450,000 versus $2.1 million for an equivalent on-prem deployment with seven appliances dimensioned for peak.

Scenario C — SaaS company hosting customer keys. A multi-tenant SaaS providing document signing or envelope encryption must isolate keys per customer and prove that isolation to enterprise procurement. Multi-tenant managed KMS with per-customer CMKs covers the baseline at fractions of a cent per operation. Enterprise customers who insist on operator-controlled keys get an HYOK option — the SaaS calls back to the customer's on-prem or sovereign HSM for high-sensitivity operations, accepting the latency penalty in exchange for legal isolation.

The architecture splits: 95 percent of traffic on multi-tenant KMS, 5 percent on customer-controlled HSM, single billing model, single audit trail. Mixing models is operationally hard but commercially necessary because the top 50 enterprise prospects will demand HYOK in their security questionnaire.

Scenario D — Sovereign government processing classified data. A defense ministry or intelligence agency operating code signing certificates for classified software supply chains, qualified electronic signatures under eIDAS 2.0, and weapon-system telemetry encryption needs FIPS 140-3 Level 4 or CC EAL5+, jurisdictional sovereignty under SecNumCloud or BSI C5, and a complete absence of foreign legal exposure.

On-prem with Atos Trustway, Utimaco u.trust 360, or a sovereign-operated Thales Luna 7 in a tempest-rated facility is the only credible answer. Sovereign cloud HSM via a local operator is acceptable for some unclassified-but-restricted workloads. Hyperscaler dedicated HSM is disqualified by jurisdiction, even when the technical specifications would otherwise be sufficient.

Hybrid HSM Architectures

The interesting architectures in 2026 are hybrid. Pure on-prem is shrinking to the offline root and the most regulated payment workloads; pure cloud is shrinking to commodity envelope encryption. The middle is where most regulated estates are landing, and the middle has four named patterns.

Split-root is the oldest and the simplest. The root CA key lives in an offline, air-gapped on-prem HSM, powered up only for ceremony signings. Subordinate issuing CAs run in cloud HSM under their own keys, signed by the offline root. The audit story is clean: the root never touches a network, the subordinates scale elastically, and a compromise of the cloud HSM partition forces revocation of one subordinate, not the root.

This is the default pattern for new browser-trusted CAs and for internal enterprise CAs operating under PCI DSS 4.0.

Bring Your Own Key (BYOK) generates the key inside a customer-controlled HSM and imports it into the cloud HSM under a wrapping key. PKCS#11 C_WrapKey with an AES-256 key encryption key, or RFC 3394/5649 AES Key Wrap, are the standard primitives. AWS CloudHSM, Azure Key Vault Premium, and Google Cloud HSM all publish BYOK procedures using their own KEK. The customer retains the master copy on-prem, can re-key the cloud copy on rotation, and can prove to an auditor that the key originated under customer control.

The trade-off is that once the key is inside the cloud HSM, the provider operates it — BYOK does not give the customer operational control, only origination control.

Hold Your Own Key (HYOK) goes further. The key never leaves the customer HSM. The cloud service calls back to the customer's HSM via mTLS-protected PKCS#11-over-network or a vendor proxy (Thales Luna Cloud HSM Service, Atos Trustway Cloud Connector) for every cryptographic operation. Latency is worse (10 to 40 ms per operation typical), but the customer retains operational custody. HYOK is the right answer for healthcare data under HIPAA, classified data under national programs, and DORA Article 28 critical workloads where the legal team will not accept provider operational custody.

Key-wrapping pipelines are the most flexible pattern. A short-lived signing key is generated in a cloud HSM for a specific batch (a release signing, a software update, a settlement window), used, and destroyed. The long-lived signing identity lives on-prem and signs an attestation that delegates authority to the cloud key for a bounded window.

This pattern compounds well with build-pipeline threat models where a stolen long-lived key is catastrophic but a stolen 6-hour key has bounded blast radius. Sigstore, GitHub OIDC-based signing, and the SLSA Level 3 attestation chain all assume some variant of this pattern.

Migration Realities

The brochure says you can migrate from HSM A to HSM B. The reality is that you usually cannot, and the projects that pretend otherwise end in 90-day outages.

Most HSM vendors will not let you export plaintext private key material — that is the point of the device. Exporting a wrapped key requires a key-wrapping key shared between source and destination, which requires either a common vendor (Thales-to-Thales via cloning, nShield-to-nShield via Security World) or a one-time PKCS#11 wrap-import ceremony with a customer-controlled KEK. Cross-vendor migration of asymmetric keys is technically possible for RSA and ECDSA, but for ML-DSA and ML-KEM the wrap formats are still vendor-specific in 2026 and FIPS 140-3 IG D.G is still being interpreted.

Plan on re-issuance, not migration.

Re-issuance means generating new keys in the destination HSM, issuing new certificates for the new keys, and rotating every consumer to the new chain. For a CA this is straightforward but slow: every subordinate CA, every end-entity certificate, every key-pinning configuration, every code-signing client, and every Authenticode validator has to accept the new chain before the old chain expires.

Pinning is the killer. HPKP is dead, but mobile apps pin certificates, hardcoded trust stores in IoT firmware pin certificates, payment terminals pin certificates, and every pin is a hardcoded value that requires a firmware push to rotate. A migration scoped without enumerating every consumer of every key will hit a pin it did not know existed, and the outage will be measured in days, not minutes.

Downtime windows are the other reality. For an offline root, the cutover is a ceremony — eight hours, witnessed, transcribed, low risk. For an online issuing CA serving an ACME endpoint at 4,000 issuances per minute, the cutover is a parallel-run period where both old and new chains issue concurrently for 30 to 90 days, then a careful old-chain wind-down once consumers have migrated.

Plan a 6-month parallel-run minimum for any consumer-facing PKI, and budget for the fact that 5 to 10 percent of consumers will not rotate before the deadline and will need a manual escalation.

Certificate chain implications outlive the migration. Cross-signing the new root from the old root buys backwards compatibility but extends the operational complexity until the old root expires. Cross-signing the old root from the new root is rarely useful.

AIA chasing under RFC 5280 4.2.2.1 will recover most chain problems automatically for clients that implement it correctly; clients that do not (every embedded device, half of mobile platforms) will simply fail. Test the chain on every client class before cutover and document the AIA URL availability SLO at 99.99 percent — if AIA goes down during the migration window, half the internet stops trusting you for a few hours.

Where Evertrust Fits

HSMs are the root of trust, but a root of trust without an orchestration layer is just an expensive box. The 2026 question is not just where the keys live — it is how the certificates that depend on those keys are issued, renewed, revoked, inventoried, and reported against PCI DSS 4.0, NIS2, DORA, eIDAS 2.0, and the EU Cyber Resilience Act.

Evertrust sits above the HSM, whether that HSM is on-prem, dedicated cloud, sovereign cloud, or a hybrid blend, and provides one operational and audit surface across all of them.

For a tier-1 bank, that means orchestrating issuance against a Thales payShield cluster on-prem while feeding the same inventory to the DORA concentration-risk register. For an IoT manufacturer, it means brokering BYOK to AWS CloudHSM at factory burn-in while the root stays in an offline Utimaco u.trust 360. For a SaaS, it means presenting a unified HYOK surface to enterprise customers who insist on operator-controlled keys. For a sovereign agency, it means a single audit trail across an Atos Trustway estate certified to ANSSI standards.

To see how the orchestration layer connects to the cryptographic substrate — on-prem HSM, HSMaaS, or hybrid — explore Evertrust PKI.