Post-Quantum Cryptography Migration: The 3Ps Strategy

Quantum computers will one day break the encryption we rely on today. Post-quantum cryptography (PQC) migration is how we replace it before that happens, and the job is bigger than any crypto change we have done before. It reaches into every TLS handshake, every code-signing pipeline, every VPN tunnel, every X.509 certificate, and every embedded device. Despite that scope, most organizations still treat the work as a future problem to be patched later.

The published deadlines disagree. Gartner forecasts that by 2029, advances in quantum computing will make conventional asymmetric cryptography unsafe to use.

For security engineers, PKI engineers, and CISOs, the question is no longer whether to migrate but how to migrate without breaking production or spending a multi-year budget on rework. The answer proposed here is a structured 3Ps strategy: Proactive, Preventive, and Practical. Each pillar answers a different question, runs on a different cadence, and produces a different artifact, yet the three reinforce one another. In this blog, we will examine why the timelines are urgent and how to put each pillar into practice.

The Quantum Clock: What Actually Breaks, and When

Shor’s algorithm, running on a cryptographically relevant quantum computer (CRQC), efficiently solves the two hard math problems that today’s public-key cryptography depends on: integer factorization and the discrete logarithm. That one capability breaks RSA, Diffie-Hellman, ECDH, and ECDSA, the algorithms that secure TLS, PKI, SSH, code signing, and most identity systems. Therefore, all of them now need quantum-safe replacements.

NIST finalized these replacements as three standards on August 13, 2024, after an evaluation process spanning nearly eight years. The three standards, described below, are FIPS 203, FIPS 204, and FIPS 205. FIPS 203 specifies ML-KEM, a Module-Lattice-Based Key-Encapsulation Mechanism that replaces RSA and ECDH key exchange. FIPS 204 specifies ML-DSA, a Module-Lattice-Based Digital Signature Algorithm that replaces RSA and ECDSA signatures. FIPS 205 specifies SLH-DSA, a stateless hash-based signature scheme whose security depends only on hash functions, providing a conservative fallback with hardness assumptions independent of lattice mathematics.

NIST is also advancing two further algorithms: FN-DSA, a FALCON-based signature scheme being standardized as FIPS 206, and HQC, a code-based key-encapsulation mechanism selected in March 2025 as a backup to ML-KEM. Both are still moving through the standards process and are not yet finalized.

The transition timeline is set out in NIST IR 8547, “Transition to Post-Quantum Cryptography Standards.” NIST IR 8547 is an Initial Public Draft released in November 2024 and is not yet a final standard. Quantum-vulnerable public-key algorithms, such as RSA-2048 and ECC P-256, are scheduled for deprecation after 2030 and full disallowance after 2035.

The distinction matters to auditors. As defined in the draft, deprecated means the algorithm or key length may still be used but carries some security risk, so the data owner must weigh that risk before continuing to use it. Disallowed means the algorithm, key length, parameter set, or scheme is no longer allowed for the stated purpose. The 2035 endpoint aligns with U.S. National Security Memorandum 10 (NSM-10) and with the UK NCSC plan, which sets milestones for 2028, 2031, and 2035.

National security systems follow a faster timeline. NSA’s CNSA 2.0, updated in May 2025, expects software and firmware signing to prefer quantum-safe algorithms by 2025 and to use them exclusively by 2030, with new system acquisitions required to be compliant starting January 1, 2027. Web and cloud services must achieve exclusive use by 2033. The directive explicitly specifies the strongest parameter sets, ML-KEM-1024 and ML-DSA-87. An organization that is not a federal supplier still inherits these dates indirectly, because vendors, cyber-insurers, and procurement teams increasingly treat them as the baseline.

Why this is urgent today rather than in 2035 comes down to the “harvest now, decrypt later” (HNDL) threat. An adversary records encrypted traffic or exfiltrates ciphertext now and decrypts it once a CRQC exists. Any secret whose confidentiality must outlive roughly 2030 to 2035, including health records, source code, key material, and intellectual property, is effectively exposed the moment it crosses a quantum-vulnerable channel.

The 3Ps at a Glance

The 3Ps map onto the three governance questions a migration program must answer. They are best run in parallel, because each one protects or informs the others.

Proactive: Find out what cryptography you have and how exposed it is. This pillar covers discovery, inventory, and risk-based prioritization before any algorithm changes.

Preventive: Protect what you can right now with hybrid key establishment and dual signatures that neutralize HNDL while protocols and libraries mature.

Practical: Finish without rework by building crypto-agility, so the current migration and the next one become a configuration change rather than a re-architecture.

