The Post-Quantum Migration

The post-quantum migration is the replacement of today's public-key cryptography — RSA and elliptic-curve algorithms, which a sufficiently capable quantum computer could break — with quantum-resistant algorithms across every system that encrypts, signs, or authenticates. It is the largest scheduled infrastructure replacement in the history of the security industry: every certificate, key exchange, code-signing chain, and machine identity in the installed base is in scope. Since mid-2026 it has also become a regulated obligation with hard federal deadlines, which moved it from a research topic to a funded demand engine and a distinct capital-formation lane.

Why the migration exists

Two facts drive the timetable. First, NIST finalized the first post-quantum cryptography standards in August 2024 (FIPS 203, 204, and 205 — the ML-KEM key-encapsulation and ML-DSA/SLH-DSA signature algorithms), so replacement algorithms exist and are standardized; the open question is deployment, not mathematics. Second, the threat is retroactive: adversaries can harvest encrypted traffic today and decrypt it once quantum capability arrives ("harvest now, decrypt later"), which makes long-lived secrets — government communications, health records, financial data, intellectual property — exposed years before any quantum computer runs. Estimates of "Q-Day," the point at which quantum machines can break current encryption, remain estimates; reporting around recent funding in the segment cites a hardening consensus that it could arrive as soon as 2029 (FinTech Global, Jul 10 2026), while government planning horizons run to 2030–2035.

The regulatory timeline

The migration is now scheduled by three overlapping public timetables — US federal, EU, and the browser/CA ecosystem. Parallel national and sectoral guidance, set out in the section that follows, adds a further set of dates, several of which fall earlier than the US deadlines.

Date Milestone Source of obligation
Aug 2024 NIST finalizes FIPS 203/204/205 — the standardized PQC algorithms NIST
Jun 23, 2025 EU coordinated implementation roadmap published (NIS Cooperation Group): national transition strategies under way by end-2026; high-risk use cases migrated no later than end-2030; as many systems as feasible by 2035 European Commission
Jun 22, 2026 EO 14412 — "Securing the Nation Against Advanced Cryptographic Attacks" signed, with OMB memo M-26-15: accelerates the US federal migration by roughly four to five years versus the prior NSM-10 2035 horizon White House · OMB M-26-15
Within 270 days of EO 14412 CISA + NIST publish minimum elements for a cryptographic bill of materials (CBOM) — a required inventory of every key, certificate, and cryptographic asset EO 14412
Dec 31, 2027 NIST completes a pilot migration of a subset of its own systems EO 14412
2029 Public-TLS certificate lifetimes reach 47 days under the CA/Browser Forum schedule, making manual certificate management impractical at enterprise scale CA/Browser Forum
Dec 31, 2030 US high-value assets and high-impact systems complete PQC migration for key establishment; covered federal contractors meet NIST FIPS including PQC under a forthcoming FAR rule (proposal due within 180 days of the EO) EO 14412 / FAR Council
Dec 31, 2031 US high-value assets and high-impact systems complete PQC migration for digital signatures EO 14412
2035 EU target for completing the transition across as many systems as practically feasible; original NSM-10 US horizon EU roadmap / NSM-10
2024NIST PQCstandards 2025EU coordinatedroadmap 2026EO 14412hard US deadlines;CBOM mandated 2027NIST pilotmigration 202947-day TLScertificates 2030–31US federal deadlineskeys (2030),signatures (2031) 2035EU completiontarget Standards (2024) → schedules (2025–26) → enforced deadlines (2030–31); orange = binding US federal dates

National and sectoral horizons

The table above records the timetables that set the US and EU outer boundaries. Vendors selling internationally face a wider set, and the operative date for a given product is usually the earliest one that applies to its customers rather than the headline 2035 figure. Published national guidance converges on 2030 for high-risk systems and 2035 for the remainder, with several jurisdictions setting earlier intermediate obligations.

