Post-quantum migration readiness checklist

Every post-quantum migration begins with the same unglamorous problem: nobody knows where all the cryptography is. This checklist walks the inventory-first method that turns the migration into ordinary, ordered engineering work. The threat timeline is uncertain, but the deadline is not set by the hardware - it is set by how long your data must stay secret plus how long migration takes, which for most organizations means starting now.

Work through it in order; the phases depend on each other.

Stop the growth

• Have you gated new code against introducing new uses of quantum-vulnerable public-key cryptography, so the population you must migrate stops growing while you plan?

Build the inventory

• Do you have a complete cryptographic inventory generated from real artifacts - source, configuration, certificates and keys, and compiled binaries - not from what teams remember using?
• Does it cover the binary and vendor-software surface, where the oldest and weakest algorithms often hide?
• Are cryptographic assets the tooling could not resolve declared as known-unknowns, so the inventory’s completeness is honest?
• Does the inventory regenerate with every build, so it stays current instead of decaying?

Classify

• Is every asset classified against the finalized NIST post-quantum standards - quantum-vulnerable, quantum-safe, or weak-regardless?
• Do you understand the scope boundary: public-key cryptography (RSA, elliptic curve, Diffie-Hellman) is the target; symmetric cryptography at adequate key sizes largely survives?

Prioritize

• Is the vulnerable population ranked by the confidentiality lifetime of the data each asset protects, so long-lived secrets migrate first?
• Have you accounted for harvest-now-decrypt-later - long-lived data encrypted today is already collectible for future decryption?
• Are key-establishment mechanisms prioritized ahead of signatures, since recorded traffic falls retroactively when key exchange breaks?
• Are long-lived trust roots (code-signing, document-signing) flagged early, because their chains take years to rotate?

Migrate in order

• Are you moving key exchange to hybrid schemes first, combining a classical and a post-quantum algorithm to hedge both threats at once?
• Are you re-encrypting long-lived data at rest whose confidentiality horizon crosses the quantum threshold?
• Where you touch code anyway, are you replacing hard-coded algorithm choices with configurable ones, so the next migration is a config change rather than a program?

Measure

• Do you track a readiness number - the fraction of cryptographic assets that are quantum-safe, per service, per quarter - computed from the live inventory?
• Does that number stay honest automatically, so a new dependency dragging vulnerable crypto back in is visible?

The realistic timeline

Expect the inventory to take weeks, the ranking days, and the migration years - that is normal for any large migration. The danger was never that it takes years; it is spending those years without an inventory, discovering the scope at the end, and finding the highest-value data was exposed the whole time.

The inventory is a CBOM, the readiness verdict is a QBOM, the method is detailed in planning a PQC migration, and if you want the inventory generated from your own artifacts, request a demo.