Planning a PQC migration: the inventory-first method
Treat post-quantum migration like a well-run vulnerability program: build a complete cryptographic inventory first, classify and prioritize by data lifetime, migrate key exchange before signatures, and gate new code so the vulnerable population stops growing while you work.
Every failed technology migration has the same autopsy: the team started replacing things before they knew what they had. Post-quantum migration is unusually punishing about this, because cryptography hides in more places than any other technical dependency, and missing one usage can undo the confidentiality the whole program was meant to protect.
The fix is to run the migration inventory-first. Here is the sequence.
Phase 0: stop the bleeding
Before migrating anything, stop making the problem bigger. Add a policy gate to new code: no new usages of quantum-vulnerable public-key primitives without an explicit, recorded exception. This is cheap, it is immediately enforceable in CI, and it means the inventory you are about to build has a fixed target instead of a growing one.
Phase 1: inventory everything
Build a CBOM from evidence: source code, configuration, certificates and keystores, and compiled binaries. The binary surface matters more than teams expect, because vendor software and static-linked libraries carry their own cryptography that never appears in your source.
Two disciplines make the inventory trustworthy:
- Evidence per asset. Every entry records where it was found and how, so a skeptical auditor or engineer can verify it.
- Known-unknowns declared. Runtime-selected algorithms and unresolvable binaries are listed as unresolved, not skipped. Your plan needs to see its own blind spots.
Phase 2: classify and rank
Classify each asset against the finalized NIST post-quantum standards: quantum-vulnerable, quantum-safe, or already-weak-classically. Then rank the vulnerable population by two questions:
- How long must the protected data stay secret? Decade-scale data first, because harvest-now-decrypt-later means it is already collectible.
- Is this key establishment or a signature? Key exchange migrates first: recorded traffic falls retroactively when the key exchange breaks. Signatures matter on a slower clock, with the exception of long-lived trust roots, which take years to rotate and deserve early planning.
The output of this phase is not a report. It is a backlog: specific components, in specific services, with target algorithms.
Phase 3: migrate in the boring, correct order
- Key exchange to hybrid schemes first. Combining classical and ML-KEM key encapsulation protects against both a quantum future and any weakness discovered in the new algorithms. Mainstream TLS implementations already ship support.
- Then long-lived encryption at rest. Re-encrypt archives whose confidentiality horizon crosses the quantum threshold.
- Then signatures, starting with code-signing and document-signing roots whose chains take longest to rotate, moving to ML-DSA or SLH-DSA.
- Crypto-agility as the exit criterion. Where you touch code anyway, replace hard-coded algorithm choices with configurable ones, so the next migration is a config change instead of a program.
Phase 4: measure like a program, not a project
The single most useful management artifact is a readiness percentage computed from the live inventory: what fraction of cryptographic assets are quantum-safe, tracked per service and per quarter. It converts an abstract threat into a burn-down chart, it satisfies the regulators who are beginning to ask, and it makes backsliding visible when a new dependency drags vulnerable crypto back in.
Because the inventory regenerates with every build, the number stays honest without anyone maintaining a spreadsheet.
The realistic timeline
For a mid-size estate, expect the inventory phase to take weeks, the ranking days, and the migration years. That is fine. The danger was never that migration takes years; every large migration does. The danger is spending those years without an inventory, discovering the scope at the end, and finding the highest-value data was exposed the whole time.
BOMNexa automates phases 1, 2, and 4: evidence-based cryptographic inventory, per-asset quantum verdicts, and the readiness reporting, all inside your own network. The migration itself stays yours, but it starts from a map instead of a guess.