The Y2Q Migration Guide: Five Steps Every Organization Must Complete Before Quantum Arrives

The standards are final. The threat is real. The migration takes years. Those three facts together define the Y2Q problem for every organization that handles sensitive data or runs critical digital infrastructure. This guide outlines the five steps of a post-quantum migration — what each involves, why it cannot be skipped, and what happens to organizations that delay.

The NSA's CNSA 2.0 framework sets 2027 as the first hard deadline for quantum-safe encryption across US national security systems. NIST's post-quantum standards are final as of 2024. The Global Risk Institute places a 28–49% probability of Y2Q arriving within the next ten years. For a migration that takes three to seven years from initiation to completion, the arithmetic is unambiguous: organizations that have not started are already behind the safest planning schedule.

Why migration takes years — not months

A common misconception is that post-quantum migration is a software update: swap one algorithm library for another, retest, redeploy. For consumer applications built on modern TLS stacks, that is partially true — browser vendors and cloud providers have already begun deploying hybrid post-quantum TLS, and end users see nothing. But for organizations with complex cryptographic dependencies — custom PKI infrastructure, hardware security modules, embedded systems, long-lived certificates, regulatory compliance requirements — migration is a multi-phase project involving audit, procurement, testing, and staged rollout across potentially thousands of systems.

Cloudflare, one of the most technically sophisticated organizations on the internet, has budgeted until 2029 for its own full post-quantum migration. If a company whose core product is cryptographic infrastructure needs years, an enterprise with a diverse technology estate should not expect to compress this into months.

Inventory

3–6 mo

Classify

2–4 mo

Pilot PQC

6–12 mo

Hybrid deploy

12–24 mo

Full PQC

12–24 mo

Step 1: Cryptographic inventory

Step 01

Map every cryptographic dependency in your organization

You cannot migrate what you have not found. A cryptographic inventory means identifying every system, service, library, hardware device, and vendor integration that uses public-key cryptography. In a mature enterprise, this spans:

TLS certificates and the services they protect
VPN and remote access infrastructure
PKI root and intermediate certificate authorities
Code signing certificates and pipelines
Hardware security modules (HSMs)
Cloud provider cryptographic services (KMS, secrets managers)
Third-party SaaS and vendor integrations
Embedded systems and IoT devices (often have 10+ year lifespans)

Tooling for automated cryptographic discovery is available from vendors including Venafi, Keyfactor, and IBM's Quantum Safe Explorer. NIST's NCCoE has published a migration guide (NIST SP 1800-38) that includes discovery methodology. The inventory phase typically takes three to six months and is often the most surprising: organizations consistently underestimate the number of cryptographic touchpoints they have.

Step 2: Data classification by sensitivity and longevity

Step 02

Identify which data is at risk from harvest now, decrypt later

Not all data has the same Y2Q risk profile. A transaction receipt for a $12 coffee purchase that will never matter again has near-zero quantum risk. A medical record that must remain confidential for decades, a government communication that is classified for 30 years, or intellectual property that represents competitive advantage for a decade — these are materially exposed by harvest now, decrypt later attacks that are already ongoing.

Classification criteria:

Longevity: Will this data still be sensitive in 5–15 years?
Adversary motivation: Does a state-level actor have reason to want it?
Volume: Is this data transmitted at scale over interceptable channels?
Regulatory exposure: Does its exposure create legal or compliance liability?

Data classified as high-risk on this framework should be prioritized for early migration — and where possible, should be re-encrypted with quantum-resistant algorithms now, before Y2Q arrives.

Step 3: Adopt NIST's finalized post-quantum standards

Step 03

Deploy ML-KEM, ML-DSA, FN-DSA, and SLH-DSA

NIST finalized four post-quantum cryptography standards in August 2024:

ML-KEM (CRYSTALS-Kyber) — key encapsulation, replacing RSA and Diffie-Hellman for key exchange
ML-DSA (CRYSTALS-Dilithium) — general-purpose digital signatures
FN-DSA (FALCON) — compact signatures for bandwidth-constrained applications
SLH-DSA (SPHINCS+) — hash-based signatures as a mathematical diversity backup

In March 2025, NIST added HQC as a fifth standard — a code-based key encapsulation algorithm that provides a backup in case lattice mathematics is ever compromised. All five are available in major cryptographic libraries including OpenSSL 3.x, BoringSSL, and liboqs. The implementation work required to adopt them depends heavily on your inventory findings from Step 1.

Step 4: Deploy hybrid cryptography during the transition

Step 04

Run classical and post-quantum algorithms in parallel

Hybrid cryptography means combining a classical algorithm (e.g., ECDH) with a post-quantum algorithm (e.g., ML-KEM) in a single key exchange, such that the session is only compromised if both are broken. This provides two critical properties during the migration period:

Backward compatibility: Systems that do not yet support PQC can still communicate
Defense in depth: If a newly standardized PQC algorithm has an undiscovered flaw, classical security still holds

Major cloud providers have already deployed hybrid TLS. Google Chrome, Cloudflare, and AWS support X25519+ML-KEM hybrid key exchange. For internal systems, hybrid mode is the recommended transition path by both NIST and the BSI (Germany's Federal Office for Information Security). Running hybrid indefinitely is not the goal — the goal is a clean migration to pure PQC — but hybrid prevents gap exposure during the multi-year rollout.

Step 5: Build crypto-agility into new systems

Step 05

Design for algorithm replacement, not algorithm permanence

The collapse of SIKE in 2022 — a post-quantum candidate broken by a classical algorithm on a laptop, after years of expert review — demonstrated that even well-vetted algorithms can fail unexpectedly. Crypto-agility means designing systems so that the cryptographic algorithm is a replaceable component, not a hardcoded assumption.

In practice, this means:

Abstracting cryptographic operations behind configurable interfaces, not hardcoded library calls
Using algorithm negotiation in protocols rather than fixed ciphersuites
Maintaining algorithm metadata (what was used, when, by which version) in data stores
Including cryptographic algorithm rotation in your operational runbooks
Evaluating HSM and PKI infrastructure for algorithm upgrade paths before procurement

Crypto-agility is the difference between a future migration being an operational procedure and being an emergency rebuild. Organizations that build it in today will be able to respond to the NIST additional signature standards (expected ~2028) as a routine update — not a crisis.

The supply chain dimension

One of the most underestimated Y2Q risks is the supply chain. Your organization's post-quantum migration is only as complete as your vendors' migrations. A perfectly migrated internal system that exchanges signed software updates with a vendor still using ECDSA is exposed through that vendor. A cloud-native application that encrypts data at rest with ML-KEM but communicates through a third-party API gateway still using RSA TLS has a gap. The Y2Q migration checklist must include a vendor assessment program — understanding which critical suppliers are on a post-quantum migration path, and which are not.

The NSA's CNSA 2.0 framework explicitly requires vendors supplying national security systems to meet PQC standards by specific deadlines. For organizations outside the defense sector, similar vendor requirements will increasingly appear in regulatory frameworks, insurance requirements, and enterprise procurement standards over the next three years. Building those requirements into vendor contracts and RFPs now is the lowest-cost time to do it.

Starting today

The single most important action any organization can take today is to start the cryptographic inventory. It costs nothing but time, it reveals the true scope of the problem, and it is the prerequisite for every subsequent step. NIST's post-quantum migration documentation — including SP 1800-38 and the accompanying NCCoE project materials — provides detailed, freely available guidance. The standards are final. The threat is real. The clock is running.