Post-Quantum Cryptography Migration: A Developer's Guide to Beating the Harvest-Now-Decrypt-Later Threat

Quantum computers capable of breaking today's encryption don't exist yet. But waiting for them to arrive before acting would be a serious mistake — and the reason comes down to a threat that is already unfolding.

This guide walks developers through what post-quantum cryptography migration actually involves: not the abstract warnings, and not the dense lattice mathematics, but the concrete work of building an inventory, enabling hybrid encryption in the tools you already use, planning your signature transition, and engineering systems that can adapt as standards evolve.

Why You Can't Wait for Q-Day

The phrase "Q-Day" refers to the moment a cryptographically relevant quantum computer finally exists — one powerful enough to break the public-key encryption that secures most of the internet. That day hasn't come. So why is migration urgent now?

The Harvest-Now-Decrypt-Later Threat in Plain Terms

The answer is a strategy known as harvest now, decrypt later (HNDL), sometimes called store-now-decrypt-later. The logic is simple and unsettling: an adversary records encrypted traffic today, stores it, and waits. The data stays locked until a quantum computer capable of breaking the encryption arrives. Once it does, everything that was captured can be unlocked retroactively.

This changes the math entirely. You might think encrypted data is safe because no machine can currently crack it. But if that data needs to stay confidential for ten, fifteen, or twenty years — think medical records, state secrets, financial data, intellectual property, or long-term legal documents — then it is already exposed. The encryption protecting it today will not protect it for its full required lifespan.

Any data with a 10-or-more-year confidentiality requirement is, in practical terms, already at risk. The clock started the moment it crossed the wire.

This is what makes the migration immediate rather than theoretical. You are not defending against a future attack on future data. You are defending against a future attack on data moving through your systems right now.

What Quantum Computers Actually Break (and What They Don't)

A common misconception is that quantum computers will break all cryptography. They won't. Understanding the distinction is essential to migrating intelligently, because it tells you where to spend your effort and where you can relax.

The threat comes from two quantum algorithms:

Shor's algorithm is the dangerous one. It efficiently solves the mathematical problems — integer factorization and discrete logarithms — that underpin public-key cryptography. This means the algorithms you rely on for key exchange and digital signatures, such as RSA and elliptic-curve cryptography (ECC/ECDH), are fundamentally broken by a sufficiently capable quantum machine. There is no patch or larger key size that saves them; the underlying hardness assumption simply collapses.

Grover's algorithm is the milder threat. It speeds up brute-force searches against symmetric cryptography like AES. But it only provides a quadratic speedup, which effectively halves the security strength rather than eliminating it. The practical consequence is reassuring:

• AES-256 remains quantum-resistant. Its security margin is large enough that Grover's algorithm doesn't meaningfully endanger it.
• AES-128's margin is halved, but it isn't catastrophically broken.

The takeaway is that symmetric cryptography is mostly fine, while public-key cryptography is the real problem. This single fact shapes the entire migration strategy: you focus on key agreement and signatures, not on replacing your symmetric ciphers wholesale.

The Regulatory Clock: NIST IR 8547, Executive Order 14306, CNSA 2.0

Beyond the technical threat, there is a hard compliance dimension that turns "should migrate" into "must migrate" for many organizations.

The foundational standards are now final. In August 2024, the U.S. National Institute of Standards and Technology (NIST) published the finished post-quantum standards — FIPS 203, FIPS 204, and FIPS 205 — ending years of competition and analysis. With standards finalized, the deadlines followed:

• NIST IR 8547 ("Transition to Post-Quantum Cryptography Standards") sets a timeline to deprecate quantum-vulnerable algorithms at the 112-bit security strength for federal systems by 2031, and to disallow them entirely by 2035.
• The NSA's CNSA 2.0 (Commercial National Security Algorithm Suite) imposes earlier dates for national-security systems, pushing those organizations to move faster than the general federal timeline.
• U.S. Executive Order 14306, issued June 6, 2025, requires federal agencies to begin inventorying their cryptographic dependencies — the foundational first step of any migration.

Even if you don't work for a federal agency, these deadlines matter. They cascade through supply chains, vendor requirements, and procurement rules, and they set the de facto industry timetable that enterprises follow.

The New Standards, Demystified

The replacements for our vulnerable algorithms emerged from a multi-year NIST competition. Each finalized standard descends from a submission that survived years of public scrutiny, and each addresses a specific cryptographic job.

FIPS 203 (ML-KEM) for Key Establishment

FIPS 203 standardizes ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), derived from the algorithm formerly known as CRYSTALS-Kyber. This is the workhorse of the transition.

