AWS Pulled Ahead on Post-Quantum Crypto in 2026: Azure and GCP Are Still Catching Up

Run the same cryptographic-readiness audit against AWS, Azure, and Google Cloud in 2026 and you can still get three materially different answers.

I do not mean three different console labels for essentially the same control. I mean different answers to questions that matter during an audit: Can I establish a NIST-standardized post-quantum shared secret? Can the cloud KMS create an ML-DSA signing key? Is that operation inside a validated HSM? Is post-quantum TLS merely available, or is it enabled automatically in the client path my application actually uses?

AWS currently gives the cleanest operational answer across several of those layers. Azure's managed HSM documentation, meanwhile, still lists RSA, elliptic-curve, and AES keys rather than ML-KEM or ML-DSA, even though Microsoft has added post-quantum capabilities elsewhere in the Windows platform. Google Cloud has changed faster than an earlier 2026 snapshot suggested: by August, Cloud KMS documentation lists ML-KEM, ML-DSA, and SLH-DSA, making GCP substantially more ready than “sparse documentation” would imply.

That unevenness is why post-quantum cryptography cloud security 2026 is an engineering problem rather than a future-computing thought experiment. NIST's first PQC standards have been final for two years, an NSA networking milestone lands in 2026, federal cryptographic-module validation has a concrete September transition date, and National Security System procurement faces a January 2027 milestone close enough to affect architecture decisions being made now.

For engineers building the broader cloud foundation behind those decisions, the Refonte Learning Cloud Security Engineer Program covers data encryption, IAM, cloud compliance, monitoring, and security tooling across AWS, Azure, and Google Cloud. Its published curriculum does not currently claim to teach ML-KEM, ML-DSA, CNSA 2.0, or PQC migration specifically, so this guide should be read as a deeper cryptographic-migration layer built on top of those fundamentals.

Three Clouds, Three Different Answers to the Same Audit

The mistake I see in multi-cloud audits is asking a question that is too broad: “Does this cloud support post-quantum cryptography?” A provider can answer yes because one TLS library negotiates a hybrid KEM while its HSM cannot create the PQ signing key your control requires.

The useful audit question decomposes the capability into algorithm, operation, service, protocol, protection boundary, validation status, and deployment default. When I normalize the three providers that way, the readiness gap becomes much easier to defend in an audit report.

That table is why I would currently call AWS the operational leader, but I would not describe GCP as simply “behind” in KMS algorithm availability anymore. Google has moved significantly during 2026, while Azure's biggest visible gap is specifically native ML-KEM and ML-DSA support in the Managed HSM algorithm set, not an absence of PQC work across Microsoft as a whole.

For a serious AWS Azure GCP post-quantum readiness review, that distinction matters. “Provider supports PQC” is not a control result; “this production cryptographic operation uses this standardized algorithm inside this validated boundary with this negotiated protocol and fallback behavior” is.

What NIST Actually Standardized in 2024 (and Why 2026 Matters Now)

On August 13, 2024, NIST finalized the first three Federal Information Processing Standards from its post-quantum cryptography program. They are no longer draft algorithms waiting for a standards decision; they are finalized standards that vendors can build against.

This is the core of the NIST PQC standards ML-KEM ML-DSA conversation. ML-KEM is not a drop-in “encrypt my 20-terabyte data lake with post-quantum crypto” algorithm, and ML-DSA is not a VPN cipher; they solve different asymmetric-cryptography problems.

That also explains why a blanket instruction to “replace AES with PQC” is technically wrong. NSA's CNSA 2.0 suite retains AES-256, and both AWS and Google describe 256-bit symmetric encryption as suitable for the quantum-resistance problem they are addressing; the urgent asymmetric problem is RSA- and ECC-based key establishment and signatures that sufficiently capable quantum computers could attack.

For National Security Systems, NSA's December 2024 CNSA 2.0 FAQ specifies ML-KEM-1024 for key establishment and ML-DSA-87 for signatures, alongside AES-256, SHA-384, and SHA-512. That is more specific than saying “use ML-KEM somewhere”: CNSA 2.0 chooses particular parameter sets for its mission and classification requirements.

