Cloud security architects assessing post-quantum readiness for key management infrastructure face a consistent problem: the question of whether a cloud KMS "supports PQC" conflates two distinct capabilities that are not equally available. Storing opaque PQC key material in a cloud KMS and having that KMS perform ML-KEM or ML-DSA operations within a validated cryptographic boundary are different things. All three hyperscalers can, in some form, do the former. None can do the latter in a FIPS 140-3 validated configuration as of August 2025. The practical migration architecture for most organisations flows from that gap.

For the database encryption layer above the KMS hierarchy and the mechanics of key re-wrapping without data re-encryption, see PQC at the Application Layer: Database Encryption Migration. For CNSA 2.0 key management obligations for US government and Defence Industrial Base contractors, see CNSA 2.0 vs 1.0: What Changes for Key Management.

What cloud KMS must support for PQC: the three-layer test

A complete PQC migration at the cloud KMS layer requires three categories of capability:

Key generation means creating ML-KEM-768 or ML-KEM-1024 encapsulation key pairs, ML-DSA-65 or ML-DSA-87 signing key pairs, and SLH-DSA-SHA2-128s key pairs for long-lived signing use cases. All are specified in NIST FIPS 203, FIPS 204, and FIPS 205 respectively.

Key storage means protecting private keys (ML-KEM decapsulation keys, ML-DSA signing keys) inside hardware security modules or software key stores with equivalent access controls to current RSA and ECDSA key storage.

Key operations means performing ML-KEM encapsulation and decapsulation, ML-DSA signing and verification, and SLH-DSA signing and verification on demand via the KMS API, or exporting key material to calling applications that perform these operations locally.

The gap between the three hyperscalers is primarily at the key operations layer, and specifically at the validated hardware boundary. Storing opaque PQC key material as a generic secret is within reach at all three platforms today. Generating structured PQC key material inside an HSM and performing ML-KEM or ML-DSA operations within a FIPS 140-3 validated boundary is not.

FIPS 140-3 validation is required for KMS components used by US federal agencies and Defence Industrial Base contractors under NSM-10 and CNSA 2.0 timelines. As of August 2025, no FIPS 140-3 validated HSM or software module had completed validation for ML-KEM, ML-DSA, or SLH-DSA. Validations were in progress at NIST's Cryptographic Module Validation Program (CMVP). NIST IR 8547 (November 2024) sets out the transition timeline context. Commercial deployments may proceed on non-validated implementations while awaiting validation, with the understanding that CNSA 2.0 compliance for the 2030 (software) and 2033 (hardware) deadlines will require validated modules.

Two interoperability specifications matter for multi-platform key management. PKCS#11 v3.0 (OASIS, June 2020) added mechanism identifiers for Kyber (CKM_KYBER_KEY_PAIR_GEN, CKM_KYBER) and Dilithium (CKM_DILITHIUM). PKCS#11 v3.1 was expected to align these with the finalised FIPS 203 and FIPS 204 identifiers. HSMs exposing a PKCS#11 interface with pre-standard Kyber mechanism identifiers will not interoperate directly with applications using FIPS 203 ML-KEM identifiers. KMIP v2.1 (OASIS, 2021) added ML-KEM and ML-DSA key object types for organisations managing keys across multiple KMS platforms via a KMIP client; both client and server must support KMIP v2.1 for PQC key object exchange.

AWS KMS: what is and is not available today

AWS KMS key spec parameters as of August 2025: SYMMETRIC_DEFAULT (AES-256-GCM), RSA_2048/3072/4096, ECC_NIST_P256/P384/P521, ECC_SECG_P256K1, and HMAC. No ML-KEM or ML-DSA key spec was offered. ML-KEM encapsulation key pairs and ML-DSA signing key pairs cannot be generated natively in AWS KMS. [ASSUMED: verify current key spec list at the AWS KMS Developer Guide before deployment planning.]

AWS Custom Key Store backed by AWS CloudHSM provides the nearest available path for HSM-enforced key storage. CloudHSM as of August 2025 ran Cavium Nitrox HSMs with supported key types of RSA (up to 4096-bit), ECC (P-224 through P-521), AES, 3DES, and HMAC. ML-KEM and ML-DSA key generation are not natively supported. An organisation can import externally generated ML-KEM or ML-DSA key material into CloudHSM as an opaque WRAP key type for storage purposes, but CloudHSM cannot perform ML-KEM or ML-DSA operations on that material natively. The practical consequence: applications that import PQC key material for storage must retrieve it and perform PQC operations outside the CloudHSM boundary. That reduces the tamper-evidence and access-control guarantees the HSM provides; under FIPS 140-3, cryptographic operations that occur outside the validated module boundary do not carry the module's assurance level.