A key-encapsulation mechanism (KEM) is how two parties establish a shared secret over an insecure channel — the modern equivalent of the key-exchange step that secures a TLS connection. Because key agreement is exactly what HNDL attacks target, ML-KEM is the single most urgent piece of your migration. Protecting key establishment is what stops today's recorded traffic from being decrypted tomorrow.

The most common variant you'll encounter is ML-KEM-768, which strikes a practical balance between security and performance.

FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for Signatures

While ML-KEM handles key exchange, two other standards handle digital signatures — the mechanism that proves authenticity and integrity, used in code signing, certificates, and tokens.

• FIPS 204 standardizes ML-DSA (Module-Lattice-Based Digital Signature Algorithm), derived from CRYSTALS-Dilithium. This is the primary signature standard.
• FIPS 205 standardizes SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), derived from SPHINCS+. It is built on a completely different mathematical foundation — hash functions rather than lattices — which makes it a valuable conservative backup, even though its signatures are larger and slower.

Signatures are generally less time-sensitive than key agreement. A signature verifies authenticity at the moment of use; an adversary recording a signed message today gains nothing by breaking the signature years later, because the data isn't secret — it's just authenticated. This is why the standard advice is to migrate key agreement first and signatures second.

Backups and Diversity: HQC and FN-DSA/Falcon

NIST didn't stop at a single algorithm per task, and for good reason: relying on one mathematical approach is risky. If a weakness were discovered in lattice-based cryptography, having a fundamentally different fallback prevents a single point of failure. This principle is called algorithmic diversity.

• HQC, selected in March 2025, is a code-based backup KEM. Because it rests on different mathematics than ML-KEM, it offers insurance against an unexpected break in the lattice family. Its FIPS standard is expected around 2027.
• FN-DSA (based on Falcon), expected as FIPS 206, will offer a signature scheme with notably smaller signatures — valuable in bandwidth- and memory-constrained settings where ML-DSA's size becomes a burden.

Why Hybrid (Classical + PQC) Is the Default Transition Mode

Here lies one of the most important strategic decisions in the entire migration, and it's worth pausing on.

The post-quantum algorithms are new. They have undergone enormous scrutiny, but they simply haven't been battle-tested across decades the way RSA and ECC have. There is a genuine, if small, risk that a clever attack against a young algorithm could surface in the coming years.

Hybrid cryptography is the elegant answer. Instead of replacing the classical algorithm with a post-quantum one, you run both together. A widely used example is X25519MLKEM768, which combines the classical X25519 elliptic-curve exchange with post-quantum ML-KEM-768.

The security property is the key insight:

A hybrid connection stays secure as long as either algorithm holds. A quantum computer might break the classical half — but the post-quantum half protects you. And if a flaw is later found in the post-quantum algorithm, the classical half still stands. You only lose security if both are broken at once.

This fail-safe design is why hybrid deployment is the recommended transition path, and it's the approach taken in production by Meta, Cloudflare, AWS, and Akamai. It buys confidence during the years when the new algorithms are still earning trust.

Step 1: Build Your Cryptographic Inventory

Every credible migration starts in the same place, and it isn't with code changes. You cannot migrate what you cannot see. Most organizations have no clear picture of where and how cryptography is used across their systems — which libraries, which algorithms, which key sizes, embedded in which services. The first job is to build that picture.

What a CBOM Is and How It Relates to an SBOM

You may already be familiar with a Software Bill of Materials (SBOM) — a structured inventory of all the software components and dependencies in a system. A Cryptographic Bill of Materials (CBOM) applies the same idea specifically to cryptography.

A CBOM catalogs:

• Which cryptographic algorithms are in use (RSA, ECDH, AES, and so on)
• The key sizes and parameters
• Where each is used — which services, protocols, certificates, and dependencies
• How these elements connect to one another

The CycloneDX schema provides a standard format for expressing a CBOM, making the inventory machine-readable and shareable.

Crucially, a CBOM is not a one-time audit. It should be treated as a living, continuously updated artifact. Cryptography changes as code ships, dependencies update, and infrastructure shifts. An inventory that's accurate today is stale in six months unless you keep it current.

Tooling to Scan Code, Containers, and Configs

You don't have to build the inventory by hand. A range of tools can scan your codebase, container images, and configuration to discover cryptographic usage, including:

• ReversingLabs Spectra Assure
• Checkmarx (SCA/SBOM capabilities)
• Keyfactor and Sectigo for certificate and PKI discovery
• The PQC Coalition Inventory Workbook and guidance from Encryption Consulting

For organizations seeking structured guidance, NIST's NCCoE (National Cybersecurity Center of Excellence) publishes practical material on migration and inventory under its Migration to Post-Quantum Cryptography project.

Prioritizing by Risk: Key Agreement First, Signatures Next, Symmetric Last

Once you can see your cryptography, you sequence the work by risk rather than tackling everything at once. The priority order falls directly out of the threat model discussed earlier:

1. Key agreement — high priority. This is the direct HNDL defense. Anything establishing shared secrets (TLS, SSH, VPNs) comes first.
2. Digital signatures — medium priority. Important, but less time-critical because signatures don't protect long-lived secrets.
3. Symmetric cryptography — low priority. AES-256 is already quantum-resistant, so in most cases this needs little or no change.

This risk-based sequencing is what keeps a daunting, decade-long effort manageable. You put your energy where the exposure is greatest.

Step 2: Migrate Data-in-Transit

With an inventory in hand and priorities set, the first concrete migration target is data in transit — the traffic flowing across networks through TLS and SSH. This is where the HNDL threat is most acute and where, conveniently, tooling support is most mature.

TLS 1.3 Hybrid Key Exchange (X25519MLKEM768)

The headline change for most developers is enabling hybrid key exchange in TLS 1.3 using X25519MLKEM768. As described earlier, this runs classical and post-quantum key agreement together, so the connection is quantum-safe while retaining classical security as a fallback.

This is precisely the change driving the real-world adoption numbers. According to Cloudflare's 2025 Radar Year in Review, post-quantum encrypted traffic nearly doubled throughout 2025, from 29% at the start of the year to 52% in early December — meaning the majority of human-initiated web traffic became quantum-safe in a single year.

Enabling PQC in OpenSSL 3.5 and BoringSSL