Jurisdiction / sector Instrument Stated horizon
United States NIST IR 8547 (initial public draft) Deprecation of traditional asymmetric algorithms by 2030; disallowed after 2035
European Union European Commission recommendation on a coordinated implementation roadmap High-risk systems — those whose data must remain private for ten years — migrated by 2030; remainder by 2035
United Kingdom NCSC whitepaper on quantum-safe cryptography Cryptographic discovery complete by 2028; high-priority systems transitioned by 2031; migration complete by 2035
Germany BSI Technical Guideline TR-02102 Hybrid post-quantum cryptography recommended for all deployments; high-risk systems by 2030; no traditional asymmetric cryptography in use after 2031
France ANSSI position paper on post-quantum cryptography Products handling sensitive data quantum-resistant by 2027; all products on the market from 2030
Australia ASD, Planning for Post-Quantum Cryptography Migration complete, with no ongoing use of traditional asymmetric cryptography, by 2030; stronger parameters (ML-KEM 1024) recommended after 2030
Canada Canadian Centre for Cyber Security, ITSM.40.001 Departmental migration plans by April 2026; high-priority systems by end-2031; all remaining systems by end-2035
Financial services (G7) G7 Cyber Expert Group coordinated roadmap Critical financial systems to complete the transition by 2034

Two features of this set bear on the commercial picture. The earliest binding dates are not the American ones: France's 2027 obligation for products handling sensitive data and the United Kingdom's 2028 discovery milestone both fall before any deadline in EO 14412, so a vendor with European customers is on a shorter clock than the US schedule implies. And the German cut-off is a prohibition rather than a migration target — no traditional asymmetric cryptography in use after 2031 — which makes non-agile cryptography embedded in a product a dated liability in that market rather than a deferred one.

Sources: AWS — migration to quantum-resistant cryptography (regulatory summary) · Infosecurity Magazine — G7 sets 2034 deadline for finance (Jan 14, 2026)

Why it is a demand engine

The near-term spend is not on the algorithms themselves — those are standardized and largely free — but on three operational layers the deadlines force:

Discovery and inventory. No large organization knows every place it uses cryptography. The CBOM requirement in EO 14412 converts that ignorance into a compliance gap with a deliverable attached: agencies and covered contractors must produce an inventory of keys, certificates, algorithms, and cryptographic dependencies before they can migrate anything. Cryptographic discovery and posture management is therefore the first-funded lane.

Crypto-agility and lifecycle automation. Migrating means swapping algorithms across millions of certificates and machine identities, then doing it again as standards evolve. The CA/Browser Forum's shrinking public-TLS lifetimes (47 days by 2029) compound the same requirement from the browser side: certificate management at that cadence is only feasible as software. This is the machine-identity / certificate-lifecycle / PKI vendor lane — Keyfactor, Venafi (inside Palo Alto Networks via the CyberArk acquisition, completed Feb 2026), DigiCert, Entrust, AppViewX, SandboxAQ.

Certification as market gate. The FAR rule attached to EO 14412 uses the same mechanism as CMMC and FedRAMP (16d): compliance becomes a condition of selling to the government, which makes PQC readiness a non-discretionary purchase for the federal supply chain rather than a security team's discretionary judgment.

Demand quality follows the pattern described in 16c: scheduled, non-discretionary, legally enforced — the revenue profile that commands premium multiples and attracts platform acquirers.

Adversary adoption of the same standards

The migration is generally treated as a defender's schedule, governed by the deadlines above. The standardized algorithms are public and freely implementable, however, which makes them available to any party, and adversary use of them has now been documented in an intrusion campaign rather than only in research.

Check Point Research published an analysis on August 11, 2026 of a wave of the long-running North Korean campaign known as Operation Dream Job, which approaches employees at defense firms with fraudulent job offers. The wave targeted defense and aerospace organizations in Europe and India, including organizations working on surveillance sensors, drones and robotics, with activity or targeting observed in France, Germany, Brazil and India. In the delivery chain, a module requested four public keys from the command server and used ML-KEM (Kyber) — the key-encapsulation scheme NIST standardized in 2024 as FIPS 203, the same algorithm named in the timeline above — to establish the channel over which it retrieved a Windows privilege-escalation exploit, which was decrypted and run in memory. A further encryption layer sat on top of the malware's own transport encryption. The exploit itself, CVE-2026-68820, a flaw in a Windows kernel networking driver, was the only vulnerability in Microsoft's August 2026 Patch Tuesday release flagged as under active exploitation; Check Point reported it to Microsoft on July 28 and published on the day the patch shipped. The payload delivered through the handshake was a build of the group's kernel rootkit that disables telemetry callbacks, removes minifilters and blinds 94 Event Tracing for Windows providers, with newly added tampering against Smart App Control. Command-and-control ran almost entirely on machines the group did not own — compromised Roundcube webmail servers and PrestaShop sites, at least 17 of them acting as relays — and part of the delivery used websites impersonating a privacy technology vendor, which Check Point stated was itself neither targeted nor compromised.