The way PQC migration is framed determines its success. When treated as a single checklist, progress often stalls due to unclear ownership and a lack of visible results until the entire multi-year effort is completed. In contrast, organizing it into three parallel workstreams enables steady, measurable progress, with each pillar delivering independent value along the way.

With this framework in place, we can now look at each pillar individually and understand how it contributes to a successful PQC migration.

Proactive: See Your Cryptography Before You Migrate It

You cannot migrate what you cannot see, and the most uncomfortable finding in nearly every PQC readiness assessment is how little an organization knows about its own cryptographic footprint. Keys and algorithms can be hidden throughout the environment, including TLS terminators, service meshes, JWT signers, database transparent encryption, backup encryption, container image signing, IoT firmware, and third-party libraries that are included indirectly through other software dependencies. The steps below explain how to discover this cryptography, record it, and govern the migration.

Discover Across Four Planes

Effective cryptographic discovery spans four distinct planes. The source-code plane uses static analysis to find cryptographic API calls and hard-coded algorithm identifiers. The network plane observes the cipher suites and key-exchange groups actually negotiated in traffic. The certificate and key-store plane enumerates PKI hierarchies, HSM contents, and secrets managers. The binary and firmware plane inspects compiled artifacts and device images, which often contain the most stubborn, least visible cryptography. No single tool covers all four, so discovery is a fusion exercise, not a single scan.

Produce a Cryptographic Bill of Materials (CBOM)

The durable artifact of discovery is a Cryptographic Bill of Materials (CBOM), a machine-readable inventory of every algorithm, key, certificate, and protocol in use, with its purpose and location. It applies the familiar software-bill-of-materials (SBOM) concept to cryptography, captured in an open, machine-readable format so it lives inside existing inventory and supply-chain tooling rather than in a static spreadsheet.

You produce one by correlating the findings from the four discovery planes, deduplicating and normalizing them against a common identifier scheme, and mapping each asset to where it is used. Because it is structured data rather than a document, it can be regenerated automatically from the build pipeline.

Make It a Governance Program, Not a Security Project

A migration that touches procurement, application teams, and operations cannot be owned by the security team alone. Practical governance includes a board-level readiness metric, multi-year budget approval, and procurement language that requires new vendors to support FIPS 140-3 validated modules, demonstrate crypto-agility, and publish a PQC roadmap. Contracts signed today without those clauses become tomorrow’s legacy systems that cannot be migrated.

Once you can see your cryptography, you can start defending it. The next section, Preventive, covers the controls that buy you time.

Preventive: Buy Time Against Harvest Now, Decrypt Later

Preventive controls accept a hard truth: you will not finish migrating before adversaries start harvesting. The goal of this pillar is to make harvested data worthless even before the full migration lands, which is why it delivers the fastest return of the three. The steps below cover hybrid key exchange, dual signing, and prioritizing data by confidentiality lifetime.

Hybrid Key Establishment

The dominant preventive control is hybrid key exchange, which runs a classical and a post-quantum mechanism in parallel and combines their outputs through the TLS 1.3 key schedule. A widely adopted hybrid configuration is X25519MLKEM768. More precisely, it is defined in the IETF Internet-Draft draft-ietf-tls-ecdhe-mlkem, which is still a draft and not yet an RFC. On the wire, the client’s key share carries a 1,184-byte ML-KEM-768 encapsulation key plus a 32-byte X25519 share, for 1,216 bytes total.

The server responds with a 1,088-byte ML-KEM ciphertext plus its 32-byte share. The security benefit is conservative: an attacker must break both X25519 and ML-KEM-768 to recover the session, which protects against a quantum break of X25519 and against an unexpected classical break of the newer lattice scheme.

Dual-Sign: What You Cannot Easily Update

Firmware and boot-chain signatures have the longest lifetimes and the hardest update paths, which is why CNSA 2.0 pushes signing first. Where ML-DSA tooling is not yet available, the stateful hash-based schemes LMS and XMSS (NIST SP 800-208) are already supported by major HSM vendors and can dual-sign firmware today, pairing a classical signature with a quantum-safe one to preserve interoperability while establishing a quantum-resistant root of trust. One caution: LMS and XMSS are stateful, and reusing a one-time key state is catastrophic, so the signing state is advised to be managed inside the HSM.

Prioritize Data by Confidentiality Lifetime

Hybrid transport protects data in motion, but harvested archives and long-lived keys also need attention. Re-encrypting high-value archives under a hybrid or post-quantum scheme, and rotating long-lived keys sooner, closes the gap for data an adversary may already be holding. The rule of thumb is to prioritize confidentiality of long-lived data and integrity of long-lived trust anchors first; short-lived ephemeral secrets can wait for the practical pillar.