The most significant tooling milestone is OpenSSL 3.5.0, the first OpenSSL release with built-in support for ML-KEM, ML-DSA, and SLH-DSA. Previously, post-quantum support required external providers; now it ships natively in the most widely used cryptographic library on the internet. BoringSSL (Google's fork) also supports hybrid post-quantum key exchange, powering Chrome's deployment.

This matters because OpenSSL underlies an enormous swath of software. When the base library gains native support, the entire ecosystem built on it inherits a path forward.

Post-Quantum SSH with OpenSSH (mlkem768x25519-sha256)

SSH is one of the most accessible places to see post-quantum cryptography working, and OpenSSH has been ahead of the curve. According to OpenSSH's official PQC page:

• OpenSSH has offered post-quantum key agreement by default since release 9.0 (April 2022), originally via sntrup761x25519-sha512.
• It added mlkem768x25519-sha256 in version 9.9.
• It made that the new default scheme in OpenSSH 10.0 (April 2025).
• OpenSSH 10.1 will warn the user when a non-post-quantum key agreement scheme is selected.

You can inspect and configure this directly. To check which post-quantum key exchange algorithms your client supports:

ssh -Q kex | grep -E 'mlkem|sntrup'

To set your preferred algorithms, you edit the KexAlgorithms line in ~/.ssh/config.

There's a real-world gotcha worth flagging. GitHub's SSH endpoint did not yet support post-quantum key exchange, which means a strict post-quantum-only configuration could break connections to it. The practical fix is a per-host classical fallback:

Host github.com
    KexAlgorithms +curve25519-sha256

This is a perfect illustration of why hybrid and fallback configurations matter — the ecosystem migrates unevenly, and your configuration has to tolerate hosts that haven't caught up.

Cloud Endpoints: AWS KMS/ACM/Secrets Manager, Cloudflare

Major cloud providers have made post-quantum TLS available, often behind a simple flag. As of April 2025, AWS supports ML-KEM hybrid TLS in KMS, ACM, and Secrets Manager.

The performance impact is modest and well-documented. According to the AWS Security Blog, switching from classical to hybrid post-quantum key agreement will transfer approximately 1600 additional bytes during the TLS handshake and will require approximately 80–150 microseconds more compute time. Even in the worst case — no TLS connection reuse — throughput dropped only about 2.3% on average (from 108.7 to 106.2 transactions per second), measured with the AWS SDK for Java v2.

Enabling it is often a one-line change:

• In the AWS SDK for Java v2, you call .postQuantumTlsEnabled(true).
• In the Rust SDK, you enable the prefer-post-quantum feature flag in rustls.

AWS-LC, the underlying cryptographic module, holds FIPS certificates (#4631, #4759, and #4816). Note also that CRYSTALS-Kyber support is being phased out across AWS endpoints in 2026 in favor of standardized ML-KEM — a concrete example of why crypto-agility matters, which we'll return to shortly.

To verify that a hybrid handshake actually happened, you can confirm X25519MLKEM768 appears in the keyExchange field via AWS CloudTrail, or inspect the TLS handshake directly with Wireshark or your browser's developer tools.

Step 3: Migrate Signatures and PKI

Once data-in-transit is protected, attention turns to signatures and public-key infrastructure (PKI) — certificates, code signing, and token authentication. This part of the migration is genuinely harder and moves more slowly, and it's important to understand why.

Code Signing, JWTs, and Certificate Chains

Signatures appear throughout modern systems:

• Code signing verifies that software hasn't been tampered with.
• JWTs (JSON Web Tokens) authenticate API requests and sessions.
• Certificate chains establish trust in TLS connections, where each certificate is signed by the one above it.

Migrating these to post-quantum signatures (ML-DSA or SLH-DSA) means changing not just your own code but the entire trust ecosystem certificates depend on.

Why PQC Certificates Lag Key Agreement

There's a structural reason certificates trail behind key exchange. A certificate's trust depends on a long chain of parties — root certificate authorities, intermediate CAs, browser root programs, and hardware security modules (HSMs) that protect signing keys. Every link in that chain must support the new algorithms before post-quantum certificates can work end-to-end.

This involves the CA/Browser Forum finalizing support, root programs updating, and HSMs passing audits for the new algorithms. Coordinating all of that across the industry takes time. The practical consequence is an interim period where key agreement is already post-quantum but certificates are still classical — and that's an expected, acceptable state during the transition, not a failure.

Planning for Larger Signatures and Certificate Sizes

Post-quantum signatures are substantially larger than their classical counterparts, and this has real engineering consequences.

• ML-DSA signatures are roughly 50 times larger than ECDSA signatures.
• For reference, an ML-DSA-65 signature is around 3,309 bytes.

When every certificate in a chain carries a much larger signature, the cumulative size grows quickly. This affects handshake sizes, bandwidth, storage, and memory — which is exactly why the smaller signatures promised by FN-DSA/Falcon are so anticipated for constrained environments. Planning for these size increases is a necessary part of the signature migration.

Step 4: Build Crypto-Agility Into Your Architecture

If there's one lesson that outlasts the specific algorithms, it's this: the standards will keep changing, and your architecture should expect that. The Kyber-to-ML-KEM transition already forced one round of changes; the HQC and FN-DSA standards will bring more. The goal is to make the next migration far less painful than this one.

Separating Crypto Policy from Enforcement

Crypto-agility is the architectural principle of separating cryptographic policy — which algorithm, which key length, under which conditions — from the systems that enforce it.

The practical difference is enormous. When policy is separated from enforcement:

Changing your cryptographic algorithms becomes a matter of updating configuration, not re-engineering systems. New choices propagate through your infrastructure automatically, instead of requiring developers to hunt down and rewrite hardcoded cryptographic calls scattered across the codebase.

Hardcoding a specific algorithm guarantees a painful re-migration the moment standards shift — which they just did, and will again. Designing for agility now is what spares you that pain later.

Guardrails: Stopping New Quantum-Vulnerable Keys

During a migration that may take years, you face a frustrating problem: while you're cleaning up old quantum-vulnerable keys, engineers may unknowingly create new ones. Without controls, you're emptying a bucket that keeps refilling.

The solution is guardrails — automated controls that prevent backsliding:

• Key-generation warnings that alert when someone creates a quantum-vulnerable key.
• Source-control rules that flag or block new quantum-vulnerable cryptography from entering the codebase.

These guardrails ensure your migration makes net progress rather than running in place.

Continuous Inventory and Monitoring

This brings the process full circle back to the inventory. Because cryptography keeps changing, monitoring must be continuous, not a one-time event. Cloudflare offers a strong model here: it now automatically scans active origins roughly every 24 hours to test and enable post-quantum handshakes. The principle is that your cryptographic posture is something you watch continuously, the same way you monitor uptime or security.

Language and Library Support Reference

A practical migration depends on knowing which tools actually support post-quantum cryptography today — and, importantly, which support only part of it.

Native and Provider-Based Support

The ecosystem has matured significantly, but support is uneven across languages and even across functions within a single language:

• Go provides native ML-KEM through the crypto/mlkem package, introduced in Go 1.24. An important caveat: Go's standard library provides native ML-KEM (key encapsulation) but does not provide native ML-DSA or SLH-DSA signature packages through Go 1.26. Don't assume full signature support in Go's standard library.
• OpenSSL 3.5 offers native ML-KEM, ML-DSA, and SLH-DSA.
• AWS-LC was the first open-source crypto module to include ML-KEM in a FIPS 140-3 validation.
• BoringSSL supports hybrid post-quantum key exchange.
• rustls supports post-quantum key exchange via the prefer-post-quantum feature flag.
• Bouncy Castle 2.x provides post-quantum algorithm support for Java and C#.
• Open Quantum Safe (OQS) / liboqs offers a broad library with language bindings (oqs-provider, liboqs-python, liboqs-go). Per the project's GitHub release page, liboqs 0.15.0 was released on November 14, 2025 — the last version to support SPHINCS+ and the release that removed Dilithium in favor of ML-DSA.

A critical warning about liboqs: its maintainers explicitly state it is intended for prototyping and experimentation, not for protecting production data. Use it to learn and test, but do not rely on it to secure sensitive production traffic.

Constrained Environments: IoT, Mobile, LoRaWAN

Post-quantum cryptography poses special challenges for constrained environments — devices with limited bandwidth, memory, or battery. The larger key and signature sizes that are a minor annoyance on a server become a serious obstacle on a sensor.

The numbers tell the story:

• ML-KEM-768 carries a 1,184-byte public key and a 1,088-byte ciphertext.
• LoRaWAN payloads are typically only 51 to 242 bytes.

When a single public key dwarfs the maximum payload size, you can't simply send it in one message. These environments require fragmentation planning — splitting cryptographic material across multiple transmissions — along with careful attention to battery life, since larger computations and more transmissions consume more power. This is the territory where the smaller signatures of FN-DSA/Falcon will be especially welcome.

A Phased 12-Month Migration Roadmap

Pulling the steps together, here is how a realistic migration can be sequenced over roughly a year. The phases build on one another, moving from visibility to action to durability.

Phase 1 — Inventory (Months 1–3). Build your Cryptographic Bill of Materials. Deploy scanning tools across code, containers, and configurations. Establish the CBOM as a living artifact with a process to keep it current. This is the foundation; everything else depends on it.

Phase 2 — Prioritize and Plan (Months 2–4). Using the inventory, rank cryptographic usage by risk: key agreement first, signatures second, symmetric cryptography last. Identify the highest-exposure systems — anything carrying long-lived confidential data over the network.

Phase 3 — Migrate Data-in-Transit (Months 4–8). Enable hybrid TLS 1.3 (X25519MLKEM768) and post-quantum SSH. Turn on post-quantum TLS at your cloud endpoints. Test in your own environment for handshake size, latency, and middlebox compatibility before broad rollout.

Phase 4 — Build Crypto-Agility and Guardrails (Months 6–10). Separate cryptographic policy from enforcement. Add key-generation warnings and source-control rules to stop new quantum-vulnerable keys from being introduced. Stand up continuous monitoring.

Phase 5 — Plan the Signature and PKI Transition (Months 9–12). Begin the slower signature and certificate migration as ecosystem support matures. Plan for larger signature and certificate sizes. Accept the interim state where key agreement is post-quantum but certificates remain classical.

The aim of this sequencing is to reach a state of readiness — what Meta calls "PQ-Ready" — before you're forced to be fully enabled. If a quantum breakthrough arrives suddenly, being ready in advance compresses the panic window from months to days.

Lessons from Real-World Migrations

The theory becomes far more credible when you see how major organizations have actually executed it.

Cloudflare: Adoption at Scale

Cloudflare provides the clearest picture of post-quantum adoption happening in the wild. Across 2025, post-quantum-encrypted human web traffic on its network rose from 29% to 52%. The company has committed to completing its PQC migration by 2029 and now automatically scans active origins roughly every 24 hours to test and enable post-quantum handshakes. A notable inflection came in mid-September 2025, when Apple's iOS 26, iPadOS 26, and macOS Sequoia enabled hybrid quantum-secure TLS 1.3 by default — within four days, the global share of post-quantum-supporting requests from iOS devices jumped from under 2% to 11%, exceeding 25% by early December.

Meta: The Enterprise-Migration Playbook

Meta published a detailed framework in "Post-Quantum Cryptography Migration at Meta: Framework, Lessons, and Takeaways" on its engineering blog. It introduces a six-step framework:

1. Prioritization
2. Build a Cryptographic Inventory
3. Address External Dependencies
4. Implement PQC Components
5. Implement Guardrails
6. Integrate PQC Components

Meta also defines a five-level maturity model for tracking progress, the PQC Migration Levels:

• PQ-Unaware — no awareness or action
• PQ-Aware — the organization understands its exposure
• PQ-Ready — capable of switching on post-quantum cryptography
• PQ-Hardened — robust protections in place
• PQ-Enabled — post-quantum cryptography fully active

Meta favors hybrid deployment and co-authored the HQC backup algorithm — reinforcing the themes of hybrid security and algorithmic diversity throughout this guide.

Apple and Signal: The End-to-End Messaging Story

Secure messaging shows post-quantum cryptography reaching ordinary users at massive scale:

• Signal's PQXDH (2023) was the first large-scale messaging app to add post-quantum security to initial key establishment.
• Apple's iMessage PQ3 (2024) went further, adding ongoing post-quantum rekeying with self-healing, so security is continually refreshed rather than established once.
• iOS 26 (September 2025) then enabled hybrid post-quantum TLS by default across hundreds of millions of devices — the change that drove the dramatic adoption spike Cloudflare measured.

Common Mistakes to Avoid

As you plan, watch for the pitfalls that have tripped up others:

• Treating PQC as a future problem. Ignoring HNDL exposure leaves long-lived confidential data unprotected today.
• Migrating signatures first. Key agreement is the urgent HNDL defense and should come first; signatures can follow.
• Choosing wholesale replacement over hybrid. Replacing classical algorithms outright loses the fail-safe if a young post-quantum algorithm is later broken.
• Hardcoding algorithms. This guarantees a painful re-migration when standards shift — as the Kyber-to-ML-KEM change already demonstrated.
• Forgetting middleboxes. Firewalls and proxies performing deep packet inspection can block the larger post-quantum handshake. Test for this before rolling out broadly.
• Assuming symmetric cryptography needs replacement. AES-256 is quantum-resistant; this is wasted effort.
• Relying on liboqs in production. Its maintainers explicitly state it's for prototyping and experimentation, not for protecting sensitive production data.

Best Practices Summary

To distill the guidance into a checklist:

• Start with a cryptographic inventory (CBOM). You can't migrate what you can't see. Treat it as living, not a one-time audit.
• Prioritize by risk: key agreement (high), digital signatures (medium), symmetric cryptography (low).
• Deploy hybrid (e.g., X25519MLKEM768) for fail-safe security throughout the transition.
• Reach "PQ-Ready" before you must be "PQ-Enabled" to compress the panic window if a breakthrough lands suddenly.
• Use ML-KEM-768 / X25519MLKEM768 as the sensible default for key agreement.
• Add guardrails so engineers can't introduce new quantum-vulnerable keys during the cleanup.
• Test in your own environment for handshake size, latency, and middlebox/DPI compatibility before enabling broadly.

What's Coming Next

The migration will keep evolving over the coming years. Several trends are worth watching:

• PQC certificates and PKI will mature as the CA/Browser Forum and root programs finalize ML-DSA certificate support from 2026 onward. Expect an interim period where key agreement is post-quantum but certificates remain classical.
• Pure (non-hybrid) ML-KEM groups and finalization of the IETF TLS drafts into formal RFCs are anticipated, though as of mid-2026 these remain Internet-Drafts. Treat timelines here as forward-looking projection, not settled fact.
• FN-DSA/Falcon (expected as FIPS 206) will bring smaller signatures for bandwidth- and memory-constrained environments, with HQC's FIPS standard expected around 2027.
• PQC for IoT, embedded systems, and LoRaWAN will remain a frontier, where large signature sizes strain payload limits and battery life.
• Crypto-agility will become a baseline architectural requirement — and an explicit hiring criterion, as job listings increasingly demand familiarity with crypto-agility and post-quantum readiness.

Key Takeaways

The migration to post-quantum cryptography is neither hype nor a distant concern. It is a live, measurable transition already underway across the internet's core infrastructure.

The threat is present-tense: harvest-now-decrypt-later means any data needing long-term confidentiality is already exposed. The standards are final: FIPS 203, 204, and 205 are published and ready. The deadlines are real: regulatory mandates run from 2031 to 2035. And the tooling is here: OpenSSL 3.5, Go 1.24, OpenSSH 10.0, and the major cloud SDKs all support post-quantum cryptography today.

The path forward is clear and sequenced:

1. Inventory your cryptography with a living CBOM.
2. Prioritize by risk — key agreement first.
3. Migrate data-in-transit with hybrid TLS and SSH.
4. Build crypto-agility so the next transition is painless.
5. Plan the signature and PKI migration as the ecosystem matures.

This is a decade-long effort, but the work that matters most begins now. The organizations already moving — Cloudflare, Meta, Apple, AWS — aren't reacting to a future threat. They're closing a window that's already open.

Frequently Asked Questions

What is "harvest now, decrypt later"? 

It's an attack strategy where an adversary records encrypted data today and stores it until a quantum computer capable of breaking the encryption exists. The implication is that any data needing long-term confidentiality is effectively at risk right now, even though no quantum computer can yet decrypt it.

Do I need to replace my symmetric encryption like AES? 

In most cases, no. AES-256 is considered quantum-resistant. Grover's algorithm only halves symmetric security strength, and AES-256's margin is large enough to remain secure. AES-128's effective security is reduced but not broken. The urgent work is in public-key cryptography — key agreement and signatures — not symmetric ciphers.

What's the difference between ML-KEM and ML-DSA? 

ML-KEM (FIPS 203) is a key-encapsulation mechanism used for establishing shared secrets — the key-exchange step in protocols like TLS. ML-DSA (FIPS 204) is a digital signature algorithm used to verify authenticity and integrity, as in code signing and certificates. ML-KEM is the more urgent migration because key agreement is what harvest-now-decrypt-later attacks target.

Why use hybrid cryptography instead of just switching to post-quantum algorithms? 

Hybrid runs a classical and a post-quantum algorithm together, so the connection stays secure as long as either one holds. Post-quantum algorithms are new and not yet battle-tested over decades; if a flaw were found in one, the classical algorithm still provides protection. This fail-safe is why major providers use hybrid as the default transition path.

What should I migrate first? 

Key agreement (key exchange) first, because it is the direct defense against harvest-now-decrypt-later. Digital signatures come next, as they're less time-sensitive. Symmetric cryptography is last, since AES-256 is already quantum-resistant.

Which tools support post-quantum cryptography today? 

Native support has landed in OpenSSL 3.5, Go 1.24 (ML-KEM via crypto/mlkem), OpenSSH 10.0 (default post-quantum key exchange), AWS-LC, BoringSSL, rustls, and Bouncy Castle 2.x, among others. Note that Go's standard library provides ML-KEM but not native ML-DSA/SLH-DSA signatures, and liboqs is intended for experimentation rather than production use.

How much does post-quantum TLS slow things down? 

The overhead is modest. AWS measured that switching to hybrid post-quantum key agreement transfers roughly 1,600 additional bytes during the handshake and adds about 80–150 microseconds of compute time, with throughput dropping only around 2.3% in the worst case of no connection reuse.

What is crypto-agility and why does it matter? 

Crypto-agility means designing systems so that cryptographic choices are separated from the code that enforces them, allowing algorithm changes through configuration rather than re-engineering. It matters because standards keep evolving — the Kyber-to-ML-KEM change already forced one round of updates, and more are coming. Agile systems make each future migration far less painful.

Sources

• Cloudflare, 2025 Radar Year in Review and State of the Post-Quantum Internet
• NIST, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)
• NIST IR 8547, Transition to Post-Quantum Cryptography Standards
• NIST NCCoE, Migration to Post-Quantum Cryptography
• NSA, Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)
• U.S. Executive Order 14306 (June 6, 2025)
• OpenSSH PQC page (openssh.org/pq.html)
• OpenSSL 3.5 release notes
• AWS Security Blog, ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager
• Engineering at Meta, Post-Quantum Cryptography Migration at Meta: Framework, Lessons, and Takeaways
• Open Quantum Safe / liboqs (openquantumsafe.org; open-quantum-safe/liboqs GitHub)
• Go release notes and pkg.go.dev/crypto/mlkem
• IETF, draft-ietf-tls-ecdhe-mlkem and draft-ietf-tls-mlkem
• Signal, PQXDH announcement
• Apple, iMessage PQ3 security documentation