Post-Quantum Migration Starts With a Map, Not an Algorithm

Start post-quantum migration with a map of services, protected data and dependencies—not a shortlist of replacement algorithms. For each important service, record its owners, data lifetime, lifecycle position, supplier status and plausible cutover path; add algorithm, certificate, protocol and hardware detail when it changes the risk assessment or migration design.

This staged inventory gives enterprise and public-sector security teams an actionable roadmap without waiting for a perfect cryptographic register. It also keeps technical discovery tied to operational decisions: what must move first, which dependencies need investigation and whether the work belongs in a routine upgrade, an in-place migration or a replacement programme.

1. Make the service the first inventory unit

Create one record for each service or operational capability, including externally managed services. Assign both a business owner, who can decide priority and accept risk, and a technical owner, who can obtain evidence and deliver the change.

The first-pass record should contain:

• service purpose and business or mission criticality;
• data handled, where it moves and where it is stored;
• required confidentiality or authenticity lifetime;
• hosting model, exposed interfaces and material dependencies;
• planned retirement or refresh date;
• vendor readiness status and date last checked;
• provisional cutover route, accountable owner and next decision.

This broad record is intentionally different from an exhaustive catalogue of cryptographic components. The UK NCSC migration guidance says early discovery should identify key services, data and system dependencies rather than become a formal register of every individual asset; it calls for deeper cryptographic analysis where directly managed IT or operational technology requires it. For organisations following the UK timetable, the targets are discovery and an initial plan by 2028, the highest-priority migrations and a refined plan by 2031, and completion by 2035, subject to a possible tail of harder-to-migrate technologies.

2. Discover in two passes

Pass one maps services and dependencies. Use architecture repositories, asset and configuration records, data-flow documentation, certificate-management systems, procurement records and interviews with service owners. Trace each service through identity systems, APIs, network controls, databases, code-signing and update processes, backups, hardware roots of trust and managed providers.

For every dependency, record what it supplies, who controls it and whether both ends of the interface can change together. A managed service may not expose its algorithms; a partner may constrain protocol choices; an embedded device may depend on firmware and hardware that cannot be upgraded separately.

Pass two deepens records where detail affects exposure or feasibility. Capture algorithms and key sizes, certificates and chains, protocol versions, cryptographic libraries, key stores, hardware security modules, trust anchors, signing paths and configuration ownership. Prioritise this work for long-lived sensitive data, public-facing exchanges, custom code, PKI, operational technology and suppliers without a credible transition plan.

The two passes reconcile apparently different discovery goals. The G7 Cybersecurity Working Group statement describes a detailed cryptographic inventory as important but also says discovery should be ongoing and iterative, beginning with existing asset data and progressively improving accuracy. A service map is therefore the starting layer, not a substitute for cryptographic detail.

3. Rank data and trust functions before systems

Current system criticality is only one priority signal. Assess the data or trust function against four questions: how damaging disclosure or forgery would be, how long protection must last, whether an adversary could retain the protected material, and how long migration is likely to take.

Long-lived confidentiality can raise priority even when a service is not operationally urgent, because captured encrypted material may retain value. Authenticity has its own lifetime: firmware signatures, software releases, identity credentials and archival records may need to remain trustworthy beyond an application’s normal refresh cycle.

A high, medium or low rating is sufficient when a numerical score would imply unsupported precision. Record a short rationale and review date. “Protects sensitive records for 15 years and depends on non-upgradeable hardware” supports a decision; “uses RSA” merely identifies a component.

4. Assign one of three cutover paths

Once ownership, dependencies and timing are visible, give each in-scope service a provisional route:

• Routine upgrade: a supported vendor or platform will deliver the change through its normal release cycle. Record the expected product version, prerequisites, evidence required and deployment window; an undated roadmap entry is not proof of readiness.
• In-place migration: your organisation controls the application, protocol or infrastructure and can change it without replacing the service. Plan code or configuration changes, certificate and key handling, coexistence, interoperability testing and rollback.
• Re-platform or retire: the service cannot accommodate the required protocol, trust model, software or hardware changes on an acceptable schedule. Connect replacement to lifecycle planning, or set a defensible retirement date and document interim controls.

If the evidence is incomplete, use “investigate” as a temporary status. Name the missing evidence, its owner and a decision deadline rather than assigning a confident but unsupported route.

5. Treat crypto-agility as tested evidence

Crypto-agility is a capability, not a product label. NIST’s definition of crypto-agility covers replacing and adapting cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations.

Turn that definition into questions a test can answer. Can the cryptographic provider or algorithm change without rewriting unrelated business logic? Can policy select approved options centrally? Can keys and certificates be rotated at operational scale? Can telemetry show what was negotiated, and can the service roll back safely?

Attach evidence to each migration record: functional and security results, performance and resource observations, failure behaviour, observability, interoperability with material peers and rollback results. A vendor report can support the record, but it does not establish that your configuration and full dependency chain work together.

6. Move the roadmap through decision gates

1. Scope: approve programme ownership, service boundaries, risk criteria and inventory fields.
2. Map: identify priority services, data flows, suppliers, dependencies and lifecycle dates.
3. Deepen: collect cryptographic detail for long-lived, exposed, custom, constrained or uncertain systems.
4. Decide: assign priority, cutover route, funding need, vendor action and target window.
5. Pilot: use a contained but representative service to produce reusable interoperability and rollback evidence.
6. Execute: migrate in waves and verify cross-system behaviour before each production cutover.
7. Retire: remove obsolete mechanisms after policy, ecosystem support and tested compatibility permit it.

Keep the inventory current when services, vendors, protocols or lifecycle plans change. Begin with a bounded set of critical services, complete their first-pass records and let unresolved dependencies determine where detailed cryptographic discovery starts.

Also read:

• Bitcoin’s HODL Era Is Fraying, but the Data Does Not Show a Great Purge
• A Camera Is Not a Security Plan: When Video Monitoring Earns Its Place
• The Best Business Security System Starts With Risk, Not a Camera Catalog