The Quantum Migration Problem: Can the World Replace Its Cryptography Before It Becomes Obsolete?

Abstract

Post-quantum cryptography (PQC) is often described as an algorithm replacement: remove vulnerable public-key mechanisms and install quantum-resistant alternatives. That description is mathematically convenient but operationally incomplete. Cryptography is embedded in protocols, certificates, software libraries, hardware security modules, firmware, identity systems, cloud services, industrial devices, archival signatures, and supplier relationships. A technically sound algorithm cannot protect an organization if it cannot be negotiated interoperably, deployed within device constraints, validated in its implementation, or maintained throughout the system's lifetime. This research perspective examines the quantum threat to public-key cryptography, the first NIST PQC standards, emerging international migration guidance, and the engineering challenges that turn standardization into a multi-year infrastructure programme. It distinguishes the effects of Shor's and Grover's algorithms, explains harvest-now-decrypt-later risk, and reviews the status of ML-KEM, ML-DSA, SLH-DSA, FN-DSA, and HQC as of 3 November 2026. It compares selected United States, United Kingdom, and European Union guidance without treating national recommendations as universal legal mandates. The article then proposes a Cryptographic Migration Readiness Framework with seven measurable dimensions: inventory coverage, dependency traceability, crypto agility, protocol interoperability, implementation assurance, operational resilience, and governance. A reproducible, resource-tiered audit protocol is offered for universities, public institutions, small and medium-sized enterprises, cloud providers, and critical-infrastructure operators. The framework is a proposal for independent testing, not a validated standard. The central argument is that PQC migration is not a one-time algorithm swap. It is a lifecycle transformation of cryptographic dependencies and trust infrastructure, and its success must be measured by the security and continuity of the systems that depend on cryptography.

Keywords: post-quantum cryptography; quantum computing; ML-KEM; ML-DSA; SLH-DSA; HQC; cryptographic agility; hybrid key establishment; cryptographic inventory; PKI; TLS; cybersecurity migration.

1. Introduction: The algorithm is the easy part

Modern digital infrastructure depends on cryptographic mechanisms that are rarely visible to their users. A browser negotiates a secure connection; a device validates a firmware signature; a cloud service authenticates another service; a certificate authority binds a public key to an identity; a VPN establishes a session; and an archive preserves evidence that a document was signed years earlier. These operations rely on cryptographic algorithms, but they also rely on protocol rules, key management, software implementations, hardware, trust anchors, configuration, and operational processes.

A sufficiently capable, fault-tolerant quantum computer would change the security assumptions behind widely deployed public-key cryptography. Shor's algorithm gives a polynomial-time quantum approach to integer factorization and discrete logarithms, the mathematical problems underlying RSA and elliptic-curve and finite-field public-key systems [1]. That does not mean a quantum computer available today can break deployed RSA or elliptic-curve systems. The relevant threat is a future cryptographically relevant quantum computer (CRQC), and its arrival date remains uncertain. However, uncertainty about timing does not eliminate the need to plan: information encrypted today can remain sensitive after the technology used to protect it becomes vulnerable.

The response is post-quantum cryptography: classical algorithms designed to resist attacks from both classical and quantum computers. NIST finalized its first three principal PQC standards on 13 August 2024: ML-KEM for key establishment, ML-DSA for digital signatures, and SLH-DSA for stateless hash-based signatures [2–4]. These standards are an essential milestone, but publication is not the same as global deployment. The standards must be integrated into protocols, products, certificate ecosystems, validated modules, devices, and operational practice.

This distinction defines the article's central question: how can organizations replace quantum-vulnerable cryptography across complex, interconnected systems without creating new security weaknesses or disrupting essential services?

The argument is that migration should be treated as a lifecycle transformation of cryptographic dependencies, not as a one-time algorithm swap. A successful programme must discover where cryptography is used, understand what depends on it, prioritize according to risk and data lifetime, support algorithm change, test interoperability, validate implementations, and maintain trust through the transition.

This paper is a research perspective. It synthesizes public standards and guidance available by 3 November 2026 and proposes a framework and audit protocol for future research. It does not report a Deaimer deployment, original cryptographic benchmark, or measured migration outcome.

2. What quantum computing changes—and what it does not

2.1 Shor's algorithm and public-key cryptography

Shor's algorithm changes the asymptotic complexity of integer factorization and discrete logarithms on a sufficiently capable quantum computer [1]. RSA security is tied to the difficulty of factoring large integers. Diffie–Hellman and elliptic-curve cryptography rely on discrete-logarithm problems in finite fields or elliptic-curve groups. A CRQC running an adequately fault-tolerant implementation of Shor's algorithm would undermine the mathematical assumptions used by these systems.