Why does 2026 matter? Because the standards phase is over and the integration phase is visible in production cloud services, validation programs, acquisition planning, VPN and network modernization and government capability packages.

The Deadlines That Are Real in 2026

This is where timeline discipline matters most. Not every date circulating in a CNSA 2.0 timeline is a 2026 deadline, and not every cryptographic deadline in 2026 is technically a PQC mandate.

The primary-source picture looks like this:

There is an important correction to make to some secondary compliance summaries: “PKI has a 2026 CNSA deadline” is too broad. NSA's older category roadmap put “niche equipment,” explicitly including constrained devices and large PKI, on a later support or prefer trajectory, while software and firmware signing and certificate modernization begin earlier.

Data-at-rest also needs careful wording. The March 2026 DAR package proves that NSA's CNSA 2.0 transition is active now, but it does not mean every AES-256-encrypted disk suddenly needs conversion to ML-KEM; ML-KEM is a key-establishment mechanism, while AES-256 remains part of CNSA 2.0.

The September 21, 2026 FIPS 140-2 Sunset, Explained

September 21 is useful as an audit anchor because it is concrete, but I would never label it “the PQC deadline.” It belongs to NIST's Cryptographic Module Validation Program transition from FIPS 140-2 to FIPS 140-3.

NIST states that FIPS 140-2 active modules can be used for new systems through September 21, 2026. After that date, the remaining FIPS 140-2 validation certificates move to the Historical list; NIST's FAQ frames September 22 as the point at which only FIPS 140-3 validations remain active.

Three audit consequences follow:

•       Inventory modules by validation certificate and version, not merely by product brand. A cloud service saying “HSM-backed” does not tell you which validated module boundary your requirement depends on.

•       Do not equate “Historical” with “the module stops functioning.” NIST explains that Historical modules can continue to be used in existing deployments depending on applicable agency and procurement rules.

•       Use the transition to eliminate cryptographic technical debt while you are already reviewing keys, certificates, VPN endpoints and HSM dependencies for PQC.

That makes the FIPS 140-2 Historical status milestone operationally adjacent to PQC migration without pretending they are the same regulatory event.

The Deadlines That Are NOT Urgent Yet (and Why That Matters)

Urgency inflation is bad security engineering. When every 2030 or 2035 requirement is presented as though enforcement arrives next quarter, teams stop distinguishing between what needs a budget decision now and what needs a long-range architecture capability.

NSA has also updated and clarified its guidance since the original 2022 category chart, so you should preserve the source date in any compliance matrix.

This explains why you may see both “2033” and “2031” in otherwise reputable discussions. The 2033 dates come from category-specific milestones in NSA's September 2022 advisory; the later December 2024 FAQ, written ahead of updated CNSS Policy 15, provides a newer high-level transition framework including the 2030 phase-out and 2031 algorithm mandate.

My audit rule is simple: never flatten those documents into one unlabeled timeline. Store the source, publication version, system category and exact requirement with every deadline.

The near-term date I would take into a 2026 architecture review is January 1, 2027 for new NSS acquisitions. That is not a 2026 deadline, but a system entering procurement, authority-to-operate work or contract negotiation in August 2026 cannot sensibly wait until New Year's Eve to discover that a required crypto component does not support CNSA 2.0.

Several deadline formulations circulating in compliance-industry material are secondary interpretations. Before relying on any such date for a contract or audit, cross-check it against current primary policy from NSA, CNSS, NIST or the controlling agency.

Why "Harvest Now, Decrypt Later" Makes This Different From Past Migrations

The harvest now, decrypt later risk model changes how I prioritize data because an attacker does not need a cryptographically relevant quantum computer today. The model assumes an adversary can capture ciphertext now, retain it, and attempt to decrypt it later when cryptanalytic capabilities improve.

Google's current Cloud KMS documentation describes precisely this general threat model when discussing RSA-based asymmetric encryption, and AWS's PQC migration material similarly emphasizes protecting long-lived confidentiality over untrusted networks.

I would not attach a supposed “2026 harvest-now-decrypt-later incident rate” to that statement. No such statistic is needed to justify the engineering model, and no independently verified 2026 incident is cited here.

The assets I rank highest are therefore not simply “the databases with the highest CVSS-adjacent risk score.” They include information whose confidentiality life can exceed the useful life of today's public-key protection.

•        Long-retention government, research, health, financial or intellectual-property data moving over untrusted links deserves early attention.

•      Backups and archival workflows matter because retention periods can outlive today's protocol choices.

•       TLS, VPN and other session-establishment mechanisms deserve scrutiny where classical public-key negotiation protects data that must remain confidential for many years.

•        AES-256 data-at-rest encryption should not automatically be re-encrypted under a PQ algorithm; both CNSA 2.0 and cloud-provider guidance retain strong symmetric cryptography.

This is why quantum-resistant encryption cloud programs should start with a data-lifetime map and cryptographic dependency map, not a purchase order for whatever product has “quantum safe” on its landing page.

AWS's Post-Quantum Rollout: What's Actually Live in 2026

AWS has been building toward this for years rather than treating NIST's 2024 finalization as the starting gun. Its published migration plan says AWS has worked on post-quantum capabilities across AWS-LC, s2n, KMS, Secrets Manager and ACM since 2019, and the provider is now translating that work into managed-service deployment.

The strongest AWS story in 2026 is not just algorithm availability. It is operational integration.

AWS's own migration plan prioritizes public-key cryptography used across untrusted networks and uses hybrid approaches during transition. It also explicitly warns against the simplistic idea that customers must re-encrypt all AES-256 data at rest merely because quantum computing is progressing.

That is the architecture pattern I want in a PQC migration 2026 program: deploy hybrid negotiation where interoperability allows it, keep the classical component during the transition, instrument fallback, and move away from quantum-vulnerable asymmetric dependencies without destabilizing every workload at once.

I am deliberately not extending the AWS finding into a blanket statement that every AWS CloudHSM operation supports FIPS 203, 204 and 205. The strongest primary documentation found in this review establishes ML-DSA inside AWS KMS's FIPS 140-3 Level 3 HSM boundary; that is the claim I would put in an evidence-backed audit.

Secrets Manager, Lambda, and CSI Driver Support Explained

The April 2026 change is especially interesting because it moves PQC from “the endpoint can negotiate it” toward “normal application traffic can use it without every team becoming a cryptography integration project.”

AWS's April 2026 Secrets Manager client announcement states that ML-KEM support is automatically enabled for:

•        Secrets Manager Agent version 2.0.0 and later.

•       AWS Parameters and Secrets Lambda Extension version 19 and later.

•       Secrets Store CSI Driver AWS Provider version 2.0.0 and later.

That version detail belongs in the audit. A provider roadmap saying “Secrets Manager supports PQC” does not prove that a Kubernetes cluster pinned to an old CSI provider, or a Lambda application using an older extension, is actually negotiating the new path.

I therefore collect client component and version alongside the cloud service. It is one of the simplest ways to prevent a false-positive readiness result.

Where Azure Stands on Native PQC Support

Azure is the clearest example of why “Microsoft supports PQC” and “my Azure HSM requirement is satisfied” are two different statements.

Microsoft's Windows platform has been adding ML-KEM, ML-DSA and post-quantum and hybrid cryptographic capabilities, and the July 2026 Secure Future Initiative update says Microsoft's quantum-safe PKI program has advanced to a defined transition approach with validated scope and phased implementation planning.

But the current Azure Managed HSM documentation tells a narrower story.

So if an audit requirement says, “Generate and use an ML-DSA private key inside Azure's native managed HSM service,” I would currently record a gap based on the published algorithm table. If the requirement instead says, “Use quantum-resistant AES-256 for native HSM-protected data encryption,” Azure has a documented answer.

This finding has high confidence for the documentation checked, not permanent confidence about Azure's roadmap. Cloud-provider cryptographic services change quickly; the right audit practice is to date-stamp the finding and re-check Microsoft Learn before a procurement or compliance decision.

Where Google Cloud Stands: Its Documentation Has Caught Up

As of August 18, 2026, Google Cloud's public PQC documentation is no longer as thin as it appeared earlier in the migration.

Google Cloud KMS now documents a substantial algorithm set.

Google announced general availability of quantum-safe ML-DSA and SLH-DSA signatures and ML-KEM-related Cloud KMS capabilities during the 2026 rollout, after preview releases in 2025.

That means the AWS-versus-GCP comparison has become more nuanced. AWS still has the stronger story around broad service integration, client defaults and an explicit ML-DSA protection within a FIPS 140-3 Level 3 KMS boundary, but Google Cloud KMS is no longer sitting on the sidelines of standardized PQC.

One area deserves additional due diligence. Google's protection-level documentation currently describes Cloud HSM hardware as FIPS 140-2 Level 3, while Google's quantum-safe roadmap separately points toward a “Quantum-Safe Cloud HSM (FIPS 140-3 L3)” milestone in 2028; at the same time, its algorithm page says all key purposes are supported at HSM protection level.

I would treat that as a certification-boundary question to verify, not as evidence that ML-KEM cannot run with HSM protection. For a control that explicitly requires a particular FIPS 140-3 validated hardware boundary for PQ operations, inspect the applicable CMVP certificate and obtain provider confirmation rather than inferring compliance from a generic KMS feature table.

What Sparse Documentation Signals About Priority

Earlier in a technology transition, sparse documentation is a useful warning signal: if I cannot find algorithm identifiers, protocol negotiation behavior, HSM boundaries, version requirements or fallback rules, I cannot write a high-confidence audit finding.

But that signal is time-sensitive. Google Cloud KMS release notes show enough change during 2026 that an assessment based on a mid-2025 or early-2026 snapshot can now produce an outdated “GCP doesn't support PQ KMS” conclusion.

The operational lesson is:

•        Keep cloud-provider PQC capability data under change control rather than in a once-a-year spreadsheet.

•        Record the documentation last-updated date with every capability.

•        Separate preview from general availability.

•        Separate algorithm availability from FIPS or CNSA qualification.

•        Re-run evidence collection before signing a compliance assertion.

For assessments conducted after August 2026, re-check all three providers because Azure, AWS and Google will keep moving.

What This Readiness Gap Means for a Multi-Cloud Security Audit

A conventional cloud-security audit often normalizes controls at a high level: encryption enabled, key rotation enabled, customer-managed key configured, public endpoint restricted. PQC exposes how insufficient that abstraction can be.

For this migration, I normalize the cryptographic function, then test each provider's implementation separately.

The resulting finding may legitimately differ by provider. “AWS workload passes, Azure workload has an HSM algorithm gap, GCP workload passes technically but needs module-validation confirmation” is a better audit result than forcing all three into one green checkbox.

PQC should also stay distinct from your posture-management layer. CNAPP products answer adjacent questions about exposed workloads, identities, vulnerabilities, data and configuration; Refonte Learning's existing article on cloud security platforms and CNAPP tools covers that platform layer separately.

For a multi-cloud team, I would make the PQC matrix a dedicated control domain that feeds governance and architecture systems rather than trying to squeeze algorithm migration into a generic “encryption enabled” CNAPP policy.

Auditing Your Own Environment for PQC Readiness

Start with inventory, not replacement. Until you know where RSA, elliptic-curve cryptography, TLS negotiation, certificates, code signatures and HSM keys are actually used, a PQC project is mostly presentation slides.

My first-pass audit looks like this:

•        Inventory cryptography: certificate authorities, server and client certificates, KMS keys, HSM keys, SSH dependencies, code-signing keys, VPN configurations, TLS terminators, service meshes and external key managers.

•        Inventory long-lived information: identify data whose confidentiality requirement extends for years and map the network paths over which it moves.

•        Map provider-managed dependencies: determine where AWS, Azure or GCP chooses algorithms on your behalf rather than where you configure them directly.

•        Record validation boundaries: map FIPS 140-2 and FIPS 140-3 certificate dependencies and investigate anything affected by the September 2026 transition.

•        Test rather than assume: capture TLS and key-exchange negotiation, exercise KMS signing and verification or encapsulation and decapsulation APIs, and test failure and fallback behavior.

A useful readiness score should not be a single percentage. I prefer separate dimensions for discovery coverage, cryptographic agility, provider capability, protocol support, HSM and validation compliance, migration testing and operational monitoring.

The first artifact I want at the end is not a purchase request. It is a cryptographic bill of materials detailed enough that a future algorithm change can be answered through data rather than another six-week manual discovery exercise.

Where to Start If You Manage Multiple Clouds

For AWS, Azure and GCP together, create one canonical schema and populate it with provider-specific evidence.

A practical starting matrix is:

Then automate drift detection around that schema. Provider release notes, SDK upgrades and validation-certificate changes should trigger a review because PQC readiness is now a moving configuration property, not a one-time architecture attribute.

What CNSA 2.0 Compliance Actually Requires by Category

First, a scope warning: CNSA 2.0 is NSA guidance for protecting National Security Systems and related national-security information. It is influential beyond that community, but a normal commercial SaaS company should not say it is legally “required to comply with CNSA 2.0” unless a contract, agency requirement or other governing obligation actually makes that true.

At the algorithm level, NSA's newer FAQ identifies the CNSA 2.0 suite around AES-256, ML-KEM-1024, ML-DSA-87, SHA-384, SHA-512, and limited LMS or XMSS uses for particular signing scenarios.

At the deployment level, category matters.

The newer December 2024 NSA FAQ provides a second layer of policy timing: new NSS acquisitions should be CNSA 2.0 compliant beginning January 1, 2027 unless otherwise noted; unsupported equipment and services should be phased out by December 31, 2030; CNSA 2.0 algorithms become mandated by December 31, 2031 unless otherwise noted; and NSA's overall objective remains quantum-resistant NSS by 2035.

For a 2026 engineer, the actionable interpretation is therefore:

•        VPN and network support is genuinely a current category concern under the original roadmap.

•        Data-at-rest CNSA transition is demonstrably active in NSA's March 2026 CSfC material.

•        Software and firmware signing should already be a migration workstream, not something postponed until 2030.

•        Large PKI should not be falsely described as having a universal 2026 deadline.

•       January 2027 acquisition compliance is the near-term planning trigger, while 2030, 2031, 2033 and 2035 remain later milestones.

That distinction is more useful than turning the entire timeline red.

Building a Migration Plan That Doesn't Wait for a Forced Deadline

A strong migration program does not start by converting every key. It starts by creating crypto agility so that the organization can change algorithms, key sizes, certificates and protocol groups without rewriting every application.

I normally break the program into four tracks.

Hybrid deployment is particularly useful while standards and ecosystems coexist. AWS's migration plan uses hybrid key establishment as part of its transition strategy, and Google Cloud recommends a hybrid KEM option in its current Cloud KMS documentation.

Do not ignore performance engineering. PQ signatures, certificates and key-exchange artifacts can have different sizes and computational costs from the RSA and ECC constructions your gateways, embedded clients, MTU assumptions, certificate parsers and signing pipelines were designed around.

The migration backlog should also carry two dates: cryptographic deadline and application retirement date. There is little value spending a year retrofitting a system scheduled for decommissioning before the relevant exclusive-use milestone, but there is substantial value preventing a new 10-year platform from hard-coding RSA-only assumptions in 2026.

Prioritizing Data-at-Rest, PKI, and VPN First

These categories need different treatment rather than one “encrypt with PQC” project.

Data at rest: preserve strong AES-256 where it meets your requirement, then examine the keys, wrapping mechanisms, administrative interfaces, HSM validation and long-term protection architecture around it. CNSA 2.0 retains AES-256, and NSA's 2026 DAR package shows the transition being introduced around the broader cryptographic ecosystem rather than replacing symmetric encryption with ML-KEM.

PKI and signing: inventory root and intermediate CAs, certificate profiles, code-signing keys, firmware verification, certificate consumers and signature-size constraints. ML-DSA is the NIST-standardized signature primitive relevant to this work; AWS KMS already offers ML-DSA, Google Cloud KMS now lists ML-DSA and SLH-DSA, while Azure Managed HSM currently does not list ML-DSA in its supported algorithms.

VPN and transport: prioritize flows carrying information with long confidentiality requirements and test hybrid key establishment end to end. The NSA 2022 roadmap explicitly gave traditional NSS networking equipment a support or prefer milestone in 2026.

My immediate migration queue would therefore be:

•        Long-lived sensitive traffic still dependent on classical-only asymmetric key exchange.

•        New systems expected to remain in service through the 2030s.

•        Code, firmware and certificate trust chains with long verification lifetimes.

•        VPN and networking systems affected by the current CNSA transition.

•        FIPS 140-2-dependent components whose active validation status matters to new deployments after September 21, 2026.

•        Cloud workloads where a provider already supplies an easy hybrid or PQ path but the organization has not upgraded the required client or runtime.

That sequence turns post-quantum migration into ordinary risk engineering: prioritize by exposure, data life, system life, regulatory scope and replacement cost.

Cloud Security Engineer Salaries in 2026

PQC does not justify inventing a salary premium, and I found no evidence that employers pay a fixed additional amount specifically for ML-KEM or CNSA 2.0 expertise. What we can document is that U.S. cloud security engineering compensation remains high, while major salary aggregators disagree noticeably on the exact number.

The meaningful point in cloud security engineer salary 2026 data is the gap between sources, not whichever number makes a better headline. ZipRecruiter derives estimates from job postings and third-party data, while Glassdoor uses submitted compensation data and its modeling approach, so differences in sample, job-title normalization, base versus total compensation and update timing can move the result.

For career planning, I would treat roughly $153,000 versus $169,000 as evidence of a broad market range rather than a contradiction that needs to be “resolved.” Senior compensation can run higher, but location, experience, industry, clearance requirements, cloud specialization and total-compensation structure matter more than a national average.

The career value of PQC knowledge is less about memorizing three algorithm names and more about being able to translate standards into a real multi-cloud migration: inventorying cryptography, interpreting validation boundaries, reading provider documentation critically, testing protocol negotiation, and giving an auditor a defensible answer.

Building This Expertise: The Refonte Learning Cloud Security Engineer Program

Post-quantum migration sits on top of core cloud-security skills: encryption, architecture, IAM, governance, monitoring, incident response and the ability to move between providers without assuming equivalent controls.

Refonte Learning's live Cloud Security Engineer program provides that broader foundation.

There is an accuracy boundary worth preserving here. The curriculum says “Data Encryption Techniques”, but the live program page does not currently name post-quantum cryptography, FIPS 203, ML-KEM, ML-DSA or CNSA 2.0.

So the credible reason to consider the Refonte Learning Cloud Security Engineer Program is not a claim that it already provides a dedicated PQC-migration module. It is that a cloud engineer needs the underlying architecture, encryption, compliance, IAM and multi-cloud tooling foundation before the more specialized work in this guide becomes operationally useful.

That distinction mirrors the broader lesson of post-quantum cryptography cloud security 2026. The hard part is no longer knowing that quantum-resistant algorithms exist; NIST standardized the first set in 2024. The hard part is determining where they can be used today, under which validated boundary, through which client version, with what fallback, against which compliance date, and without confusing an old provider capability snapshot with the state of the cloud this month.

In August 2026, AWS has the most mature end-to-end operational rollout among the three providers reviewed here, particularly where managed-service integration, default client adoption and explicit FIPS 140-3 Level 3 ML-DSA protection are concerned. Google Cloud has closed far more of the KMS algorithm gap than earlier 2026 documentation snapshots suggested, while Azure's native Managed HSM remains the clearest constraint for teams requiring ML-KEM or ML-DSA operations inside that specific managed hardware service.

The deadline discipline is equally important. September 21, 2026 is a real FIPS module-validation transition date; traditional NSS networking has a real 2026 CNSA transition milestone; NSA's 2026 data-at-rest materials show migration already underway; and January 1, 2027 creates immediate acquisition pressure.

But 2030, 2031, 2033 and 2035 are still later milestones. A senior cloud security engineer's job is not to make them sound closer. It is to make sure the systems being designed in 2026 will not become the legacy cryptography problem everyone is scrambling to replace when those dates finally arrive.