Every organization that handles cryptographic keys faces the same question: where do those keys physically live? The answer used to be simple — buy an HSM, rack it in your data center, manage it yourself. Now there are three options: on-premises HSMs you own, dedicated cloud HSMs managed by a provider, and multi-tenant cloud KMS services backed by shared HSM infrastructure.
Each model has different security properties, cost structures, operational requirements, and compliance implications. Choosing wrong is expensive — keys generated in one HSM can’t be extracted and moved to another. Your choice is effectively permanent for the lifetime of those keys.
The Three Models
1. On-Premises HSM (You Own Everything)
You purchase physical HSM hardware, install it in your data center, and manage the entire lifecycle: initialization, key ceremonies, firmware updates, HA configuration, physical security, and eventual decommissioning.
Examples: Thales Luna Network HSM 7, Entrust nShield Connect XC, Utimaco SecurityServer
You get:
- Full physical control (you can verify tamper seals yourself)
- No third-party access to your keys (ever)
- No network dependency for key operations
- Complete audit trail under your control
- Ability to operate air-gapped (offline Root CAs)
You accept:
- $30,000-$100,000+ per HSM (plus annual maintenance contracts)
- 12-16 week procurement lead time
- Rack space, power, cooling, physical security
- Staff trained in HSM administration
- Firmware update responsibility
- HA configuration (minimum 2 HSMs for production)
- Key ceremony logistics (secure room, witnesses, M-of-N cards)
2. Dedicated Cloud HSM (Provider Manages Hardware, You Manage Keys)
The cloud provider gives you a dedicated, single-tenant HSM instance in their data center. You control the keys (they can’t access them). They manage hardware health, availability, and physical security.
Examples: AWS CloudHSM, Azure Dedicated HSM (Thales Luna hardware), Google Cloud HSM
You get:
- FIPS 140-2 Level 3 hardware (same as on-premises)
- Single-tenant (your keys are isolated on dedicated hardware)
- Provider manages hardware failures, replacements, physical security
- Deploy in minutes (API call, not procurement cycle)
- Multi-AZ availability built-in
- Same PKCS#11 interface as on-premises (code portability)
You accept:
- $1.50-$2.00/hour per HSM instance (~$1,100-$1,500/month)
- Keys can’t be exported (locked to provider’s infrastructure)
- Network dependency (HSM is in provider’s VPC)
- Provider manages firmware (you approve, they apply)
- No physical access to verify tamper seals
- Trust the provider’s physical security controls
3. Multi-Tenant Cloud KMS (Fully Managed, Shared Infrastructure)
The cloud provider operates a shared HSM fleet. Your keys are stored alongside other customers’ keys (logically isolated, physically shared). You interact via API only — no PKCS#11, no direct HSM access.
Examples: AWS KMS, Azure Key Vault (Standard tier), Google Cloud KMS
You get:
- Simplest possible interface (API calls only)
- Automatic availability and redundancy
- Automatic key rotation (optional)
- Pay-per-operation pricing ($0.03 per 10,000 requests)
- Integrated with all cloud services natively
- No operational overhead whatsoever
You accept:
- FIPS 140-2 Level 2 (not Level 3) for most services
- Multi-tenant (your keys share hardware with other customers)
- No PKCS#11 access (API only — can’t use with traditional CA software)
- Vendor lock-in (keys non-exportable, API is proprietary)
- Trust the provider’s logical isolation between tenants
- Limited algorithm support (provider decides what’s available)
Comparison Matrix
| Criteria | On-Premises | Cloud HSM (Dedicated) | Cloud KMS (Shared) |
|---|---|---|---|
| FIPS Level | Level 3 | Level 3 | Level 2 (typically) |
| Tenancy | Single (yours) | Single (dedicated) | Multi-tenant |
| Physical control | Full | None (provider) | None (provider) |
| Key exportability | HSM-to-HSM only | Not exportable | Not exportable |
| Setup time | Weeks-months | Minutes | Minutes |
| Monthly cost (HA) | ~$3,000-$8,000 (amortized) | ~$2,200-$3,000 | ~$10-$100 |
| Upfront cost | $60,000-$200,000 | $0 | $0 |
| Operational burden | High | Low | None |
| PKCS#11 support | Yes | Yes | No |
| Air-gap capable | Yes | No | No |
| Vendor lock-in | Low (standard PKCS#11) | Medium (can’t export keys) | High (proprietary API) |
| Best for | Root CAs, payment, government | Issuing CAs, production signing | Application encryption, secrets |
Decision Framework: When to Use Each
Use On-Premises HSM When:
- Root CA keys — the trust anchor of your PKI should be under your exclusive physical control, stored offline
- Payment processing — PCI PIN Security requires HSMs under your direct control for PIN translation keys
- Government/classified — regulations require keys to remain within specific facilities or national borders
- Air-gapped operations — the HSM must operate without any network connectivity
- You need to verify physical security — tamper seals, secure room access, key ceremony witnesses
Use Dedicated Cloud HSM When:
- Issuing CA keys — online CAs that sign certificates frequently need high availability (cloud HSM provides this)
- Production code signing — frequent signing operations that need HSM protection but can’t tolerate on-premises operational overhead
- Migrating from on-premises — same PKCS#11 interface means existing code works without changes
- Multi-region deployment — need HSM access from multiple geographic locations
- You want Level 3 without the operational burden — same security level, provider handles hardware
Use Cloud KMS When:
- Application-level encryption — encrypting database fields, S3 objects, secrets at rest
- Envelope encryption — wrapping data encryption keys (DEKs) with a master key
- Low-volume signing — occasional document signing, JWT signing, webhook verification
- You need native cloud integration — KMS integrates directly with S3, EBS, RDS, Lambda, etc.
- Budget is the primary constraint — $1/month per key vs $1,500/month per HSM
The Hybrid Pattern (Most Common in Practice)
Most mature organizations use all three:
Root CA Key → On-Premises HSM (offline, air-gapped, key ceremony)
↓ signs
Issuing CA Key → Cloud HSM (online, HA, high-volume signing)
↓ issues certificates for
Application TLS Keys → Cloud KMS or cert-manager (automated, ephemeral)
Payment PIN Keys → On-Premises HSM (PCI requirement)
Code Signing Key → Cloud HSM (CI/CD integration, frequent use)
Data Encryption Keys → Cloud KMS (application integration, low cost)This gives you:
- Maximum security for the most critical keys (Root CA, payment)
- Operational simplicity for high-volume operations (Issuing CA, code signing)
- Minimal cost for application-level encryption (KMS)
Migration Considerations
On-Premises → Cloud HSM
The problem: Keys generated in an on-premises HSM cannot be extracted in plaintext. You can’t “move” a key to a cloud HSM.
Options:
- Key wrapping — if both HSMs support the same wrapping mechanism (rare across vendors)
- Re-key — generate a new key in the cloud HSM, re-issue all certificates signed by the old key, update all trust stores. This is effectively rebuilding your PKI.
- Hybrid period — run both HSMs simultaneously during transition. New certificates from cloud HSM, old certificates remain valid until expiry.
Recommendation: Plan your HSM choice at PKI design time. Migrating later is a multi-month project.
Cloud HSM → On-Premises
Same problem in reverse. Keys in AWS CloudHSM can’t be exported to a Thales Luna in your data center. The only path is re-keying.
Between Cloud Providers
AWS CloudHSM keys can’t move to Azure Dedicated HSM or Google Cloud HSM. Multi-cloud key portability doesn’t exist. If you need multi-cloud, keep your Root CA on-premises (portable) and create provider-specific Issuing CAs in each cloud.
Cost Analysis: 3-Year TCO
Scenario: 2 HSMs for HA, supporting a PKI Issuing CA
| Cost Component | On-Premises | AWS CloudHSM | AWS KMS |
|---|---|---|---|
| Hardware/service | $80,000 | $0 | $0 |
| Monthly operational | $2,500 | $2,336 | $3 |
| Annual maintenance | $16,000 | $0 | $0 |
| Staff (partial FTE) | $30,000/yr | $5,000/yr | $0 |
| 3-Year Total | $278,000 | $99,096 | $108 |
The cost difference is dramatic. But cost isn’t the only factor — security requirements, compliance mandates, and operational control needs drive the decision as much as budget.
FAQ
Q: Can I use AWS KMS for a Certificate Authority? A: AWS KMS doesn’t support PKCS#11, so traditional CA software (EJBCA, Microsoft AD CS) can’t use it directly. AWS Private CA uses KMS internally, but you interact via the ACM-PCA API, not PKCS#11. For custom CA deployments, use AWS CloudHSM (which does support PKCS#11).
Q: Is cloud KMS secure enough for production encryption keys? A: For application-level encryption (database fields, file encryption, secrets), yes — cloud KMS is appropriate and widely used. For CA signing keys and payment processing, dedicated HSM (Level 3) is required by compliance standards.
Q: What happens if the cloud provider has an outage? A: Existing encrypted data remains encrypted (you don’t need the HSM to store encrypted data). But you can’t encrypt new data or sign new certificates until the HSM is available. For cloud HSM: multi-AZ deployment mitigates this. For KMS: the provider’s SLA applies.
Q: Can I bring my own key (BYOK) to cloud KMS? A: Yes — AWS, Azure, and GCP all support importing your own key material into KMS. However, the imported key is still non-exportable once inside. BYOK gives you control over key generation (you can generate in your own HSM) but not ongoing portability.