up:: 00 Field Guide Map
The Transition
The Transition is the actual work of replacing quantum-vulnerable cryptography with quantum-safe cryptography across a live organization. It has five faces: the new standards that say what to deploy, the migration architecture that says how, the protocols where the algorithms run, the quantum-native technologies people keep asking about, and the human and organizational work where the whole thing either ships or stalls. You have to hold all five at once, because the faces people skip are the ones that sink the project.
Map of content
A short overview of the transition, and the index that routes you to every note in this section. Skim it to get oriented, then follow the links to go deep.
The short version:
- The transition is a program with five faces, and only the first one is about cryptography. The other four are about finding it, running it, judging the hype, and getting people to do the work.
- The new standards are the what: ML-KEM for key establishment and ML-DSA, SLH-DSA, and FN-DSA for signatures, the first three finalized by NIST in August 2024.
- The migration architecture is the how, and it starts with a step most programs underestimate: you have to find the cryptography before you can fix it, and it hides in places nobody mapped.
- The protocols are where new math becomes real protection, inside TLS, VPNs, and SSH. Quantum-native security (QKD, QRNG) is a niche complement, and the standardized algorithms carry the migration.
- The human and organizational side is where programs actually stall, on unclear ownership and quiet resistance, long before they stall on math.
Picture rewiring a hospital that never closes. The wiring runs through every wall, some of it installed by contractors who left no map, and you cannot switch off the lights while you work. Choosing better wire is the easy afternoon. Finding every run of the old stuff, swapping it without a single outage, and getting each ward’s staff to accept the disruption is the year that follows. The post-quantum transition is that job, done to the cryptography holding up a whole organization.
What is the post-quantum transition?
The post-quantum transition is the multi-year replacement of the public-key cryptography a quantum computer can break with the quantum-safe algorithms NIST standardized to replace it. The urgency comes from two facts sitting on top of each other. A large enough quantum computer running Shor’s algorithm breaks RSA, elliptic-curve cryptography, and Diffie-Hellman, which is the math under nearly every secure connection today. And harvest-now-decrypt-later means an adversary can record encrypted traffic now and open it the day that machine exists, so data with a long secrecy lifetime is already exposed even though the machine is not here yet.
That combination is what turns “someday” into a program with a clock. The replacements exist, the deadlines are published, and the work of getting from here to there is the transition. It is a program because it touches inventory, architecture, protocols, procurement, and people, and because doing it safely means running old and new side by side for years rather than flipping a switch.
What are the five faces of the transition?
The transition splits into five faces, and each answers a different question. A program that treats only the first face as the work has a plan for the easy 20% and no plan for the 80% that decides the outcome.
| Face | The question it answers | What it covers | Where it stands |
|---|---|---|---|
| The New Standards | What do we deploy? | ML-KEM for key establishment, ML-DSA / SLH-DSA / FN-DSA for signatures, plus the HQC backup | First three finalized Aug 13, 2024; HQC selected Mar 11, 2025 |
| Migration Architecture | How do we swap it safely? | discovery and the CBOM, crypto-agility, hybrid cryptography, composite certificates, key management | Deployable today; discovery is the gating first step |
| In the Protocols | Where does it run? | TLS hybrid key exchange, IPsec and VPNs, SSH, mTLS, QUIC | Hybrid TLS deploying now, endpoint by endpoint |
| Quantum-Native Security | Is the physics-based option the answer? | QKD, QRNG | Niche complement; agencies point to PQC as the substrate |
| The Human and Organizational Side | Why does it stall? | ownership, change management, vendor-controlled surfaces | The true bottleneck, and the least-taught face |
Source: NIST, “NIST Releases First 3 Finalized Post-Quantum Encryption Standards,” August 13, 2024, nist.gov; “NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption,” March 11, 2025, nist.gov.
The five faces are covered in depth in their own hubs, linked under Go deeper below. What follows is how they interlock, and why the order and the emphasis matter.
The New Standards: what do we deploy?
The new standards answer the what, and the single most useful thing to understand is that public-key cryptography did two separable jobs, so the transition has two separable replacements. Key establishment (agreeing a shared secret) moves to ML-KEM, a key encapsulation mechanism, with HQC held as a backup on different math. Digital signatures (proving identity and integrity) move to ML-DSA as the default, with SLH-DSA as the conservative hedge and FN-DSA as the compact option.
NIST finalized the first three, ML-KEM, ML-DSA, and SLH-DSA, on August 13, 2024, and selected HQC as a code-based backup on March 11, 2025.
Source: NIST, “NIST Releases First 3 Finalized Post-Quantum Encryption Standards,” August 13, 2024, nist.gov.
Two things about the standards shape the rest of the program. The symmetric world barely changes, so AES-256 and the SHA-2 and SHA-3 hashes stay, which means the whole transition is a public-key story. And “post-quantum” means “believed secure against the quantum attacks we know,” rather than “proven unbreakable forever,” which is why the architecture face insists on being able to swap again.
Migration Architecture: how do we swap it safely?
The migration architecture answers the how, and it opens on the step programs badly underestimate: before you can fix any cryptography, you have to find it, and it hides inside vendor products, embedded firmware, and forgotten systems nobody ever mapped. A CBOM is the inventory of where cryptography actually lives, and discovery is the detective work of building one.
Once you can see the estate, three engineering ideas carry the swap. Crypto-agility is the property that lets you change algorithms later through configuration rather than a rebuild, so the next change is an update instead of a construction project. Hybrid cryptography runs the classical and post-quantum algorithm together during the transition, so a session stays secure as long as either one holds. Composite certificates and careful key management carry the trust layer across without a gap.
The through-line, and the sentence worth memorizing: swapping the algorithm is the easy 20%, and finding every place it hides and rolling the replacement out safely is the other 80%, where programs actually succeed or stall.
In the Protocols: where does the new math run?
The protocols face is where the standards stop being math and start being protection, because a new algorithm helps nothing until it is running inside the protocols your systems speak. TLS is the big one, the protocol behind every https padlock, and it moves to hybrid key exchange, running classical X25519 and ML-KEM together. The same shift reaches IPsec and VPNs, SSH for remote access, and machine-to-machine mTLS.
The rule that governs this whole face: a protocol is only as quantum-safe as its weakest deployed endpoint. One un-migrated load balancer or legacy VPN gateway reopens the HNDL door for everything behind it, which is why applied PQC is a rollout tracked endpoint by endpoint rather than a box checked once.
Quantum-Native Security: is the physics-based option the answer?
Quantum-native security uses quantum physics itself, rather than new math, to protect information, and it comes up constantly with more hype than fit. QKD uses the laws of physics to share a key in a way that reveals any eavesdropper, and QRNG uses quantum processes to produce true randomness. Both are real technologies.
The honest picture is that QKD needs dedicated hardware and physical links, it does nothing for signatures or authentication, and it does not scale like software. Because of that, the major Western agencies point organizations to the standardized post-quantum algorithms as the substrate for the migration and treat quantum-native technology as a complement for a few extreme-assurance settings.
Source: NSA, “Quantum Key Distribution (QKD) and Quantum Cryptography (QC),” nsa.gov.
This face earns its place in the transition mostly so a team can answer the vendor pitch with confidence and move on, rather than lose a quarter debating a technology that was never going to carry the estate.
The Human and Organizational Side: why does the transition stall?
The human and organizational side is where the whole thing actually stalls, and it is the face almost no other resource teaches, because most of the field does not have the words for it. Two forces do the stalling. Organizationally, the vulnerable algorithm is scattered across dozens of vendor products nobody ever mapped, and ownership is unclear: engineering assumes procurement owns it, procurement assumes the board does, and a migration with no owner simply does not move. Humanly, the people who have to do the work sometimes fear that the change makes their hard-won skills obsolete, so they resist, and resistance shows up as a hundred small delays rather than a single objection.
The way through is to assign ownership before a line of code changes, and to bring people along instead of pushing change onto them, starting with the smallest completely reversible moves framed around what the developers themselves want. Naming this face out loud is most of the advantage. Nearly every firm has the technical arm, and almost none treat the human and organizational work as real work with its own method, which is why so many programs have a beautiful roadmap and no motion.
Which parts run urgent, and which run deliberate?
The transition runs on two clocks, and mixing them up is a common and expensive mistake. Key establishment is urgent because it is the half exposed to harvest-now-decrypt-later, so recorded traffic is a standing risk today. Signatures and PKI only fail once a real quantum computer exists, so they migrate on a slower, deliberate track. NIST’s transition guidance states the sequence plainly: migrate key establishment before signatures.
| Track | What it covers | Why this pace | Deadline anchors |
|---|---|---|---|
| Urgent (key establishment) | ML-KEM in TLS, VPN, and SSH key exchange, usually as a hybrid | Exposed to HNDL: traffic captured today is decrypted later | NIST IR 8547 says migrate key establishment first; 112-bit key exchange deprecated after 2030 |
| Deliberate (signatures and PKI) | ML-DSA / SLH-DSA, certificates, firmware and code signing | Only breaks once a CRQC exists; no retroactive exposure | NSA CNSA 2.0: software and firmware signing exclusive by 2030; full NSS transition by 2035 |
Source: NIST IR 8547 ipd, “Transition to Post-Quantum Cryptography Standards,” November 2024, csrc.nist.gov; NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” CSA U/OO/194427-22, September 2022.
The deliberate track is not a slow track because it matters less. It is slower because signing and PKI touch roots of trust, hardware security modules, and long-lived credentials that take careful ceremony and coordination to change, and because the harvesting clock does not apply to them. Both tracks run in parallel; the urgent one just cannot wait for the deliberate one to finish.
Why do the parts people skip sink the project?
Because the transition fails on its weakest face, and the weak faces are the ones that get skipped. A program can pick the right algorithms, deploy hybrid TLS on its front door, and still stall out for a year, and when it does, the cause is almost never the cryptography.
- Skip discovery and you migrate blind. If the inventory is incomplete, the un-migrated endpoint you never found is the one that keeps the harvesting door open for everything behind it. You cannot fix what you never located.
- Skip crypto-agility and every future change is a rebuild. The standards will change again, so a migration that hard-codes today’s algorithm buys one swap and re-buys the whole problem next time. Agility is what makes the next change a configuration update.
- Skip ownership and the roadmap never moves. A migration with no named owner is a document, not a program. Assigning ownership is the cheapest, highest-leverage move in the whole effort, and the one most likely to be treated as somebody else’s job.
- Skip change management and the people quietly stall it. Resistance rarely arrives as a “no.” It arrives as delay, and a team that feels change is being done to them will produce a great deal of delay. Bringing people along is the difference between a plan and motion.
The pattern under all four is the same: the technical face is legible and gets the attention, and the organizational and human faces are invisible until they are the reason nothing shipped.
How do the five faces fit into one program?
They fit as a rough sequence with heavy overlap, not a waterfall. Ownership and discovery come first and never really stop, because you assign someone the job and start finding cryptography before you deploy anything. The standards and the architecture decisions come next, choosing ML-KEM and committing to hybrid and agility as the pattern. Protocol rollout follows, endpoint by endpoint, with the urgent key-establishment track leading and the deliberate signing track running behind it. Quantum-native security sits to the side as a question to answer once rather than a phase to run. And change management runs underneath the entire thing, because every step above is executed by people who need to be brought along.
The reason to hold all five at once, rather than run them in strict order, is that they gate each other. Discovery reveals vendor-controlled surfaces you cannot change alone, which is an organizational problem. Protocol rollout surfaces the un-agile systems that need architecture work. And the human resistance shows up precisely when the technical work asks people to change how they build. A program that sequences the faces rigidly discovers the dependencies the hard way.
What does the transition build toward?
The transition is one stage in a larger arc. The Mandates are who is making you move, the regulations and deadlines (CNSA 2.0, NIST IR 8547, Executive Order 14306) that turn “post-quantum, someday” into named algorithms with named years. Doing the Work is how you actually run the program day to day, including the governance and the board and practitioner resources. And the foundations underneath all of it, what security and classical cryptography even are, live in Foundations and the threat that makes the transition necessary in the first place.
Common misconceptions
- “The transition is a technical project.” The cryptography is the smallest face. The transition is a program that lives or dies on inventory, ownership, protocol rollout, and change management, which are organizational and human problems.
- “We swap the algorithm and we’re done.” Swapping the algorithm is the easy 20%. Finding every place it hides across the estate and rolling the replacement out without an outage is the 80% that takes the time.
- “QKD or quantum-native tech replaces the whole thing.” For almost every organization the standardized algorithms carry the migration, and quantum-native security stays a niche complement that agencies do not recommend as the substrate.
- “We can wait until quantum computers arrive.” Harvest-now-decrypt-later means data with a long secrecy lifetime is already exposed. The key-establishment half of the work is urgent today, before the machine exists.
- “Once we migrate, we’re safe permanently.” “Post-quantum” means believed secure against known quantum attacks, so the durable win is building crypto-agility to swap again when the next change comes.
Questions people ask
Where does the transition actually start? With ownership and discovery. You assign someone accountable for the migration and start building the inventory, because you cannot plan a migration for cryptography you cannot see, and a program with no owner does not move.
What do we deploy first? ML-KEM for key establishment, usually as a hybrid with a classical algorithm, because that closes the harvest-now-decrypt-later exposure. Signatures and PKI follow on the deliberate track.
How long does a transition take? Years, not months, for a real estate. The published deadlines run to 2030 and 2035, and the pace is set less by the cryptography than by discovery, vendor dependencies, hardware refresh cycles, and getting people to do the work.
Is this only a problem for regulated industries? No. The mandates bind federal systems and their vendors first, but harvest-now-decrypt-later applies to anyone with data that must stay secret for years, and NIST’s deprecation years become the de facto industry clock through insurers, procurement, and vendor contracts.
Do we have to rip out all our encryption? No. Symmetric encryption (AES-256) and the hashes (SHA-2, SHA-3) survive with minor adjustments. The transition replaces the public-key layer, which is RSA, ECC, and Diffie-Hellman.
Why run old and new algorithms together? Hybrid deployment keeps a session secure as long as either the classical or the post-quantum algorithm holds, which protects you against an implementation flaw in the young post-quantum code while the harvesting clock is already running.
Which face do most programs get wrong? The human and organizational one. Nearly everyone can pick the right algorithm; far fewer assign ownership and manage the change, which is why so many programs have a roadmap and no motion.
What is the single most useful thing to understand? That the transition is a program, not an algorithm swap. Coverage that stops at the new standards has explained the easy part and skipped the part that decides whether the project ships.
Go deeper
The five faces, each a hub that teaches its own domain 0→1000:
- The New Standards, the what: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), FIPS 206 (FN-DSA), HQC (Hamming Quasi-Cyclic), and the algorithm families.
- Migration Architecture, the how: Cryptographic Discovery, the Cryptographic Bill of Materials (CBOM), Crypto-Agility, Hybrid Cryptography, Composite Certificates, Key Management.
- In the Protocols, the where: TLS, TLS 1.3 Hybrid Key Exchange, IPsec, Secure Shell (SSH), Mutual TLS, QUIC.
- Quantum-Native Security, the physics sideline: Quantum Key Distribution (QKD), Quantum Random Number Generation (QRNG).
- The Human and Organizational Side, where it stalls: Why Post-Quantum Migrations Stall, Cryptographic Ownership, Change Management for Cryptographic Migration, Vendor-Controlled Crypto Surfaces.
Field notes: Why Cryptography Was Never Meant to Be Permanent (the reframe that opens this section, cryptography is a replaceable subsystem with a shelf life, and designing for replacement is the whole posture).
The rest of the arc: The Mandates are who’s making you move, Doing the Work is how you run the program, and Foundations and the threat are what sits underneath.
Everything here is the map, given freely. When your team needs these five faces turned into a migration sequenced against your own systems, that’s the work I do, and there’s an alignment briefing for it.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.