← Back to Blog Tutorials

AWS CloudHSM: PQC Algorithm Coverage

10 min read

AWS CloudHSM gives customers dedicated, single-tenant hardware security modules in the AWS cloud. It is the choice when AWS Key Management Service (KMS) is too multi-tenant for the threat model and when the customer needs FIPS 140-3 Level 3 hardware boundaries that they exclusively control. This post walks through where CloudHSM stands on post-quantum cryptography algorithm coverage, how the underlying hardware affects PQC availability, and how it relates to AWS KMS.

What CloudHSM Actually Is

CloudHSM provisions dedicated HSM hardware in AWS data centers and exposes it to a customer's VPC. The customer:

Initializes the HSM cluster with their own crypto officer credentials
Generates and manages all keys directly on the hardware
Accesses the HSMs via PKCS#11, JCE, OpenSSL, or KMIP

AWS does not have access to customer keys or operations. The HSM tamper protection means even AWS personnel cannot extract keys from the hardware. This is the fundamental security property that distinguishes CloudHSM from the multi-tenant AWS KMS service.

The Underlying Hardware

AWS CloudHSM is built on Marvell LiquidSecurity HSM hardware. Marvell (formerly Cavium) makes the HSMs that AWS deploys in their data centers. The PQC algorithm availability in CloudHSM tracks the Marvell firmware roadmap.

This is operationally significant because:

New algorithms appear when Marvell ships firmware that supports them
AWS must integrate, validate, and roll out the firmware update across all CloudHSM regions
The end-to-end timeline from "Marvell ships firmware" to "feature available in all AWS regions" is several months

The result is that CloudHSM tends to lag standalone HSM deployments in PQC algorithm availability. A customer running their own Marvell hardware on premises can deploy a new firmware revision the day Marvell ships it. CloudHSM customers wait for AWS to integrate.

Why Customers Choose CloudHSM Over KMS

The decision tree between CloudHSM and KMS hinges on:

Compliance. FIPS 140-3 Level 3 single-tenant hardware boundary requirements push customers toward CloudHSM. KMS uses multi-tenant HSMs (also FIPS 140-3, but the boundary is shared).
Custom algorithm support. CloudHSM supports a wider range of algorithms via PKCS#11 than KMS, which exposes a curated subset.
Direct PKCS#11 access. Some applications integrate via PKCS#11 and prefer the direct hardware access model.
Custom workflows. CloudHSM allows operations like key wrapping, key derivation, and arbitrary signing flows that KMS does not expose.
Cost predictability. CloudHSM has fixed hourly pricing. KMS scales per request, which can be cheaper or more expensive depending on workload.

For a separate look at AWS KMS PQC migration, see our AWS KMS quantum migration post.

PQC Algorithm Tracking

The PQC algorithms that matter for CloudHSM customers:

ML-KEM (FIPS 203). Module-lattice key encapsulation. Replaces RSA-OAEP and elliptic curve key agreement.
ML-DSA (FIPS 204). Module-lattice digital signatures. Replaces RSA and ECDSA for signing.
SLH-DSA (FIPS 205). Hash-based digital signatures. Conservative backup for long-lived signatures.

For background on the differences, see our ML-KEM explained and ML-DSA vs SLH-DSA posts.

CloudHSM availability of these algorithms tracks the Marvell firmware roadmap. Customers should consult the AWS CloudHSM documentation and release notes for the specific algorithms exposed in the current firmware.

Migration Patterns for CloudHSM Customers

A typical CloudHSM customer running PQC migration follows this pattern:

Inventory keys. Use the CloudHSM management tools to list all keys, their algorithms, and their usage patterns.
Identify long-lived keys. Anything signing data or wrapping keys that must remain confidential for decades is high priority.
Plan for parallel keys. Generate new ML-DSA-65 or ML-KEM-1024 keys alongside existing classical keys. Run them in parallel until applications are updated.
Update application clients. PKCS#11 clients need updates to understand the new mechanism identifiers.
Cut over. Once parallel operation is stable, cut new operations to the PQC keys.
Retire classical keys. After the cutover period, retire classical keys per CNSA 2.0 or your applicable regime.