Two consequences bear on the commercial picture, and both are narrower than the headline framing suggests. First, the use of a quantum-resistant key exchange here is an evasion measure against present-day interception and later decryption of captured traffic, not evidence of quantum capability; the migration deadlines are unchanged by it. Second, it points at a class of control whose economics depend on reading session content — TLS-terminating proxies, network data-loss prevention, and network detection built on inspecting or reconstructing traffic. Where adversaries negotiate their own channels with algorithms chosen for resistance to future decryption, the value of passively captured traffic falls, and the case for those products rests more on endpoint and identity telemetry than on the wire. One campaign is an early indicator rather than a repricing, and the same logic has applied to encrypted command-and-control for years; what is new is the algorithm class. For diligence purposes it adds a second question alongside crypto-agility in the product roadmap: whether a target's detection approach assumes content it will continue to be able to see.

Sources: Infosecurity Magazine — Lazarus Used Post-Quantum Key Exchange to Deliver Zero-Day (Aug 12, 2026) · Check Point Research analysis (Aug 11, 2026)

See Nation-State APTs for the actor tier this campaign belongs to and Network & SASE for the inspection-dependent product lane.

Cloud-provider timetables

The regulatory deadlines set the outer boundary, but for most enterprises the practical migration schedule is set by the hyperscalers, because the majority of an organization's cryptography now terminates in someone else's infrastructure. All three of the largest providers have now stated a position, and they have not stated it in the same form — which is itself the useful observation, because the form of the commitment determines what an enterprise can actually plan against.

Provider Form of commitment Stated horizon
Google Cloud Dated program with a completion year and per-workstream milestones Full post-quantum readiness by 2029, continuing into the 2030s
Microsoft Dated program tied to an internal engineering framework, accelerated in 2026 Critical products and services transitioned by 2029; quantum-safe capabilities default across all products and services by 2033
AWS Continuous capability delivery under a shared-responsibility split, mapped to regulator deadlines rather than to a single completion year No company-wide completion date published; service-by-service readiness stated against external deadlines "as early as 2027" for confidentiality and "as early as 2029" for authentication

Google Cloud published an updated roadmap in August 2026 targeting full post-quantum readiness by 2029, with work expected to continue into the 2030s (Google Cloud, Aug 2026 · SecurityWeek, Aug 14 2026). The plan organizes work into three priorities — mitigating harvest-now-decrypt-later risk, hardening digital signatures against forgery, and building the crypto-agility to adopt successor standards — and attaches dates to each:

Milestone Target Scope
Already shipped 2026 ML-KEM hybrid key exchange live on google.com and googleapis.com endpoints; opt-in quantum-safe hybrid TLS 1.3 on application and proxy load balancers; Cloud KMS generally available for NIST-standardized PQC key exchange and signatures
Harvest-now-decrypt-later mitigation End of 2027 Customer-facing workloads, administrative and developer tooling (Cloud VPN, Interconnect), and data-transfer services (BigQuery CLI, Storage Transfer Service)
Signature integrity and identity End of 2028 Quantum-resistant software supply-chain attestations, quantum-safe certificates across the infrastructure, hardening of Cloud IAM
Foundational key management End of 2028 Quantum-safe key import as early as 2026; confidential computing, Cloud HSM, external key management and partner-enabled key sovereignty in 2028
Full readiness 2029 Continuing into the 2030s against CNSA 2.0 and the NIST IR 8547 transition paths, which anticipate final deprecation of quantum-vulnerable algorithms between 2030 and 2035