The consequences extend beyond confidentiality. Public-key cryptography is also used for authentication, digital signatures, software and firmware signing, certificate chains, secure boot, and identity. If a future attacker can forge signatures under a vulnerable scheme, the problem is not limited to decrypting recorded traffic. Trust decisions that rely on signatures may also be affected, including the authenticity of software, updates, certificates, and archived documents whose verification depends on long-lived public-key assumptions.

A critical qualification is required: the existence of Shor's algorithm is not a forecast of when a CRQC will exist. Estimates depend on the target cryptographic parameters, error-correction overhead, gate fidelity, architecture, circuit optimization, and engineering progress. Resource estimates are conditional models, not a countdown clock. This article therefore does not assign a date to the arrival of a CRQC.

2.2 Grover's algorithm and symmetric cryptography

Grover's algorithm provides a quadratic speedup for unstructured search, rather than the exponential or polynomial-time break of public-key assumptions associated with Shor's algorithm [5]. Its implications for symmetric cryptography and hash functions differ. In simplified terms, an idealized exhaustive search over a key space of size N can be reduced to a number of quantum queries on the order of N^(1/2). This does not mean that every symmetric algorithm is simply “broken in half”: practical quantum attack costs, parallelization, circuit depth, error correction, and implementation constraints matter.

The migration problem is consequently asymmetric. Public-key algorithms based on factoring and discrete logarithms require replacement by quantum-resistant alternatives. Symmetric algorithms and hash functions may instead be assessed for adequate security margins and parameter choices. Organizations should not interpret PQC migration as a requirement to replace every cryptographic primitive at once.

2.3 Harvest now, decrypt later

Harvest-now-decrypt-later (HNDL) describes an adversary collecting encrypted information now with the intention of decrypting it later if a CRQC becomes available. The risk depends on the confidentiality lifetime of the information, not only on the current sensitivity of the network session. A dataset that is harmless after several months may not need the same migration priority as diplomatic, health, biometric, intellectual-property, or long-term identity data that must remain confidential for decades.

A useful prioritization question is therefore: how long must this information remain confidential, and how long will the system that protects it remain in service? If the required confidentiality period plus the migration and procurement lead time approaches or exceeds the estimated time to replace the vulnerable mechanism, migration should be treated as urgent even when no CRQC is available today. The exact risk assessment is organization- and data-specific.

2.4 PQC is not quantum key distribution

PQC uses mathematical problems believed to resist known quantum attacks and can generally be implemented on conventional computing hardware. Quantum key distribution (QKD) uses quantum communication mechanisms and has different infrastructure, distance, trust, and deployment requirements. They are not interchangeable labels for the same technology. The European Commission's 2024 recommendation explicitly discusses coordinated PQC adoption and mentions hybrid approaches that may combine PQC with existing cryptography or QKD in particular contexts [11]. That policy language should not be read as proof that QKD is a universal replacement for cryptographic migration.

3. The first NIST standards: what is finalized and what is not

3.1 ML-KEM: establishing shared secrets

FIPS 203 specifies the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), derived from the CRYSTALS-Kyber submission [2]. A key-encapsulation mechanism allows two parties to establish a shared secret over a public channel. That shared secret is then used with symmetric cryptography to protect communications. FIPS 203 defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024. The standard's security is related to the Module Learning With Errors problem.

A KEM is not itself a general-purpose bulk data encryption algorithm. It establishes key material that is subsequently used by symmetric algorithms. This distinction matters when organizations inventory their systems: replacing a key-establishment mechanism does not automatically replace the record-layer cipher, certificate authentication, signature algorithm, or key lifecycle surrounding it. NIST's SP 800-227 provides additional guidance on KEM properties, applications, and secure implementation [8].

NIST published a planning note in November 2025 identifying an issue in FIPS 203 that is expected to be corrected in a future update or revision [2]. Migration teams should therefore track the current standard, its errata, implementation guidance, and approved validation status rather than pinning an algorithm name without monitoring corrections.

3.2 ML-DSA: lattice-based digital signatures

FIPS 204 specifies the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), derived from CRYSTALS-Dilithium [3]. Digital signatures support integrity, authentication, and evidence about the origin of data. ML-DSA is intended for use in contexts where signature verification is needed, including software distribution, certificates, and authenticated communications as protocol support matures.

Signature migration is operationally different from key-establishment migration. It affects signing keys, verification libraries, certificate formats, signature containers, code-signing workflows, trust stores, and long-term validation. Organizations should not assume that a signature algorithm can be changed without considering the size of signatures, certificate-chain growth, hardware support, timestamping, archival validation, and the systems that consume signed objects.

NIST's publication page records a July 2026 planning note concerning minor issues to be corrected in a future update or revision of FIPS 204 [3]. This reinforces the need for version-aware standards tracking.

3.3 SLH-DSA: stateless hash-based signatures

