Skip to content

The PQC migration lifecycle: discover, assess, prioritize, plan, execute, validate

Post-quantum migration is a repeatable lifecycle, not a one-off project. This is the end-to-end shape of the work — the six phases, what each produces, and why the order matters.

IT & securityWorking8 min· Updated Jul 22, 2026
TL;DR

The whole loop in one paragraph

Migrating to post-quantum cryptography runs as six phases: discover every use of cryptography, assess each for exposure, prioritize by data shelf life and harvest-now-decrypt-later risk, plan the sequenced changes, execute them domain by domain, and validate interoperability and performance before you cut over. It is a loop, not a line — the inventory is continuous and the phases repeat as new systems ship and as NIST standards evolve.

The temptation with post-quantum cryptography (PQC) is to treat it as a swap: find RSA, replace with ML-KEM, done. Real estates do not work that way. Cryptography is embedded in TLS terminators, VPN concentrators, code-signing pipelines, database drivers, firmware, and vendor appliances nobody has opened in years. The migration succeeds or fails on process, and the process is a lifecycle with six distinct phases.

The six phases

  • **Discover** — build a complete, continuous cryptographic inventory: every algorithm, key, certificate, protocol, and library, plus where each is used and what data it protects.
  • **Assess** — for each asset, determine quantum vulnerability (is it RSA/ECC/DH, i.e. broken by Shor's algorithm?) and gather the context you need to judge risk.
  • **Prioritize** — order the work by data shelf life and harvest-now-decrypt-later exposure, not by convenience.
  • **Plan** — turn the priority list into a sequenced roadmap: dependencies, owners, hybrid vs. pure-PQC choices, and rollback paths per domain.
  • **Execute** — make the changes domain by domain (TLS, PKI, data-at-rest, code signing, secrets, identity), one controlled cut-over at a time.
  • **Validate** — prove interoperability and acceptable performance before, during, and after each change; feed exceptions back into the inventory.

The order is not arbitrary. You cannot prioritize what you have not discovered, and you cannot execute safely without a plan that respects dependencies — a certificate authority has to issue PQC-capable certificates before the endpoints that consume them can present them. Skipping discovery to "just start migrating TLS" is the most common way a program stalls: six months in, someone finds a critical system that was never on the map.

Why it is a loop, not a line

Two things keep this cyclical. First, the estate changes: every new service, dependency bump, or acquired company introduces cryptography, so discovery never truly finishes — it runs continuously in CI. Second, the standards themselves are still moving. NIST finalized FIPS 203, 204, and 205 in 2024 and is still standardizing additional signature schemes, so an estate that is "done" today may want a second pass as FN-DSA and other algorithms land. Design the program to be re-run, not to be finished.

Pitfall

Do not let 'assess' collapse into 'discover'

Discovery tells you an endpoint negotiates RSA key exchange. Assessment tells you whether that matters — what data flows over it, how long that data stays sensitive, and whether the asset is externally reachable and therefore harvestable today. Teams that skip the assessment step end up sorting their migration alphabetically by hostname instead of by risk, and burn their first quarter on systems that could have waited.

What each phase hands to the next

Treat the lifecycle as a pipeline of artifacts. Discover produces a CBOM. Assess annotates it with vulnerability and data-context. Prioritize produces a ranked backlog. Plan produces a roadmap with owners and dates. Execute produces change records and updated configuration. Validate produces test evidence and a sign-off. Because each artifact is the input to the next phase, gaps are visible: an unranked asset means assessment is incomplete; an unowned roadmap item means planning is not done.

Read the rest of this playbook as a drill-down into each phase. Start with discovery and inventory, then risk and prioritization, then crypto-agile architecture (which makes execution cheaper), then the by-domain guides, hybrids, testing, and rollout — and keep the reusable checklists and templates beside you as you go.