Microsoft organizes its work under the Quantum Safe Program, first set out in 2023. A roadmap published on August 20, 2025 put early adoption of quantum-safe capabilities at 2029 and full transition, with those capabilities becoming the default across all products and services, at 2033 — two years ahead of the 2035 completion horizon set by several governments. The program was structured in three phases: post-quantum algorithms integrated into foundational cryptographic components, principally the SymCrypt library shared across Windows, Azure and Microsoft 365; then core infrastructure services, including Entra authentication, key and secret management, and signing services; then the wider estate of Windows, Azure services, Microsoft 365, data platforms, AI services and networking. On June 30, 2026 the company accelerated the schedule, stating that critical products and services would transition to post-quantum cryptography by 2029 and that post-quantum requirements would be folded into its Secure Future Initiative, the internal engineering framework it uses for other security commitments. Mark Russinovich, chief technology officer of Microsoft Azure, attributed the change to advances in quantum research shifting the risk horizon rather than to any regulatory instrument. The named focus areas are network cryptography via TLS 1.3, crypto-agility for stored data — self-describing cryptographic metadata or versioned ciphertext formats, so that systems can read legacy data while writing with current algorithms — and post-quantum protection of trust chains, meaning code signing, certificate issuance, key protection and update pipelines. ML-KEM and ML-DSA are being delivered to Windows Server 2025 and Windows 11 through the Cryptography API: Next Generation libraries and certificate functions.

AWS has published no single company-wide completion year. Its stated position is a shared-responsibility split under which some post-quantum capability is enabled transparently for all customers and the rest is offered as options customers apply themselves, delivered service by service and measured against external regulatory deadlines rather than an internal target date. On the shipped side: ML-KEM for confidentiality across service endpoints, with services listed individually as their public endpoints reach full support, and customer-configurable resources such as load balancers, Transfer Family and API Gateway exposing post-quantum TLS policies the customer must select; ML-DSA for digital signatures in AWS Private Certificate Authority (launched November 2025) and in Key Management Service (launched June 2025), with CloudHSM support in preview. The obligations placed on the customer are specific — applications must use TLS 1.3, client-side SDKs must be updated to versions supporting ML-KEM, and infrastructure-as-code should name the intended TLS policy explicitly, because leaving it at the default can regress a resource to an older policy chosen for backwards compatibility. On the performance question that has slowed adoption elsewhere, AWS reports no significant throughput or latency impact at CloudFront, S3 and KMS, and states that its optimized ML-KEM implementation runs up to 2.7 times faster on Graviton cores and 1.8 times faster on x86 instances than its own earlier implementations.

Sources: The Hacker News — Microsoft accelerates post-quantum shift to 2029 (Jul 1, 2026) · Infosecurity Magazine — Microsoft to make all products quantum safe by 2033 (Aug 22, 2025) · AWS — migration to quantum-resistant cryptography

The three postures produce different planning consequences. A dated completion year, as at Google Cloud and Microsoft, gives an enterprise a milestone it can put in a program plan and hold a vendor to; a continuous-delivery posture, as at AWS, gives earlier access to capability service by service but no single date to plan against, so readiness must be tracked per service rather than assumed from a headline. An organization on more than one cloud inherits the union of these schedules rather than the earliest or the average. Two questions follow for diligence on any target with meaningful cloud dependency: which providers its product terminates cryptography against, and whether its roadmap assumes a completion year that its providers have not committed to.

Two features of the framing matter commercially, and they apply to all three. First, the provider takes responsibility for its own infrastructure only: customers remain responsible for client-side software, the lifecycle of their own keys, and reconfiguring services to use quantum-safe settings once available. The division of labour is the same one that made cloud security a market rather than a feature, and it locates the spend on the customer side of the line. Second, the recommended first steps for customers — inventory cryptographic assets, update tooling to PQC-capable libraries, test applications against the quantum-safe endpoints already available — are precisely the discovery-and-agility workflow described above, now prescribed by the platform rather than only by regulation.