FIPS 205 specifies the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA), derived from SPHINCS+ [4]. Hash-based signatures offer a different design foundation from lattice-based signatures. Algorithm diversity is valuable in a migration portfolio because it avoids relying entirely on one mathematical family. The trade-off is operational: signature and key sizes, signing performance, verification cost, and use-case suitability differ from ML-DSA. A standard is not automatically the best choice for every constrained or high-throughput system.

3.4 FN-DSA and HQC: selection is not the same as final standardization

NIST selected FALCON for standardization as FN-DSA, with FIPS 206 identified as in development on NIST's PQC project pages as of the research cutoff [6]. It should not be described as a finalized FIPS standard unless the publication status has changed on the official NIST page.

NIST selected HQC for standardization on 11 March 2025 as an additional key-encapsulation mechanism based on code-based cryptography [7]. NIST stated that it would develop a standard and anticipated a process of drafting, public comment, and finalization over approximately two years. As of 3 November 2026, HQC should be described as selected for standardization, not as a finalized FIPS standard. This distinction is important for procurement and deployment decisions.

The NIST project page and individual publication records should be checked at the point of procurement because standardization and errata status can change [2–7].

4. Migration is an international programme, not a single global deadline

4.1 United States: NIST standards and federal transition planning

NIST's IR 8547, Transition to Post-Quantum Cryptography Standards, became final on 27 October 2026 [9]. It describes NIST's approach to transitioning from quantum-vulnerable cryptographic algorithms to PQC digital-signature and key-establishment standards. The final report supports implementation of Executive Order 14412 and OMB Memorandum M-26-15, which direct US federal agencies to prioritize migration of their most sensitive systems [9]. These are US federal policy instruments; they do not automatically create legal obligations for every organization or country.

NIST's CSWP 39-upd1, Considerations for Achieving Crypto Agility: Strategies and Practices, published 29 June 2026, defines crypto agility as the capability to replace and adapt algorithms across protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations [10]. It is particularly useful because it frames migration as an architectural capability rather than a one-off project.

4.2 United Kingdom: an indicative 2028–2035 pathway

The UK National Cyber Security Centre (NCSC) recommends three migration milestones: by 2028, organizations should define goals, complete cryptographic discovery, and create an initial migration plan; by 2031, they should complete the highest-priority migration activities and refine the plan; by 2035, they should aim to complete migration across systems, services, and products [12]. NCSC describes these as guidance and target dates for UK organizations, particularly large organizations, critical national infrastructure operators, and organizations with bespoke IT. It also notes that many SMEs using commodity technology may receive migration through vendor updates, while organizations with custom systems need more active planning [12].

The NCSC highlights two difficult areas: WebPKI, where coordination among roots, certificate authorities, transparency logs, and revocation systems is complex; and industrial control systems, where legacy protocols may lack modern cryptographic architecture [12]. These are important examples of why algorithm availability does not guarantee ecosystem readiness.

4.3 European Union: coordinated Member State planning

The European Commission issued a Recommendation on a Coordinated Implementation Roadmap on 11 April 2024. A high-level roadmap for Member States was published on 23 June 2025, with subsequent survey feedback published in September 2026 [11]. This is a coordinated policy approach intended to align national planning, public administration, and critical infrastructure. It is a recommendation and roadmap, not a single EU-wide technical implementation deadline equivalent to the UK's NCSC milestones.

4.4 Other national and international guidance

Organizations should also monitor guidance from NSA, CISA, ENISA, ETSI, BSI, ANSSI, ISO/IEC, and relevant sector regulators. Their documents differ in scope, legal force, audience, and technical detail. A procurement team should distinguish a binding regulation, a national agency recommendation, a voluntary technical standard, an informational RFC, and a draft protocol. This article does not claim that every jurisdiction has the same timetable or has completed an equivalent national roadmap.

A global organization should maintain a jurisdictional obligations register: which systems are in scope, which regulators or contracts apply, which standards are recognized, and which dates are mandatory versus advisory. The register should be reviewed as national policies and international standards evolve.

5. The engineering reality: discovering cryptography in a living system

5.1 Cryptographic inventory is more than searching for RSA

A migration programme begins with discovery. Cryptographic operations can be embedded in source code, third-party libraries, operating systems, network appliances, cloud services, HSMs, firmware, mobile applications, identity providers, certificate chains, database drivers, backup products, and supplier-managed services. Some use is visible through configuration; other use is indirect or hidden behind APIs.

An inventory should record at least: asset and owner; business service; cryptographic function; algorithm and parameter set; protocol and version; key and certificate lifecycle; data protected; confidentiality lifetime; system replacement date; supplier dependency; hardware constraints; validation status; and migration owner. It should also record confidence and evidence source. An inventory entry inferred from a binary scan is not equivalent to a verified architecture record.

5.2 Dependency graphs and cryptographic bills of materials

A flat list is insufficient where a single certificate authority supports hundreds of services, or where a firmware signing key is embedded in a manufacturing and update process. A dependency graph connects applications, services, libraries, protocols, certificates, devices, vendors, and trust anchors. It helps identify migration bottlenecks and blast radius.

A cryptographic bill of materials (CBOM) can provide structured machine-readable information about cryptographic assets and dependencies. It should be treated as an evolving inventory artifact, not a guarantee that all cryptography has been discovered. Automated scanners can miss dynamic dependencies, managed services, hardware implementations, or cryptographic functions hidden behind proprietary interfaces. Human validation and supplier attestations remain necessary.

5.3 Prioritization by confidentiality lifetime and system lifetime

A practical priority score can combine: sensitivity and confidentiality lifetime of data; exposure to HNDL; value of the asset; public-key dependency; system replacement lead time; supplier readiness; and consequence of a failed migration. A system protecting long-lived secrets may be prioritized even if its current traffic volume is low. A legacy device with a 15-year service life may deserve early attention because a future algorithm update may be impossible after installation.

A proposed risk model should not hide judgment behind one score. Organizations should publish the weights, uncertainty, and non-compensable criteria. For example, an unsupported device that protects high-value long-lived data should not be rated low risk merely because it is rarely used.

6. Crypto agility: designing for the next algorithm change

Crypto agility is the ability to replace cryptographic algorithms and parameters without redesigning the entire system. NIST CSWP 39-upd1 describes strategies and trade-offs for achieving this across software, hardware, firmware, protocols, and infrastructure [10].

An agility-aware design separates cryptographic policy from application logic, uses maintained cryptographic libraries and APIs, avoids hard-coded algorithm assumptions, supports versioned configuration, and provides a controlled way to update keys, certificates, and protocol negotiation. It also includes telemetry: operators need to know which algorithms are actually negotiated and whether legacy fallback is still in use.

Agility is not the same as accepting any algorithm at runtime. An overly flexible negotiation mechanism can create downgrade risks or allow unsupported algorithms to be selected. Algorithm changes must be authenticated, policy-controlled, logged, and tested. A secure migration path should define which combinations are permitted, when legacy modes are disabled, how rollback works, and how emergency revocation is performed.

7. Hybrid cryptography: useful bridge, not magic guarantee

7.1 Why hybrid key establishment is being used

During a transition, systems may combine a traditional key-establishment mechanism with a PQC mechanism. The goal is to preserve security if one component remains secure, subject to the security properties of the construction and its combiner. IETF RFC 9794 defines terminology for post-quantum/traditional hybrid schemes and clarifies that a hybrid scheme combines component algorithms to achieve one cryptographic function [13].

For TLS 1.3, RFC 10024 defines three proposed-standard hybrid key-agreement mechanisms combining ML-KEM with elliptic-curve Diffie–Hellman: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 [14]. Protocol support and implementation availability must still be checked in the actual software and deployment environment.

7.2 What hybrid does not automatically solve

Hybrid deployment is not automatically secure merely because two algorithms are present. Security depends on the combiner, transcript binding, negotiation, authentication, implementation correctness, downgrade handling, and the exact protocol specification. A weak fallback path can reintroduce quantum-vulnerable behavior. A hybrid signature or certificate chain is a different construction from hybrid key establishment; teams should not use the word “hybrid” without specifying which cryptographic function is combined.

Hybrid deployments can also increase message sizes, handshake complexity, CPU and memory use, and interoperability risks. Middleboxes, proxies, older TLS stacks, embedded clients, and fragmented network paths may fail in unexpected ways. These are testable engineering properties, not reasons to reject hybrid schemes categorically.

7.3 A staged protocol strategy

A migration plan should define the intended end state, temporary hybrid configurations, permitted traditional-only fallback conditions, monitoring requirements, and a date or event for retiring the fallback. It should test both peers, the full certificate and trust path, network intermediaries, resumption behavior, and failure recovery. The security objective is not simply to enable a PQC option; it is to establish that the negotiated path provides the intended security properties end to end.

8. The difficult systems: PKI, signatures, devices, and archives

8.1 Public-key infrastructure and certificate ecosystems

PQC signatures can be larger than familiar RSA or elliptic-curve signatures, and certificate chains may grow accordingly. WebPKI migration involves roots, intermediates, leaf certificates, certificate transparency, revocation, browsers, servers, load balancers, and enterprise inspection devices. A technically valid PQC certificate may not be accepted by every component in the chain. NCSC identifies WebPKI as a particularly complex ecosystem to migrate [12].

8.2 Code signing, secure boot, and firmware

Software supply chains depend on signature verification at build, release, installation, and boot. Devices may have immutable trust anchors or limited firmware-update paths. Migration must consider whether a device can verify a new signature algorithm before the old one is removed, whether recovery images remain trusted, and how a compromised signing key is revoked. A signature migration that strands devices can become an availability and safety problem.

8.3 IoT, operational technology, and industrial control

Constrained devices may have limited CPU, memory, flash, bandwidth, energy, and update capability. Industrial systems may have long replacement cycles and safety certification requirements. PQC key and signature sizes can affect message fragmentation, real-time performance, and protocol compatibility. Some legacy OT protocols lack modern key-management architecture, so migration may require redesigning trust and update mechanisms rather than replacing one primitive.

8.4 HSMs, cloud key management, and validated modules

Organizations should confirm algorithm support in their HSMs, cloud key-management services, certificate authorities, key backup and recovery systems, and cryptographic module validation programmes. A library that implements an algorithm does not automatically satisfy a regulated environment's module validation, operational, or certification requirements. Procurement should ask for specific algorithm, parameter-set, protocol, firmware, and validation evidence.

8.5 Long-term signatures and archival trust

A document signed today may need to be verified decades later. Migration therefore includes archival evidence, trusted timestamps, certificate status records, signature formats, and preservation of the verification material needed by future systems. Organizations should distinguish the time when a signature was created from the period during which its authenticity must remain independently verifiable.

9. Implementation security: PQC introduces new engineering risks

PQC changes the mathematical assumptions, but it does not remove conventional implementation risks. Side-channel leakage can expose secrets through timing, power consumption, electromagnetic emissions, or cache behavior. Fault injection can target computations or validation steps. Weak random-number generation can undermine key generation. Incorrect parameter selection, memory handling, encoding, parsing, or error handling can invalidate the security expected from a standard.

Larger keys, ciphertexts, and signatures can create performance and availability problems. A handshake that expands packet sizes may trigger fragmentation or be rejected by network devices. A parser that assumes a legacy maximum length may fail open, crash, or create denial-of-service exposure. Certificate and signature processing can affect latency and resource consumption in high-volume systems.

Supply-chain risk also matters. Organizations need to know where cryptographic code originates, how it is built, which dependencies it includes, how updates are authenticated, and whether the implementation has undergone appropriate review. A standardized algorithm is not the same as a secure implementation. Validation, testing, side-channel review, key management, and operational monitoring remain essential.

10. A proposed Cryptographic Migration Readiness Framework

The following framework is proposed for research and independent evaluation. It is not an official NIST, CISA, NCSC, or Deaimer standard, and it has not been validated through an empirical study.

10.1 Seven dimensions

1. Inventory coverage. What proportion of cryptographic assets and services has been discovered, verified, and assigned an owner? Candidate measures include percentage of in-scope services inventoried, percentage with verified algorithm and protocol data, and percentage of unknown dependencies resolved.

2. Dependency traceability. Can an organization trace each cryptographic dependency through applications, protocols, certificates, suppliers, devices, and data flows? Candidate measures include dependency-graph completeness, percentage of critical paths with mapped trust anchors, and number of unowned or undocumented dependencies.

3. Crypto agility. Can the organization change an algorithm or parameter through controlled configuration and deployment rather than bespoke code rewrites? Candidate measures include time to replace a test algorithm, number of applications requiring source changes, rollback success, and percentage of cryptographic functions accessed through approved interfaces.

4. Protocol interoperability. Do systems negotiate approved PQC or hybrid configurations across realistic client/server combinations and network paths? Candidate measures include successful handshake rate, fallback frequency, certificate-chain acceptance, packet fragmentation rate, and cross-vendor compatibility.

5. Implementation assurance. Are cryptographic implementations maintained, reviewed, tested, and validated for the intended use? Candidate measures include implementation provenance, conformance results, side-channel review coverage, module validation status where required, and time to remediate identified defects.

6. Operational resilience. Can the organization migrate without unacceptable service interruption or loss of trust? Candidate measures include tested rollback, key recovery, certificate renewal, firmware update success, monitoring coverage, incident response readiness, and recovery time.

7. Governance and lifecycle ownership. Are migration decisions assigned, funded, monitored, and reviewed? Candidate measures include accountable owners, supplier commitments, approved risk exceptions, policy review cadence, and evidence that sunset dates are enforced.

10.2 Why a single score is not recommended initially

A composite score can conceal a critical weakness. A company might have an excellent inventory and governance process but no compatible certificate path for its most sensitive service. The framework should initially report a multidimensional profile and identify blocking conditions. Weights and thresholds should only be introduced after studies demonstrate that they predict meaningful migration outcomes across sectors.

11. A reproducible cross-sector audit methodology

This proposed methodology is intended to be independently replicated by universities, SMEs, public agencies, cloud providers, and critical-infrastructure operators. It should be preregistered where practical and conducted only on systems for which the research team has authorization.

11.1 Research questions