For background on the NIST FIPS standards driving this work, see our NIST FIPS guide.

CloudHSM and Applications

Common application patterns on CloudHSM that need PQC consideration:

TLS termination. Some customers use CloudHSM to protect TLS server private keys via OpenSSL engine integration. PQC migration here depends on TLS protocol evolution and load balancer support.
Code signing. Build pipelines that sign software releases with HSM-protected keys. PQC migration here is straightforward if the code-signing tooling supports the new algorithms.
Database encryption. Database transparent data encryption (TDE) often uses CloudHSM to protect master keys. PQC affects key wrapping but not the bulk encryption layer.
Document signing. Legal and compliance signing applications. PQC migration here depends on the document signing standards in use (PAdES, CAdES, etc.).
Cryptographic erasure. Some customers use CloudHSM for cryptographic erasure of large datasets. PQC affects the key derivation hierarchy but not the erasure semantics.

Hybrid Mode Considerations

CloudHSM customers can implement hybrid post-quantum modes today by:

Generating a classical key (RSA-3072 or ECDSA P-384) and a PQC key (ML-DSA-65 or ML-KEM-1024) in parallel
Performing both operations at the application layer
Combining the results per a defined hybrid construction

The application carries the burden of correct hybrid composition. This is more error-prone than a native hybrid mechanism, but it works on any CloudHSM firmware that has both algorithm families.

For more on hybrid construction, see our hybrid encryption post.

Performance Expectations

CloudHSM performance for PQC operations follows the underlying Marvell hardware. Expectations:

ML-DSA-65 signing. Hundreds to thousands of signatures per second per HSM, slower than ECDSA P-256 on the same hardware.
ML-DSA-65 verification. Comparable to or faster than ECDSA verification.
ML-KEM-1024 encapsulation/decapsulation. Fast, often faster than RSA-2048 key transport.

For high-throughput applications (code signing pipelines, mass document signing), customers may need to provision additional HSM cluster members to maintain throughput during the migration.

Cost Considerations

CloudHSM pricing is per HSM-hour, not per cryptographic operation. PQC migration does not directly increase cost for most customers. However, cost can increase if:

Performance degradation requires additional HSM cluster members
Hybrid mode doubles the operations per logical request
Migration testing requires additional non-production clusters

Customers should benchmark PQC operations against their workload before committing to a migration timeline.

FIPS 140-3 Validation Status

CloudHSM operates under the Marvell LiquidSecurity HSM's FIPS 140 validation. The validation must cover the PQC algorithms for compliance-mandated use. Customers should:

Check the NIST CMVP active modules listing for the LiquidSecurity firmware version that AWS deploys
Verify the algorithm certificate covers the PQC algorithms they need
Confirm with AWS support which firmware version is deployed in their region

The CMVP validation timeline runs behind the firmware release timeline by several months because validation testing takes time. Customers in regulated industries should plan around this lag.

Operational Differences from KMS

CloudHSM differs from KMS in ways that matter for PQC migration:

Direct algorithm access. CloudHSM exposes PKCS#11 mechanism identifiers. Customers control which algorithms are used per operation.
Key versioning. CloudHSM does not have built-in key versioning the way KMS does. Customers must implement versioning at the application layer.
Cross-region replication. CloudHSM clusters are region-bound. Cross-region replication requires the customer to set up explicit replication. KMS handles this transparently.
Operational responsibility. CloudHSM customers manage HSM cluster health, partition management, and operator credentials. KMS handles all of this.

For PQC migration, the direct PKCS#11 access in CloudHSM gives customers more control but more operational burden compared to KMS.

Multi-Region Considerations

CloudHSM clusters are region-bound. A cluster in us-east-1 cannot be directly extended to us-west-2; instead, operators run separate clusters in each region and replicate keys explicitly. PQC migration in a multi-region deployment adds complexity because:

Each region's CloudHSM clusters may have different firmware versions during a rolling update
Cross-region key replication must handle PQC key sizes
Application logic that load-balances across regions must handle algorithm version differences during the migration