The hardware layer carries the same logic downward: Google states it is anchoring trust in open-source silicon components including Caliptra and OpenTitan, the latter already supporting quantum-secure boot. Where a hyperscaler's dates and a regulator's dates diverge, the earlier of the two governs the vendor roadmap, because a product that cannot run on a quantum-safe cloud has a shorter usable life than one that merely misses a compliance deadline.

Verifying a vendor's quantum-safe claim

Deadlines and roadmaps set what has to be done and by when. They do not establish how a buyer tests whether a product that is marketed as quantum-safe actually is. That gap closed at the hardware root of trust on August 24, 2026, when the Trusted Computing Group — the vendor-neutral standards body for hardware-based security — published guidance defining what a Trusted Platform Module must implement before it can be described as ready for post-quantum cryptography, and stated that some modules on the market advertise compliance without providing full end-to-end capability (Infosecurity Magazine, Aug 24 2026 · Help Net Security, Aug 25 2026).

The baseline is the TCG PC Client Platform TPM Profile (PTP) 1.07, developed from March 2026 by roughly 90 contributors drawn from government, academia, semiconductor manufacturers and computing hardware vendors, including Intel, Google, Hewlett Packard Enterprise, Microsoft, NVIDIA, Lenovo and STMicroelectronics (PTP 1.07 specification). It sets minimum requirements rather than a ceiling: it defines which ML-KEM endorsement-key certificates a module must carry and enlarges data transport on the command interface to accommodate post-quantum key sizes, and vendors remain free to implement additional algorithms. Against that baseline the guidance defines two designations:

Designation Meaning Consequence for the installed base
TCG PQC-ready TPM Implements PTP 1.07 No hardware change required
TCG PQC-upgradable TPM Does not implement PTP 1.07, but is designed so that support can be added Reaches readiness through an update rather than replacement

Modules in neither category are the material case, because they reach readiness only through hardware replacement. TCG has also stated an intention to extend its certification programs to certify modules against PTP 1.07, which would move the claim from vendor evidence to third-party attestation.

Three consequences follow. First, the module is where platform identity, attestation keys and firmware measurements live, and those artifacts have to remain trustworthy for the service life of the machine — which for server and industrial fleets is measured in decades, well past the 2030–2035 deprecation window set out above. Second, the ready-versus-upgradable split converts a cryptographic question into a capital-expenditure one: a fleet on upgradable modules migrates through firmware, while a fleet on neither designation migrates through a hardware refresh, and the difference falls on the endpoint, server and OT estates rather than on the security budget. Third, the guidance gives procurement and diligence a written baseline to request evidence against, in a segment where TCG states that 90% of businesses still lack a formal post-quantum roadmap — a trade-body figure, offered without an underlying survey, and best read as an order of magnitude for how little of the market has begun.

The capital cluster

Capital moved on the segment within days of the US deadlines becoming law:

Three dated policy-and-capital events in seventeen days, spanning the full capital structure: an executive order creating the obligation, a growth-equity check capitalizing the segment's consolidator, and a venture seed funding the discovery layer.

Relevance to M&A

The migration reshapes the machine-identity and PKI comp set in three ways. First, it adds a heavily capitalized consolidator: Keyfactor's stated intent to use part of its $1B+ round for strategic acquisitions makes sub-scale PKI, certificate-lifecycle, and crypto-agility vendors natural targets, and strengthens the exit narrative across the lane. Second, precedent already exists at platform scale — CyberArk acquired Venafi for approximately $1.54 billion in 2024, and that asset now sits inside Palo Alto Networks following the CyberArk acquisition (completed Feb 2026), meaning the largest security platform in the sector owns a machine-identity/PQC stake. Third, PQC readiness is becoming a diligence line item: for any target with federal or EU critical-infrastructure exposure, the questions are whether a cryptographic inventory exists, how much of the estate is crypto-agile, and whether the product roadmap survives the 2030/2031 deadlines. Vendors whose products embed non-agile cryptography carry a dated liability; vendors who sell the remediation carry a dated tailwind.

Related pages: Regulation (EO 14412 summary row) · Certifications as Moats · Identity (machine identity) · Regulatory Calendar as Deal Catalyst


Updated 2026-10-04 19:34 UTC · © El Dorado Capital · el-doradocapital.com · Market intelligence for informational purposes only; not investment advice.