• RQ1: Which inventory techniques identify the largest proportion of cryptographic dependencies, and what classes of dependencies remain invisible?
• RQ2: Does crypto-agile architecture reduce the time, cost, and defect rate of changing cryptographic algorithms compared with tightly coupled implementations?
• RQ3: How do hybrid PQ/T protocol deployments affect interoperability, latency, bandwidth, memory, and failure behavior across heterogeneous clients and networks?
• RQ4: Which implementation assurance practices detect the most consequential PQC-specific defects?
• RQ5: Which organizational factors predict successful migration of legacy and constrained systems?

11.2 Threat model and system selection

Define the adversary and objective: passive collection for future decryption; active network manipulation; downgrade attempts; malicious or compromised suppliers; side-channel attackers with physical or local access; and attackers targeting migration tooling or key-management processes. Do not assume all adversaries have the same capability. Select representative systems across at least three classes: commodity IT, custom enterprise systems, and constrained or long-lived devices.

11.3 Test environment

Build a controlled testbed with a traditional cryptographic baseline, a PQC-enabled configuration, and a hybrid configuration where protocol support exists. Record exact library versions, operating systems, hardware, compiler settings, parameter sets, protocol versions, certificates, and network conditions. Use synthetic data and test keys. Do not test against production services without explicit authorization.

11.4 Measurements

Record inventory coverage; dependency resolution; time and engineering effort to migrate; CPU and memory use; key, ciphertext, signature, and certificate sizes; handshake latency; throughput; fragmentation; interoperability success; fallback behavior; failure recovery; and defects discovered. For constrained devices, include energy consumption and update success. For archives and signatures, include verification across software versions and time-stamped evidence preservation.

11.5 Comparison design

Compare a tightly coupled implementation with an agility-aware implementation under the same migration change. Compare traditional-only, PQC-only, and hybrid protocol configurations where standardized support is available. Repeat tests across multiple hardware classes and software versions. Use multiple independent runs, report medians and dispersion, and publish raw denominators for interoperability and failure rates. Report confidence intervals where sample sizes support them.

11.6 Resource tiers for international reproducibility

Tier A — Desktop and university lab: inventory exercises, open-source library integration, test certificates, local TLS handshakes, and software-only performance measurement.

Tier B — SME and enterprise testbed: dependency mapping across applications, identity systems, proxies, VPNs, and cloud services; controlled hybrid interoperability tests; supplier evidence review.

Tier C — Critical infrastructure and device lab: HSMs, firmware signing, constrained IoT, OT protocol gateways, long-lived roots of trust, and safety-reviewed update/rollback exercises.

A study should publish the tier it actually completed. A Tier A software test must not be presented as evidence that an industrial controller or national PKI has been migrated safely.

11.7 Validity threats and ethics

Inventory scanners can produce false positives and false negatives. Supplier attestations may be incomplete. Benchmark results can be specific to one implementation or network path. Performance comparisons can be distorted by compiler, hardware, and configuration differences. A migration-readiness score may reflect organizational documentation rather than actual deployed state. Researchers should separate observed evidence from self-reported claims, preserve negative results, and disclose missing data. Security testing must use synthetic keys and authorized systems; publication should not expose exploitable implementation details without responsible disclosure.

12. Research directions for 2027–2028

Several research questions are likely to remain important as standards and product support mature. These are research directions, not predictions that a particular technology or deadline will succeed.

Automated cryptographic discovery. Improve static, dynamic, binary, and network-based discovery while quantifying blind spots and confidence. Research should test whether CBOMs remain accurate as applications and suppliers change.

Crypto-agility assurance. Develop repeatable tests that demonstrate algorithm replacement, policy enforcement, rollback, and resistance to downgrade or configuration drift.

Hybrid interoperability. Study hybrid key establishment and signature migration across browsers, servers, proxies, VPNs, cloud environments, mobile platforms, and constrained networks. Distinguish protocol-standard conformance from ecosystem compatibility.

PQC for constrained devices and OT. Measure memory, bandwidth, energy, latency, firmware size, and update reliability for long-lived devices. Explore gateway and architecture migration where direct device replacement is impractical.

Long-term signatures and archival trust. Develop methods for preserving signature validity, timestamp evidence, certificate histories, and trust metadata over decades.

Implementation side-channel resilience. Compare implementation strategies, constant-time behavior, fault resistance, entropy sources, and validation processes across hardware platforms.

Supply-chain assurance. Study cryptographic provenance, reproducible builds, dependency tracking, supplier evidence, and secure distribution of validated implementations.

Governance and migration economics. Develop cross-sector models for prioritizing systems by data lifetime, system lifetime, dependency complexity, and replacement cost without assuming that one national roadmap fits all.

13. Practical recommendations for organizations

Organizations do not need to design their own cryptographic algorithms. Most should use maintained, standards-aligned implementations from trusted providers and follow applicable national and sector guidance. The practical sequence is:

1. Establish ownership and executive sponsorship for a PQC migration programme.
2. Discover cryptographic use across software, hardware, services, suppliers, and data flows.
3. Classify protected data by confidentiality lifetime and system replacement horizon.
4. Map dependencies, certificates, trust anchors, key lifecycles, and vendor commitments.
5. Prioritize high-value long-lived data, externally exposed services, and long-lived devices.
6. Design crypto agility and a controlled transition policy, including hybrid use where appropriate.
7. Test interoperability, performance, fallback, rollback, and operational failure modes.
8. Validate implementations and update procurement, development, and supplier requirements.
9. Monitor standards, errata, protocol status, and product support continuously.
10. Retire vulnerable mechanisms only after dependencies and trust paths have been migrated and tested.

For SMEs using commodity technology, much of the migration may arrive through operating-system, browser, cloud, and vendor updates. They should still maintain an inventory of custom applications, VPNs, identity services, and long-lived data. Large organizations and critical-infrastructure operators should expect a more substantial discovery and dependency-management effort, consistent with NCSC's guidance [12].

14. Conclusion: migration is a test of institutional agility

The quantum threat to public-key cryptography is grounded in established quantum algorithms, but the arrival date of a cryptographically relevant quantum computer remains uncertain. That uncertainty is not a reason to delay all preparation. Data collected today may need confidentiality long after a future CRQC becomes possible, and systems with long replacement cycles cannot be migrated at the last moment.

NIST's first PQC standards provide a practical foundation. ML-KEM, ML-DSA, and SLH-DSA are finalized standards, while FN-DSA and HQC have distinct development statuses that organizations must track carefully. US federal transition guidance, UK NCSC milestones, and the EU coordinated roadmap demonstrate that migration is already an institutional planning issue, but their legal force and timelines differ.

The most difficult work lies in the systems around the algorithms: discovering hidden cryptographic dependencies, coordinating certificates and protocols, upgrading firmware and constrained devices, maintaining interoperability, validating implementations, and ensuring that rollback and recovery remain possible. Hybrid schemes can support transition, but only when their construction and protocol behavior are carefully specified and tested.

The proposed Cryptographic Migration Readiness Framework offers a way to study these challenges across sectors and countries. Its value remains to be tested. Future work should determine whether its dimensions predict migration outcomes, whether automated inventory can be trusted, and which agility practices reduce risk without imposing unnecessary operational cost.

The central lesson is straightforward: post-quantum security will not be achieved merely when an organization selects a new algorithm. It will be achieved when the entire system can adopt, verify, operate, and maintain that algorithm securely.

Research limitations and disclosure

This article is a research perspective and proposed methodology, not a peer-reviewed empirical migration study. It synthesizes public primary and institutional sources available by 3 November 2026. National roadmaps, standards, errata, protocol documents, and product support may change. The proposed Cryptographic Migration Readiness Framework and audit methodology have not been empirically validated, and no Deaimer migration audit, customer deployment, partnership, or cryptographic performance result is claimed. The bibliography prioritizes NIST, government agencies, the European Commission, IETF, and standards-related primary sources. It is not an exhaustive review of every national policy, commercial product, or academic PQC implementation paper.

References

[1] P. W. Shor, “Algorithms for Quantum Computation: Discrete Logarithms and Factoring,” Proceedings of the 35th Annual Symposium on Foundations of Computer Science, 1994. https://doi.org/10.1109/SFCS.1994.365700

[2] National Institute of Standards and Technology (NIST), FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard, 13 August 2024. https://doi.org/10.6028/NIST.FIPS.203

[3] NIST, FIPS 204: Module-Lattice-Based Digital Signature Standard, 13 August 2024. https://doi.org/10.6028/NIST.FIPS.204

[4] NIST, FIPS 205: Stateless Hash-Based Digital Signature Standard, 13 August 2024. https://doi.org/10.6028/NIST.FIPS.205

[5] L. K. Grover, “A Fast Quantum Mechanical Algorithm for Database Search,” Proceedings of the 28th Annual ACM Symposium on Theory of Computing, 1996. https://doi.org/10.1145/237814.237866

[6] NIST, “Post-Quantum Cryptography Standardization,” project status page, accessed 3 November 2026. https://csrc.nist.gov/projects/post-quantum-cryptography

[7] NIST, IR 8545: Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process, March 2025; and “HQC Announced as a 4th Round Selection,” 11 March 2025. https://doi.org/10.6028/NIST.IR.8545 ; https://csrc.nist.gov/news/2025/hqc-announced-as-a-4th-round-selection

[8] NIST, SP 800-227: Recommendations for Key-Encapsulation Mechanisms, 18 September 2025. https://doi.org/10.6028/NIST.SP.800-227

[9] D. Moody, R. Perlner, A. Regenscheid, A. Robinson, and D. Cooper, NIST, IR 8547: Transition to Post-Quantum Cryptography Standards, final, 27 October 2026. https://doi.org/10.6028/NIST.IR.8547

[10] E. Barker et al., NIST, CSWP 39-upd1: Considerations for Achieving Crypto Agility: Strategies and Practices, final, 29 June 2026. https://doi.org/10.6028/NIST.CSWP.39-upd1

[11] European Commission, Recommendation on a Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, 11 April 2024; and A Coordinated Implementation Roadmap, 23 June 2025. https://digital-strategy.ec.europa.eu/en/library/recommendation-coordinated-implementation-roadmap-transition-post-quantum-cryptography ; https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

[12] UK National Cyber Security Centre, Timelines for Migration to Post-Quantum Cryptography, published 2025, current guidance accessed 3 November 2026. https://www.ncsc.gov.uk/guidance/pqc-migration-timelines

[13] F. Driscoll, M. Parsons, and B. Hale, IETF, RFC 9794: Terminology for Post-Quantum Traditional Hybrid Schemes, June 2025. https://www.rfc-editor.org/rfc/rfc9794

[14] K. Kwiatkowski, P. Kampanakis, B. E. Westerbaan, and D. Stebila, IETF, RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3, 2026. https://www.rfc-editor.org/rfc/rfc10024

[15] NIST, CSWP 39: Considerations for Achieving Cryptographic Agility: Strategies and Practices, superseded by CSWP 39-upd1 on 29 June 2026. https://csrc.nist.gov/pubs/cswp/39/considerations-for-achieving-cryptographic-agility/final

[16] NIST, IR 8547: Transition to Post-Quantum Cryptography Standards, initial public draft, 12 November 2024; superseded by final version 27 October 2026. https://csrc.nist.gov/pubs/ir/8547/ipd

[17] NIST, SP 800-133 Rev. 3: Recommendation for Cryptographic Key Generation, initial public draft, 17 April 2026. https://csrc.nist.gov/projects/post-quantum-cryptography/publications

[18] NIST, SP 800-230: Additional SLH-DSA Parameter Sets for Limited Signature Use Cases, initial public draft, 13 April 2026. https://csrc.nist.gov/projects/post-quantum-cryptography/publications

[19] NIST, “Announcing Approval of Three Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography,” 13 August 2024. https://csrc.nist.gov/News/2024/postquantum-cryptography-fips-approved

[20] NIST, “Considerations for Achieving Crypto Agility: Strategies and Practices,” publication record, 29 June 2026. https://www.nist.gov/publications/considerations-achieving-crypto-agility-strategies-and-practices-0

[21] UK NCSC, “Setting Direction for the UK's Migration to Post-Quantum Cryptography,” migration guidance background. https://www.ncsc.gov.uk/blog-post/setting-direction-uk-migration-to-pqc

[22] UK NCSC, NCSC Annual Review 2025, chapter on migration to post-quantum cryptography. https://www.ncsc.gov.uk/collection/ncsc-annual-review-2025/chapter-03-keeping-pace-with-evolving-technology/migrating-to-post-quantum-cryptography

[23] European Commission, EU Roadmap on Post-Quantum Cryptography – Survey Feedback, 2 September 2026. https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

[24] NIST, Post-Quantum Cryptography: Publications and Standardization Status, project publications page, accessed 3 November 2026. https://csrc.nist.gov/Projects/post-quantum-cryptography/publications

[25] NIST, FIPS 203 publication record and errata notice, accessed 3 November 2026. https://csrc.nist.gov/pubs/fips/203/final

[26] NIST, FIPS 204 publication record and errata notice, accessed 3 November 2026. https://csrc.nist.gov/pubs/fips/204/final

[27] NIST, FIPS 205 publication record, accessed 3 November 2026. https://csrc.nist.gov/pubs/fips/205/final

[28] NIST, “HQC Announced as a 4th Round Selection,” 11 March 2025. https://csrc.nist.gov/News/2025/hqc-announced-as-a-4th-round-selection

[29] IETF, RFC 9794: Terminology for Post-Quantum Traditional Hybrid Schemes, informational RFC, June 2025. https://datatracker.ietf.org/doc/html/rfc9794

[30] IETF, RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3, proposed standard, 2026. https://www.rfc-editor.org/info/rfc10024

[31] ETSI, TR 103 949 V1.1.1: Quantum-Safe Cryptography Migration; ITS and C-ITS Migration Study, May 2023. https://www.etsi.org/deliver/etsi_tr/103900_103999/103949/01.01.01_60/tr_103949v010101p.pdf

[32] NIST, CSWP 39-upd1, full PDF, 29 June 2026. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.39-upd1.pdf

[33] NIST, IR 8547, final publication record and history, 27 October 2026. https://csrc.nist.gov/pubs/ir/8547/final

[34] NIST, SP 800-227, final publication record, 18 September 2025. https://csrc.nist.gov/pubs/sp/800/227/final