AWS Certificate Manager (ACM) as of August 2025 supported RSA-2048/4096 and ECDSA P-256/P-384 for TLS certificates issued to AWS-managed services including ALB, CloudFront, and API Gateway. No ML-DSA certificate issuance capability existed in ACM. For TLS post-quantum certificate migration at AWS-managed endpoints, organisations must either wait for ACM ML-DSA support or use externally issued ML-DSA certificates with manual import to ACM.

AWS Nitro Enclaves use KMS GenerateDataKey to manage data encryption keys (DEKs) for data processed within enclave boundaries. That operation uses RSA-OAEP or AES key wrapping to deliver the DEK to the enclave. As of August 2025, no ML-KEM wrapping option was available for GenerateDataKey, meaning the DEK delivery channel remains RSA-based pending native ML-KEM support.

Azure Key Vault: no PQC support and the BYOK trade-off

Azure Key Vault standard and Premium tiers as of August 2025 supported RSA (2048/3072/4096), EC (P-256/P-256K/P-384/P-521), and AES (128/192/256). No FIPS 203, 204, or 205 algorithm keys were available. [ASSUMED: verify current Azure Key Vault key type support before planning.]

Azure Managed HSM and Azure Dedicated HSM use Marvell LiquidSecurity HSMs validated to FIPS 140-2 Level 3. Azure Managed HSM's supported key types matched Key Vault Premium: RSA up to 4096-bit, ECDSA P-256/P-384/P-521, AES-256. ML-KEM and ML-DSA are not supported. An organisation requiring PQC key operations within an HSM boundary for Azure workloads cannot meet that requirement with Azure's native HSM products as of this analysis.

The external HSM path uses Thales CipherTrust Manager via Azure's Bring Your Own Key (BYOK) mechanism to import key material. Like AWS CloudHSM's opaque import path, BYOK allows PQC key material to reside under Azure Key Vault's access control model, but application-layer PQC operations occur outside Azure's HSM cryptographic boundary. This is operationally useful for key confidentiality but does not provide HSM-attested PQC operations.

Microsoft's published PQC migration strategy (September 2024) confirmed alignment with NIST FIPS 203, 204, and 205 and a phased migration roadmap for Azure services. No specific Key Vault feature availability date was published. Microsoft's TLS infrastructure for Teams and Azure HTTPS endpoints was evaluating hybrid key exchange in parallel. The commitment is public; the delivery timeline for Key Vault-specific PQC native support is not.

GCP Cloud KMS: furthest along, but still preview

GCP Cloud KMS as of August 2025 added ML-KEM (labelled ML_KEM_768 with RAW_ENCRYPT_DECRYPT purpose) and ML-DSA as preview key algorithms in its key version resource. This reflects Google's broader quantum-resistant cryptography programme, consistent with Google's production deployment of X25519+ML-KEM-768 hybrid TLS in Chrome via BoringSSL. The preview designation means no Cloud KMS SLA coverage and not generally available for production use. [ASSUMED: verify current GA status and SLA coverage at the Cloud KMS algorithm documentation before deployment planning.]

Google Cloud HSM (the HARDWARE protection level in Cloud KMS) uses Marvell NITROX HSMs validated to FIPS 140-2 Level 3. The HARDWARE protection level supports a subset of algorithms compared to the SOFTWARE protection level. Whether ML-KEM and ML-DSA preview algorithms are available at HARDWARE protection level was not confirmed in publicly available GCP documentation as of August 2025. This is the operationally critical question for regulated workloads: preview Cloud KMS support at SOFTWARE protection level means Google's software key management protects the private key material, not an HSM. For workloads that require HSM-backed PQC key storage, GCP's offering is not confirmed to qualify until HARDWARE-level support is documented and FIPS 140-3 validation for the PQC algorithms is complete.

Google Cloud Certificate Authority Service (Cloud CAS) as of August 2025 supported RSA-2048/4096 and EC P-256/P-384 for CA key material and issued certificate signatures. ML-DSA certificate issuance was not available. Organisations requiring ML-DSA TLS certificates from a GCP-managed private CA cannot use Cloud CAS without external tooling.

