Planning a Cryptographic Migration
A migration plan turns readiness from an intention into a schedule. This article offers a phased structure, inventory and prioritisation methods, and the questions that decide sequencing.
- Reading time
- 10 min read
- Last reviewed
- 1 Oct 2026
Phase 0: inventory
Nothing can be prioritised that has not been found. The inventory should list every cryptographic algorithm in use, the library and version that implements it, the data it protects, how long that data must remain protected, and who owns the component. Automated scanning of dependencies and TLS configurations helps; it rarely finds application-level signing or custom serialisation, which need a manual review.
The Lattice developer resources include a cryptographic inventory template to start from.
Phase 1: prioritise by exposure and lifetime
Two questions rank most items. First, is the data exposed to harvest-now-decrypt-later? Encrypted traffic and stored ciphertext with long confidentiality requirements rank highest. Second, how hard is the item to change later? On-chain identities and hardware-bound keys are harder to change than a TLS configuration, so their planning should start earlier even if their deadline is later.
- Tier 1: long-lived confidentiality over networks or in storage. Move to hybrid KEMs as soon as libraries and peers support them.
- Tier 2: authentication and signatures that can be rotated centrally (service identities, code signing). Prepare dual-algorithm support.
- Tier 3: user-held keys and on-chain identities. Design the migration path now; execute when the ecosystem supports it.
Phase 2: build agility
Before changing any algorithm, make the system able to change algorithms. Introduce provider interfaces for signing, verification and key establishment. Add algorithm identifiers to stored keys and signatures. Replace hard-coded sizes with values read from the algorithm metadata. Test that a second algorithm can be enabled behind a flag in a staging environment.
This phase delivers value regardless of quantum timelines: it makes routine key rotation and library upgrades safer.
Phase 3: dual support and controlled rollout
Most migrations pass through a period where both old and new algorithms are accepted. For verification, accept both; for signing, choose per context. Track adoption with metrics so that the old algorithm can be retired deliberately. For on-chain systems this phase depends on protocol and wallet support and may be long.
Phase 4: retirement and review
Retire the old algorithm when adoption metrics and policy allow. Remove the code path rather than leaving it dormant. Then review the inventory again: migrations surface dependencies that were missed, and standards will have moved.
Questions that decide sequencing
- Which secrets must still be confidential in ten years?
- Which keys cannot be rotated today, and why?
- Which partners and providers must move before we can?
- What is the cost of accepting two algorithms for an extended period?
- Who owns the plan, and when is it reviewed?
Practical implication
- Run the inventory before anything else and keep it current; it is the artefact every later decision depends on.
- Sequence by exposure and by difficulty of change, not only by deadline.
- Budget for a long dual-support period for anything that depends on external ecosystems.
Limitations
- Phases are a planning aid; real programmes overlap them and iterate.
- Sector-specific regulation may require different timelines than those discussed here.
Sources
- [1]NIST NCCoE: Migration to Post-Quantum Cryptography project (opens in a new tab) · NIST NCCoE
- [2]NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management (opens in a new tab) · NIST
- [3]NIST IR 8547 (initial public draft): Transition to Post-Quantum Cryptography Standards (opens in a new tab) · NIST