Best practices for multi-region PQC migration include staging the firmware update region by region, with non-production environments updated first, then production environments after validation.

Disaster Recovery and Backup

CloudHSM supports backup and restore operations for high availability and disaster recovery. PQC migration affects backups in two ways:

Backup file size. PQC keys are larger than classical keys. Backup files grow proportionally. Storage allocation in S3 or other backup destinations should be reviewed.
Restore compatibility. A backup taken from a CloudHSM with PQC firmware can only be restored to another CloudHSM with compatible firmware. Operators should verify firmware version compatibility before relying on a backup for disaster recovery.

For organizations with strict RPO and RTO requirements, the firmware version compatibility constraint should be part of disaster recovery planning.

Integration with AWS Services

CloudHSM integrates with several AWS services:

AWS Certificate Manager Private CA. Can use CloudHSM as the underlying key store for issuing certificates.
Oracle TDE on RDS. Some Oracle deployments on RDS use CloudHSM for transparent data encryption master keys.
Custom applications. Direct PKCS#11 or JCE integration.
Third-party software. Many enterprise software products support CloudHSM via PKCS#11.

Each integration point needs PQC support at multiple layers: the CloudHSM firmware, the AWS service, and the consuming application. The integration point that lags becomes the bottleneck for the overall migration.

Cost Implications of Migration

CloudHSM pricing is per HSM hour, not per cryptographic operation. PQC migration does not directly increase per-operation cost, but cluster sizing may need adjustment because:

ML-DSA signing is slower than ECDSA, reducing per-HSM throughput
Hybrid mode doubles the operations per logical request
Migration testing requires non-production cluster members

For cost-sensitive deployments, benchmarking PQC throughput against actual workload volumes is the right way to size the post-migration cluster. Over-provisioning during the migration period and right-sizing after stabilization is a sensible approach.

Comparison with AWS KMS

CloudHSM and AWS KMS serve different threat models. CloudHSM is single-tenant FIPS 140-3 Level 3 hardware. KMS is multi-tenant FIPS 140-3 hardware with a managed service abstraction. PQC migration trajectories differ:

KMS abstracts the underlying HSM, so AWS controls the algorithm exposure timeline
CloudHSM exposes the underlying HSM directly, so customers see PQC algorithms when the firmware ships them
KMS may add PQC algorithms in its managed API ahead of CloudHSM exposing them at PKCS#11
Some customers will run both for different use cases during the transition

For the AWS KMS-specific story see our AWS KMS quantum migration post.

Frequently Asked Questions

Does AWS CloudHSM support post-quantum cryptography? Algorithm availability tracks the underlying Marvell firmware. Check the AWS CloudHSM documentation and release notes for current PQC algorithm coverage.

Should I use CloudHSM or KMS for PQC migration? Depends on threat model. CloudHSM gives single-tenant hardware boundaries and more direct algorithm control. KMS is multi-tenant but easier to operate. For most workloads KMS is sufficient. For highest-assurance requirements, CloudHSM.

What is the FIPS 140-3 status for CloudHSM PQC firmware? Check the NIST CMVP listings for the Marvell LiquidSecurity firmware version that AWS deploys. The validation must cover the PQC algorithms.

Can I use CloudHSM with my existing PKCS#11 clients? Yes, but client libraries may need updates to understand PQC mechanism identifiers. Test with the specific client library version.

How do I handle hybrid mode on CloudHSM? Generate classical and PQC keys in parallel. Perform both operations at the application layer. Combine the results per the defined hybrid construction.

Sources

AWS. "AWS CloudHSM Documentation." https://aws.amazon.com/cloudhsm/
NIST. "FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard." 2024.
NIST. "FIPS 204: Module-Lattice-Based Digital Signature Standard." 2024.
NIST CMVP. "Cryptographic Module Validation Program Active Modules." https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules
OASIS. "PKCS #11 Cryptographic Token Interface Standard v3.1." https://docs.oasis-open.org/pkcs11/
NIST. "Post-Quantum Cryptography Standardization." https://csrc.nist.gov/projects/post-quantum-cryptography

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY