PQC for Cloud Environments: Shared Responsibility Across AWS, Azure, and Google Cloud

Quick answer: Cloud shared responsibility for post-quantum cryptography splits cleanly along a familiar line, but the specifics vary sharply by provider and service. AWS has published the clearest operational picture: AWS KMS, ACM, and Secrets Manager already support ML-KEM hybrid key agreement on non-FIPS endpoints, symmetric encryption at rest (like AWS KMS default encryption) is already quantum-resistant, and updating customer-owned resources like load balancers to a PQ-enabled TLS policy is explicitly the customer’s responsibility under AWS’s shared responsibility model. Azure and Google Cloud are each moving on their own timelines and are not uniformly at the same point of readiness across every service. The practical task for any multi-cloud customer is auditing each provider separately, service by service, rather than asking a single yes-or-no “does this cloud support PQC” question that no provider can honestly answer with one word.

Cloud providers are migrating fast, and it is genuinely tempting to assume that migration covers your workloads automatically. It does not, uniformly. This guide breaks down what each major provider migrates on your behalf, what stays your responsibility, and how to audit the gap accurately rather than by assumption.

Key Takeaways

• AWS KMS, ACM, and Secrets Manager already support ML-KEM hybrid post-quantum key agreement on non-FIPS endpoints across all AWS Regions in the standard partition.
• Updating customer-owned network resources, like load balancers, to a PQ-enabled TLS policy is explicitly on the customer side of AWS’s shared responsibility model, not something AWS does automatically.
• Symmetric encryption at rest, including AWS KMS default key encryption, is already considered quantum-resistant and requires no migration on its own.
• Provider readiness is not uniform across services within the same cloud, let alone across providers; a general “is PQC supported” question does not surface the service-by-service gaps that matter during an audit.
• A useful cross-cloud PQC readiness audit tests actual negotiation and API behavior, hybrid key exchange, KMS signing key creation, HSM validation boundary, rather than relying on marketing claims of general support.

AWS: What’s Migrated vs. What’s Your Responsibility

AWS has published the most operationally specific PQC migration guidance of the major providers. As of this guide’s publication, AWS KMS, AWS Certificate Manager, and AWS Secrets Manager endpoints support ML-KEM for hybrid post-quantum key agreement on non-FIPS endpoints across all AWS Regions in the standard aws partition, a capability AWS delivers transparently, requiring no customer action to benefit from it on those specific endpoints. Symmetric algorithms used for encryption at rest, including standard AWS KMS key encryption, are already considered quantum-resistant and do not need migration on their own merits.

What remains customer responsibility is explicit in AWS’s own guidance: updating customer-owned network resources, such as load balancers, to a PQ-enabled TLS policy is on the customer’s side of the shared responsibility model. AWS provides updated TLS policies that support ML-KEM hybrid key exchange, and IAM resource control policies to enforce a desired TLS policy on future resource creation, but applying that policy to existing resources is a customer action, not an automatic AWS-side change. AWS Private CA and AWS KMS together support post-quantum capabilities for certificate and key infrastructure, again as tools the customer configures rather than a default that applies without action.

Azure and Google Cloud: Different Timelines, Not Absent

Azure and Google Cloud are each investing in post-quantum readiness, but not uniformly at the same point as AWS across every service category as of 2026. Independent cross-cloud audits have found Azure’s managed HSM documentation, for example, still centered on RSA, elliptic-curve, and AES key types rather than ML-KEM or ML-DSA, even while Microsoft has shipped post-quantum capability elsewhere in the Windows platform, including ML-DSA support in Active Directory Certificate Services. This is a service-specific gap, not a statement about Azure’s overall PQC posture, which is why service-by-service verification matters more than a single provider-level judgment.

Google Cloud has published its own detailed PQC roadmap covering confidentiality migration, signature integrity, and service-by-service milestones; we cover that roadmap and its specific implications for enterprise customers in a dedicated guide, since it deserves its own detailed treatment rather than a summary here.

The Audit Questions That Actually Matter

“Does this cloud support post-quantum cryptography” is too broad a question to audit against, since a provider can honestly answer yes because one TLS library somewhere in the stack negotiates a hybrid KEM while an entirely different service in the same cloud still only issues classical keys. The questions that actually surface real gaps during an audit are more specific:

• Can I establish a NIST-standardized post-quantum shared secret on this specific service’s TLS endpoint?
• Can the cloud KMS create an ML-DSA signing key, and is that key generation and signing operation performed inside a validated HSM?
• Is post-quantum TLS merely available as an option, or is it negotiated automatically in the client path my application actually uses in production?
• What FIPS 140-2 or FIPS 140-3 certificate dependencies does this specific service carry, and how is the September 2026 FIPS 140-2 sunset affecting it?

Test rather than assume: capture the actual TLS handshake and key-exchange negotiation for services you depend on, exercise KMS signing, verification, encapsulation, and decapsulation APIs directly, and test fallback behavior when a post-quantum negotiation is not available, rather than relying on a provider’s general marketing claim of PQC support.

Building Your Shared Responsibility Inventory

A complete cloud PQC inventory covers more than TLS: certificate authorities, server and client certificates, KMS and HSM keys, SSH dependencies, code-signing keys, VPN configurations, TLS terminators, service meshes, and any external key managers layered on top of the cloud’s own. For each item, map which side of the shared responsibility line it actually falls on, which the cloud provider migrates by default, which requires a customer-side configuration change, and which depends on a provider capability that has not shipped yet. Long-lived, sensitive data also needs its own tracking layer, independent of infrastructure category, since data with a multi-year confidentiality requirement carries harvest-now-decrypt-later exposure regardless of which cloud service currently stores or transmits it.

What We’d Actually Recommend

Audit each cloud provider you use separately and at the service level, not as a single organization-wide “are we cloud-PQC-ready” checkbox. Apply AWS’s already-available hybrid TLS policies to your customer-owned resources now rather than assuming AWS’s own service-side progress covers them automatically. Track Azure and Google Cloud service-by-service readiness on their own timelines rather than assuming feature parity with AWS, and build your inventory to distinguish provider-managed dependencies from customer-configured ones explicitly, since that distinction is what a real shared-responsibility audit actually turns on.

How Encryption Consulting Can Help

The service-by-service inventory this guide argues for, distinguishing what each cloud provider migrates automatically from what remains your configuration responsibility, is exactly what CBOM Secure is built to produce across multi-cloud and hybrid environments, mapping certificates, keys, and TLS configurations to their provider-managed or customer-managed status.

Our PQC Advisory Services run the audit questions this guide outlines against your actual cloud footprint, testing real TLS negotiation and KMS API behavior rather than relying on provider marketing claims, and build the resulting gaps into a prioritized, customer-side remediation plan. Where certificate issuance spans multiple cloud providers, CertSecure Manager manages classical, hybrid, and post-quantum certificates from a single policy plane across AWS, Azure, and Google Cloud.

Verify the Line, Don’t Assume It

Cloud providers are moving on post-quantum cryptography, and AWS in particular has published a genuinely clear operational picture of what it migrates automatically versus what it leaves to customer configuration. That clarity does not extend evenly across every provider and every service, which is exactly why “does my cloud support PQC” is the wrong question. The right one is service-specific and testable: does this exact endpoint negotiate a validated hybrid key exchange today, in the client path my application actually uses, and who is responsible for turning it on.

Frequently Asked Questions

Does AWS automatically enable post-quantum TLS on my resources?

Not uniformly. AWS delivers ML-KEM hybrid support transparently on AWS KMS, ACM, and Secrets Manager endpoints, but updating customer-owned resources like load balancers to a PQ-enabled TLS policy is explicitly on the customer’s side of the shared responsibility model.

Do I need to migrate data encrypted with AWS KMS’s default symmetric encryption?

No. Symmetric encryption algorithms used for encryption at rest are already considered quantum-resistant and do not require a post-quantum migration on their own.

Is Azure behind AWS on post-quantum cryptography?

It varies by service. Independent audits have found gaps in specific areas, such as Azure managed HSM key type support, while Microsoft has shipped post-quantum capability elsewhere, including ML-DSA support in Active Directory Certificate Services. Verify readiness service by service rather than judging a provider’s overall posture from one service.

What is the best way to test whether a cloud service actually supports post-quantum key exchange?

Capture the actual TLS handshake for the specific endpoint using a tool like Wireshark or your browser’s built-in developer tools, rather than relying on a provider’s general marketing claim. For KMS services, directly exercise the signing, verification, encapsulation, or decapsulation API to confirm post-quantum algorithm support rather than assuming from documentation alone.

What should a multi-cloud PQC inventory include?

Certificate authorities, server and client certificates, KMS and HSM keys, SSH dependencies, code-signing keys, VPN configurations, TLS terminators, and service meshes, each mapped to whether it is provider-managed, customer-configured, or dependent on a capability that has not yet shipped.