AWS vs Azure vs Google Cloud Post-Quantum Support
AWS, Microsoft Azure, and Google Cloud all support some form of post-quantum cryptography (PQC), but the overlap is smaller than a provider-level label suggests. One provider may have a generally available signature service, another may expose algorithms only through operating-system APIs, and a third may protect TLS connections without offering an equivalent KEM key inside its managed KMS.
This directory compares deployable workflows, not marketing positions. A GA algorithm in a library does not make a managed service GA. Hybrid TLS does not add post-quantum signatures. A quantum-safe import channel does not change how the imported key is used after import.
Last verified: August 17, 2026. Statuses below refer to the named capability only.
Executive summary
- Managed PQ signatures: AWS KMS and Google Cloud KMS both offer GA ML-DSA signing. Google Cloud KMS also offers GA SLH-DSA. Azure Key Vault does not document ML-DSA or SLH-DSA key types.
- Direct KEM operations in managed KMS: Google Cloud KMS documents ML-KEM-768, ML-KEM-1024, and X-Wing in Preview. AWS uses ML-KEM extensively for TLS but does not document an equivalent customer KEM-key workflow in AWS KMS. Azure Key Vault does not expose ML-KEM keys.
- Quantum-safe key import: Google Cloud is the only one of these three documenting an HPKE-based quantum-safe import workflow. It is Preview and accepts software-backed target keys only.
- HSM-backed PQ signing: AWS KMS performs ML-DSA signing in FIPS 140-3 Level 3 validated HSMs. AWS CloudHSM has ML-DSA in Preview. Azure Key Vault and Managed HSM do not document PQ asymmetric key types. Google Cloud’s new quantum-safe import methods do not accept Cloud HSM, Cloud HSM Single-tenant, or Cloud EKM targets.
- TLS: AWS documents hybrid ML-KEM TLS across specific service endpoints and customer-configured resources. Google uses ML-KEM for internal network traffic, while support on customer-facing services varies. Microsoft provides GA ML-KEM platform APIs, but managed Azure service support must be verified service by service.
- Private PKI: AWS Private CA supports ML-DSA CA and certificate signing. Windows Server 2025 AD CS supports pure ML-DSA certificates with required updates. Google Cloud Certificate Authority Service does not document PQ certificate issuance.
Cloud PQC capability matrix
| Workflow | AWS | Google Cloud | Microsoft Azure |
|---|---|---|---|
| ML-DSA managed signing | AWS KMS GA, ML-DSA-44/65/87 | Cloud KMS GA, ML-DSA-44/65/87 | No ML-DSA key type documented in Key Vault; GA in Windows and .NET APIs |
| SLH-DSA managed signing | No AWS KMS support documented | Cloud KMS GA, SLH-DSA-SHA2-128s variants | No Key Vault or platform integration documented in reviewed sources |
| ML-KEM-768 KEM key | No customer KEM-key workflow documented in AWS KMS | Cloud KMS Preview | No Key Vault key type; GA platform API in Windows and .NET |
| ML-KEM-1024 KEM key | No customer KEM-key workflow documented in AWS KMS | Cloud KMS Preview | No Key Vault key type; GA platform API in Windows and .NET |
| Hybrid X-Wing KEM | No comparable managed KMS workflow documented | Cloud KMS Preview | No comparable managed service workflow documented |
| Quantum-safe key import | No PQ import transport documented | Cloud KMS Preview using X-Wing or ML-KEM HPKE methods | No PQ import transport documented |
| PQ import target | No comparable workflow | SOFTWARE keys only | No comparable workflow |
| HSM-backed PQ signatures | AWS KMS ML-DSA GA; CloudHSM ML-DSA Preview | Quantum-safe import does not target Cloud HSM; check algorithm documentation per operation | Key Vault and Managed HSM lack PQ asymmetric key types |
| Public service endpoint PQ TLS | Documented for KMS, ACM, Secrets Manager, Payment Cryptography, S3, and others | Varies by service; not uniformly customer-configurable | No uniform managed-service claim; verify per endpoint |
| Customer edge/load balancer PQ TLS | CloudFront default; ALB/NLB opt-in PQ policies | No uniform customer-configurable capability documented | Platform TLS available; Front Door/Application Gateway PQ policies not documented |
| Private PKI | AWS Private CA supports ML-DSA | Certificate Authority Service lacks documented PQ issuance | Windows Server 2025 AD CS supports pure ML-DSA with required updates |
The matrix deliberately leaves some cells non-equivalent. AWS ML-KEM TLS support, for example, does not imply that AWS KMS exposes an ML-KEM private key for customer decapsulation. Likewise, Azure’s CNG and .NET algorithm APIs are not Azure Key Vault features.
AWS: strongest managed HSM signing and broad documented TLS coverage
AWS has two mature but separate PQC paths.
First, AWS KMS supports GA ML-DSA signing with ML_DSA_44, ML_DSA_65, and ML_DSA_87 key specifications. AWS states that key generation and signature operations occur in FIPS 140-3 Security Level 3 validated HSMs. Applications use standard KMS operations such as CreateKey, Sign, and Verify. Messages up to 4 KB can use the RAW message type; larger messages require an externally calculated 64-byte message representative and EXTERNAL_MU.
Second, AWS deploys ML-KEM as hybrid TLS key establishment. The documented public endpoints include KMS, ACM, Secrets Manager, Payment Cryptography, and regional S3 endpoints. Client behavior depends on runtime and SDK version. Some current SDKs prefer PQ TLS automatically, while others require a compatible system OpenSSL or explicit CRT client configuration.
AWS also covers customer-facing transport. CloudFront enables hybrid PQ key establishment across its TLS security policies by default. Application and Network Load Balancers offer opt-in PQ-TLS security policies. These are TLS capabilities, not KMS KEM-key operations.
For PKI, AWS Private CA supports ML-DSA CA keys and certificate signatures. IAM Roles Anywhere accepts ML-DSA PKIs as trust anchors. AWS CloudHSM separately lists ML-DSA key generation and signing as Preview. Teams must not treat AWS KMS GA and CloudHSM Preview as the same service status.
AWS is currently the strongest fit when the required workflow is HSM-backed managed ML-DSA signing, private ML-DSA PKI, or documented hybrid TLS across multiple AWS endpoints. It is not the direct equivalent of Google Cloud’s Preview KEM and quantum-safe import APIs.
See the detailed AWS post-quantum support guide.
Google Cloud: widest managed algorithm mix and the only documented PQ import path
Google Cloud KMS offers the broadest managed algorithm mix among these providers, but with mixed maturity.
ML-DSA and SLH-DSA digital signatures are GA. KEM operations using ML-KEM-768, ML-KEM-1024, or X-Wing are Preview. X-Wing is a hybrid KEM combining ML-KEM-768 with X25519. Applications retrieve the public key and perform encapsulation locally; Cloud KMS performs decapsulation.
Google Cloud also documents quantum-safe key import in Preview. The import methods combine X-Wing, ML-KEM-768, or ML-KEM-1024 with HPKE, HKDF-SHA256, and AES-256-GCM. This protects key material during the import transport workflow. It does not turn the imported key or its workload into a fully quantum-safe system.
The restriction that matters most for enterprise architecture is protection level. These quantum-safe import methods accept SOFTWARE target keys. They do not support Cloud HSM, Cloud HSM Single-tenant, or Cloud EKM targets. Import jobs expire after three days, and the imported material becomes a new key version.
Google uses ML-KEM in internal network encryption and Chrome supports hybrid PQ TLS. Customer-facing Google Cloud endpoint support is not documented as one uniform, configurable product capability, so teams should verify each service rather than infer coverage from BoringSSL or Google’s internal network deployment.
Google Cloud is the strongest current fit when a team needs managed SLH-DSA, wants to evaluate customer-controlled KEM decapsulation, or needs to pilot PQ-protected import into a software-backed KMS key. The latter two remain Preview.
See the detailed Google Cloud post-quantum support guide.
Azure: strong platform APIs, limited managed key integration
Microsoft’s strongest current PQC layer is the platform rather than Azure Key Vault.
Windows Server 2025, supported Windows 11 releases, and .NET 10 expose GA ML-KEM and ML-DSA APIs. This is useful for application-level cryptography and TLS stacks that use current CNG, Schannel, .NET, or OpenSSL implementations. It does not mean Azure Key Vault stores those key types.
The current Azure Key Vault key documentation lists RSA and elliptic-curve asymmetric key types. Managed HSM adds symmetric AES keys, but the reviewed Key Vault documentation does not list ML-KEM, ML-DSA, or SLH-DSA keys. Consequently, Azure has no directly comparable managed KMS signing, KEM, or quantum-safe import workflow in this comparison.
Windows Server 2025 AD CS adds a separate PKI capability. With the required 2026 security update, AD CS supports pure ML-DSA certificates and all three ML-DSA parameter sets. ML-KEM and composite certificate support remain planned phases. AD CS is a Windows Server role that the organization operates, not a native PQ key type in Azure Key Vault.
For TLS, current Windows and .NET components can negotiate hybrid ML-KEM where the client, server, and configuration support it. That makes Azure VMs and application platforms viable pilot environments. It does not establish that Azure Front Door, Application Gateway, Storage, SQL, or every other managed endpoint has enabled the same groups.
Azure is currently the strongest fit when a team wants application-controlled PQC on the Microsoft platform or operates AD CS. Teams that require a managed cloud KMS with PQ asymmetric keys need to wait for a documented Key Vault capability or evaluate a different architecture.
See the detailed Azure post-quantum support guide.
Workflow-by-workflow decisions
Long-lived code or firmware signatures
AWS KMS is the clearest managed HSM-backed choice, with GA ML-DSA signing and an AWS Private CA integration for ML-DSA certificates. Google Cloud KMS also provides GA ML-DSA signing and adds SLH-DSA algorithm diversity. Azure applications can sign with GA platform APIs, but Azure Key Vault does not provide an equivalent PQ key type.
Pilot verifier compatibility before changing a root of trust. A signer being available does not mean bootloaders, package managers, HSM clients, certificate parsers, or customer verification systems accept ML-DSA.
KEM and application key establishment
Google Cloud is the only provider here exposing customer KEM keys and decapsulation through its managed KMS, and that feature is Preview. AWS hybrid TLS uses ML-KEM but does not expose the same KMS workflow. Azure offers ML-KEM through platform APIs rather than Key Vault.
Use the hybrid cryptography guide to separate a hybrid transport protocol from a standalone KEM API.
Importing externally generated key material
Google Cloud has the only documented quantum-safe import transport among these three. A pilot can use X-Wing or ML-KEM HPKE methods, but only for software-backed targets. AWS KMS and Azure Key Vault support other import mechanisms, but no directly comparable PQ-protected import method was found in the reviewed primary documentation.
Before any pilot, record protection level, origin, ownership, import method, expiry, and recovery requirements in a cryptographic inventory.
Hybrid TLS migration
AWS offers the most explicit service-by-service documentation, including default support on CloudFront and opt-in policies for ALB and NLB. Google has substantial internal and browser deployment, but customer service support varies. Azure provides capable platform components, while managed endpoints require individual verification.
TLS migration remains a client and server compatibility project. Track negotiated groups, fallback behavior, middlebox failures, connection reuse, and SDK/runtime versions.
What to pilot now
- Inventory first. Identify signatures, key exchange, import workflows, TLS endpoints, protection levels, and certificate dependencies.
- Choose one workflow. Do not start with a provider-wide “enable PQC” objective.
- Use GA for production candidates. AWS KMS ML-DSA, Google Cloud KMS PQ signatures, and Microsoft platform APIs can be evaluated against production requirements.
- Keep Preview isolated. Google KEM/import and AWS CloudHSM ML-DSA should remain controlled evaluations until their service status changes and your risk process accepts the terms.
- Measure compatibility. Validate every signer, verifier, SDK, TLS client, certificate parser, and recovery path.
- Document residual classical dependencies. PQ TLS still commonly uses classical authentication, and PQ signatures do not protect classical key exchange.
Use the post-quantum migration checklist and SaaS migration timeline to place these pilots in a wider program. The vendor support matrix tracks adjacent vendors and technologies.
Frequently asked questions
Which cloud provider has the best PQC support?
There is no defensible overall winner. AWS has strong HSM-backed ML-DSA, private PKI, and broad documented TLS support. Google Cloud has GA ML-DSA and SLH-DSA plus Preview KEM and quantum-safe import workflows. Microsoft has GA platform APIs and AD CS support, but Azure Key Vault lacks PQ asymmetric key types.
Can I use ML-KEM as a key in cloud KMS today?
Google Cloud KMS exposes ML-KEM-768 and ML-KEM-1024 KEM keys in Preview. AWS uses ML-KEM for hybrid TLS but does not document an equivalent KMS KEM-key operation. Azure exposes ML-KEM through platform APIs, not Key Vault.
Can I store PQ keys in an HSM?
AWS KMS stores and operates ML-DSA keys in validated HSMs, and AWS CloudHSM offers ML-DSA in Preview. Azure Managed HSM does not document PQ asymmetric key types. Google Cloud’s quantum-safe import Preview cannot target Cloud HSM, although other Cloud KMS PQ operations must be checked against their own protection-level documentation.
Which provider supports quantum-safe key import?
Google Cloud documents Preview HPKE import methods using X-Wing, ML-KEM-768, or ML-KEM-1024. The target must be software-backed. No directly comparable PQ import transport was found for AWS KMS or Azure Key Vault.
Does hybrid PQ TLS make a cloud workload quantum-safe?
No. It protects session key establishment for the specific connection that negotiates it. Certificate authentication, application signatures, stored keys, third-party connections, and unsupported endpoints can remain classical.
Primary sources
AWS
- AWS migration to post-quantum cryptography
- AWS KMS ML-DSA keys
- AWS hybrid post-quantum TLS SDK guidance
- AWS Private CA supported algorithms
- AWS CloudFront post-quantum TLS launch
- AWS ALB and NLB post-quantum TLS launch
Google Cloud
- Google Cloud KMS release notes
- Google Cloud quantum-safe key import
- Google Cloud KEM documentation
- Google Cloud digital signature documentation