Side-by-side comparison and what it means operationally

GCP has the most advanced PQC API position, but preview status is not a deployment basis for regulated workloads. For US Defence Industrial Base contractors whose obligations reference CNSA 2.0 timelines, NSA's 2030 deadline for software implementations and 2033 deadline for hardware implementations means the FIPS 140-3 validation gap affects all three platforms equally in terms of compliance readiness. The practical consequence is that cloud KMS alone cannot satisfy the CNSA 2.0 hardware key management requirement for PQC without either FIPS 140-3 validation completing or a BYOHSM architecture supplementing cloud KMS.

Migration architecture while waiting for native support

The interim architecture available to organisations that cannot wait for native cloud KMS PQC support has two variants.

Application-layer KEM: perform ML-KEM encapsulation and decapsulation within the application tier using a FIPS 203 library (Open Quantum Safe liboqs, BoringSSL, AWS s2n-tls with PQC support). Store the ML-KEM decapsulation key material as a generic secret in cloud KMS, protected at rest by the cloud KMS customer master key (an AES-256 CMK). The AES-256 CMK wraps the PQC private key in storage. This provides confidentiality of the PQC private key at rest, but cloud HSM-attested PQC operations are not available: the HSM enforces only the AES-256 wrapping key, not the ML-KEM operations themselves.

One important scoping point: AES-256 symmetric CMKs in any cloud KMS do not require PQC replacement. AES-256 retains approximately 128-bit post-quantum security under Grover's algorithm (NIST IR 8547 confirms AES-256 retention in the post-quantum algorithm inventory). If your cloud CMK hierarchy uses symmetric AES-256 CMKs for envelope encryption, those CMKs are already quantum-safe. The vulnerable layer is the asymmetric operations: RSA key wrapping of DEKs, ECDSA certificate signing. Many cloud KMS deployments that use symmetric CMKs require only the asymmetric operation layer to migrate, which is a substantially narrower scope than a full key hierarchy replacement.

BYOHSM path: deploy an on-premises or co-located Thales Luna Network HSM 7 or Utimaco SecurityServer with PQC firmware, both of which have published PQC roadmaps aligned with FIPS 203, 204, and 205. Connect to cloud applications via the HSM network interface. This provides HSM-enforced PQC operations with hardware boundary assurance but reintroduces on-premises HSM management complexity. For regulated workloads with a hard FIPS 140-3 HSM-backed PQC requirement, BYOHSM is the only path available pending cloud platform native support.

Multi-region key deployments require coordinated updates when key types change. All three platforms offer multi-region key replication (AWS KMS multi-region keys, Azure Key Vault geo-redundancy, GCP global key rings). Adding a new key type for PQC, where a different algorithm key pair must be created rather than updating an existing key resource (algorithm is immutable per key in all three platforms), requires creating the new PQC key in all applicable regions. No cloud KMS platform provided automated multi-region PQC key rollout tooling as of August 2025.

Four-step cloud KMS PQC readiness assessment

Step 1: Inventory asymmetric key types. Enumerate all customer master keys, key pairs, and certificate keys across all cloud KMS accounts, subscriptions, and projects. Identify RSA and ECDSA keys and tag by usage: TLS, envelope encryption, signing, key wrapping. This is your cryptographic bill of materials (CBOM) at the cloud KMS layer. The QSECDEF Cryptographic Asset Register tool provides a structured starting point for this inventory.

Step 2: Classify by HNDL urgency. Which keys protect HNDL-relevant operations: key wrapping of long-lived data, TLS key exchange, archive encryption? These are migration priority 1. Signing keys for internal artefacts (code signing, configuration signing with short-lived material) follow on a longer timeline.

Step 3: Assess the cloud provider roadmap with current documentation. For each platform in scope, verify: has ML-KEM and ML-DSA native key type been released? Is it GA or preview? Is it FIPS 140-3 validated? Is it available at HSM protection level? This brief reflects August 2025 status. The field is moving. Use current vendor documentation, not this article, for deployment planning.

Step 4: Choose interim architecture with documented trade-offs. Application-layer KEM with OQS liboqs, BYOHSM, or wait for native cloud KMS PQC. Document the trade-offs accepted in each option and define the trigger criteria for switching to native cloud KMS PQC when the capability becomes available and validated. The trigger criteria belong in your security architecture documentation, not just in informal planning notes.