With these protections buying time, the focus shifts to finishing the migration cleanly. Now, we’ll look how practical pillar helps.

Practical: Engineer Crypto-Agility Into the Migration

The practical pillar is where engineering challenges become real. PQC algorithms are not drop-in replacements at the byte level, and treating them as such is a common cause of failed pilots. The steps below cover secure key storage, interoperability and performance testing, and building lasting crypto-agility.

HSMs, FIPS 140-3, and Validated Implementations

Quantum-safe keys still need quantum-safe custody. Confirm that HSMs and key-management platforms have firmware supporting ML-KEM and ML-DSA, plus LMS and XMSS for signing, and that the implementation is validated through NIST’s Cryptographic Algorithm Validation Program (CAVP), which uses the Automated Cryptographic Validation Protocol (ACVP) as its testing interface, rather than home-rolled. A subtle pitfall is that some platforms disable post-quantum key agreement in strict FIPS mode until the validated module is in place, so test the exact compliance configuration you intend to run in production.

Interoperability and Performance Testing

Larger handshakes expose middlebox and legacy-infrastructure bugs that classical TLS never triggered. Before a broad rollout, validate firewalls, load balancers, web application firewalls, and deep-packet-inspection appliances against real hybrid handshakes, and measure the added overhead. The added overhead is acceptable for web traffic but worth modelling for services with very high request volumes or bandwidth-constrained links.

Crypto-Agility Is the Real Deliverable

Everything else in the migration ultimately serves this goal. The algorithm swap is only the forcing function; the lasting payoff is crypto-agility, the ability to change cryptographic algorithms without re-architecting the systems that depend on them. In practice that means isolating cryptographic operations behind a provider interface, removing hard-coded algorithm identifiers and key sizes, negotiating algorithms at connection time rather than assuming them, and governing every choice from a single policy point.

With all three pillars now in view, it helps to step back and see what this approach delivers.

How the 3Ps Approach Pays Off

The 3Ps structure delivers concrete advantages over treating PQC migration as a single large project. It is more cost-effective and more durable, and it produces value at each stage rather than only at the end. Here is why it pays off:

• You remediate the highest-risk systems first, and only once, which avoids paying to redo the same work later.
• You gain protection quickly, because the preventive pillar neutralizes harvest-now, decrypt-later exposure within weeks.
• The three workstreams run independently, so if one stalls (for example, while waiting on a firmware update), the others continue.
• Each pillar leaves a durable artifact: a cryptographic inventory, hardened key establishment, and an architecture that is easier to change later.
• Once your systems support crypto-agility, the ability to swap cryptographic algorithms without re-architecting dependent systems, the next change becomes a configuration update rather than another multi-year project.
• The work maps to common security and compliance frameworks, so it doubles as audit evidence and is easier to get approved.

How Encryption Consulting Can Help

If you are wondering where and how to begin your post-quantum journey, Encryption Consulting’s PQC Advisory Services are here to support you. You can count on us as your trusted partner, and we will guide you through every step with clarity, confidence, and real-world expertise.

We begin with a Cryptographic Discovery and Inventory, scanning your entire environment to identify certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This builds the baseline you need before any migration can begin.

From there, we conduct a PQC Assessment to evaluate your exposure to quantum threats, identify RSA- and ECC-dependent systems, and deliver a prioritized report of vulnerable assets with risk severity ratings.

With that clarity, we develop a PQC Strategy and Roadmap, a phased migration plan aligned to your risk appetite, regulatory requirements, and long-term security goals, including cryptographic agility so your systems can adapt as standards evolve.

We then support Vendor Evaluation and Pilot Testing, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout.

Finally, we manage Full Implementation, deploying hybrid classical and quantum-safe models, rolling out PQC across your PKI and infrastructure, and setting up monitoring for long-term cryptographic health.

With this structured approach, you move from cryptographic uncertainty to a documented, policy-driven migration program aligned to NIST timelines and your regulatory obligations.

Conclusion

Organizations cannot afford to wait for a quantum computer to arrive. The standards are final, the timelines are published, and adversaries are already harvesting. The organizations that come through this well will treat the work as three reinforcing disciplines rather than a distant patch: proactively mapping their cryptography into a CBOM and prioritizing by data lifetime, preventively deploying hybrid key exchange and dual signatures to neutralize HNDL, and practically re-engineering PKI, HSMs, and applications around crypto-agility so the migration finishes and the next migration becomes a configuration change rather than a re-architecture. The deadlines are real, so the sooner you start, the easier and cheaper the migration will be. Begin by assessing your current cryptographic state.