Future Technology Watch

Scope, date, and evidence method

This article is a dated primary-source desk review of the cited source set cited for Future Technology Watch. It is not an original survey, forecast model, market-size estimate, or the organization measurement of organizational behavior. The review compares passages from primary government and standards-oriented sources: NIST materials on PQC, the joint CISA/NSA/NIST quantum-readiness fact sheet, the NIST Cybersecurity Framework (CSF) 2.0, the NIST AI Risk Management Framework, the UK National Cyber Security Centre (NCSC) migration guidance, and the cited OWASP CycloneDX passage. The source metadata identifies publication dates, versions, and status; those details are retained where they affect interpretation.145

The evidence method is deliberately narrow. First, observations are separated from inferences. An observation is a statement directly made in a cited passage, such as the release of NIST’s first three finalized PQC standards in 2024. An inference is a practical interpretation, such as the conclusion that organizations should make cryptographic discovery a current planning activity. Second, claims are limited to what the passages support. Third, missing evidence is recorded rather than filled with assumptions. The cited source set includes current, final, and updated documents, including NIST CSWP 39 Update 1, published December 19, 2025 and updated June 29, 2026; this review does not resolve any issue beyond the cited text.62

What the evidence says about the technology horizon

NIST describes quantum computers as machines that may be years or decades away but could eventually break many widely used cryptographic systems. The cited NIST overview explains that conventional encryption has protected confidential electronic information against conventional computing attacks, while a sufficiently capable quantum computer could make some of those protections vulnerable. Post-quantum encryption algorithms are presented as methods intended to resist attacks from both conventional computers and future quantum computers. This is a technology-risk statement, not a timetable: the evidence identifies a future threat and a need for preparation, but does not provide a date or probability for a cryptographically relevant quantum computer.1

The strongest implementation signal in the cited source set is the status of NIST standardization. The NIST project passage says that the principal three PQC standards were released in 2024. It identifies FIPS 203 as the Module-Lattice-Based Key-Encapsulation Mechanism Standard, FIPS 204 as the Module-Lattice-Based Digital Signature Standard, and FIPS 205 as the Stateless Hash-Based Digital Signature Standard. The same passage says NIST is developing additional standards as backups or alternatives. Another project passage states that ML-KEM, ML-DSA, and SLH-DSA can and should be put into use now, while Falcon and HQC were selected for ongoing standardization. This coexistence of finalized standards and continuing evaluation is important: implementation can begin, but the standardization landscape is not portrayed as closed.21

Readiness is an operating discipline, not a single product decision

The joint CISA, NSA, and NIST guidance recommends establishing a quantum-readiness roadmap and a project-management team to plan and scope migration. It calls for proactive cryptographic discovery covering systems and assets that rely on quantum-vulnerable cryptography, including assets involved in creating and validating digital signatures and software or firmware updates. The guidance also emphasizes that organizations are often unaware of the breadth of application and functional dependencies on public-key cryptography in products, applications, and services. The implication is that readiness begins with visibility and ownership, not with selecting an algorithm in isolation.3

A cryptographic inventory should connect technology to business consequence. The joint guidance says the inventory should provide visibility into how cryptography is used in IT and OT systems and should identify vulnerable algorithms in network protocols and assets on end-user systems and servers, including applications and associated libraries. It also says that inventorying quantum-vulnerable technology alongside data criticality helps organizations begin risk assessment and prioritize migration. The cited NIST CSF 2.0 supports this structure through asset-management outcomes: inventories of hardware, software, services, systems, network communications and data flows, and supplier-provided services are maintained; assets are prioritized according to classification and criticality.35

This produces a useful distinction between discovery and decision. Discovery asks where cryptography exists, what algorithms and dependencies are present, which systems or suppliers control change, and what data or processes are protected. Decision asks which services should move first, what migration route is feasible, what continuity constraints apply, and how risk acceptance will be governed. The evidence supports both activities, but it does not supply a universal prioritization formula. Any ranking used by an organization would therefore be an internal risk-management choice, informed by data criticality, exposure, service lifetime, dependency constraints, and replacement cycles.53

Migration planning: sequence, continuity, and supplier dependency

The NCSC describes migration to PQC as a mass technology change that will take a number of years. Its guidance is aimed principally at technical decision-makers and risk owners in large organizations, critical national infrastructure operators, including industrial control systems, and companies with bespoke IT. It says sectors differ in cryptographic maturity and that the weight of activities may vary. The guidance identifies a milestone by 2028 to define migration goals, conduct a full discovery exercise, and build an initial plan. That date is an NCSC target in the cited guidance, not evidence that every organization must have completed migration by then.4

The NCSC says a migration plan should cover priority services processing the most valuable or long-lived data, dependencies on long-lived hardware, supply chains and service providers, and risks from legacy systems. Activities may include researching technology options, procurement, commissioning, testing, backup and data migration, and rollout. Plans should also address business continuity, acceptable outage levels, and rollback if difficulties occur. Operational technology and extensive physical infrastructure require particular attention because infrequent replacement cycles constrain the timing of change. These details make migration a lifecycle and resilience program rather than a one-time cryptographic substitution.4

The cited NCSC passage distinguishes several approaches. Where an organization relies entirely on commodity platforms, PQC upgrades may be delivered by the service provider through routine, timely refresh of commodity hardware such as laptops, phones, servers, and routers. Where technology is not commodity-based, options include in-place migration, replatforming to a PQC-compatible platform, or retiring a service. The evidence does not say that one approach is generally superior. It supports selecting an approach system by system, based on architecture, service value, hardware dependency, provider responsibility, and continuity requirements.4

Supplier engagement is a repeated theme. The joint fact sheet recommends engaging technology vendors about quantum-readiness roadmaps, including migration plans, testing timelines, and product integration. It applies to on-premises commercial off-the-shelf products and cloud-based products and recommends understanding how providers intend to enable PQC through configuration changes or application updates. The guidance also calls for attention to future contracts and expected migration costs. This is consistent with the NIST CSF 2.0 treatment of cybersecurity supply-chain risk management, which includes supplier services, third parties, lifecycle oversight, and integration with enterprise risk management.35

Governance, crypto agility, and adjacent frameworks

The NIST CSF 2.0 organizes cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. The cited passages describe identifying and prioritizing assets, protecting data and platforms, detecting and analyzing possible attacks, responding to incidents, and restoring affected operations. For future technology watch, this provides a governance frame: emerging-technology risk should be connected to asset management, risk assessment, protection, resilience, incident response, recovery, and improvement rather than managed as a separate technical forecast.5

The cited NIST CSWP 39 Update 1 metadata identifies a document on achieving crypto agility, published December 19, 2025 and updated June 29, 2026. The evidence passage defines crypto agility as capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, and firmware. Within this review, crypto agility is best understood as an architectural and lifecycle consideration: systems that can accommodate change may reduce the disruption of future cryptographic transitions. The cited passages do not provide a maturity model, test method, cost estimate, or proof that any particular architecture is agile.6

The NIST AI RMF passages establish a separate but relevant governance pattern. The framework is described as voluntary and intended to improve the incorporation of trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems. It was developed through a consensus-driven, open, transparent, collaborative process with requests for information, drafts, public comments, and workshops. This does not establish a technical connection between AI and PQC. It does show that the cited evidence treats future-technology governance as an ongoing, participatory risk-management activity rather than as a one-off prediction.7

Practical implications for a future technology watch function

A practical watch function can turn the evidence into a repeatable review cycle. Start by recording the status and date of relevant primary sources, distinguishing finalized standards from drafts, ongoing standardization, guidance, and commentary. Then maintain a technology register that links each development to affected assets, suppliers, data lifetimes, implementation dependencies, and decision owners. For PQC, the first operational question is not “When will the quantum computer arrive?” but “Where would a future cryptographically relevant quantum computer create material exposure, and how long would migration take?” This formulation is an inference from the cited readiness and migration guidance.314

1. Establish accountable ownership across cybersecurity, architecture, procurement, IT, OT, privacy or risk management, and relevant business services.
2. Create or improve a cryptographic inventory covering algorithms, protocols, certificates or keys where applicable, applications, libraries, hardware, firmware, data flows, and suppliers.
3. Classify protected data and services by criticality, sensitivity, exposure, and expected lifetime; use those characteristics to inform migration sequencing.
4. Ask vendors and cloud providers for quantum-readiness roadmaps, testing plans, upgrade paths, configuration requirements, support periods, and expected customer effort.
5. Pilot and test migration paths in representative environments, including interoperability, performance, operational procedures, backup, rollback, and continuity.
6. Review contracts, procurement requirements, architecture standards, and lifecycle plans so that future technology change is considered before long-lived dependencies are acquired.
7. Report progress as evidence-backed status: discovered, assessed, prioritized, in test, provider-dependent, migrated, retired, or unresolved.

The watch function should also preserve uncertainty. The cited sources support immediate preparation, but they do not quantify the cost of migration, the performance of each algorithm in a particular environment, the percentage of organizations that have completed inventories, or the likelihood and date of a cryptographically relevant quantum computer. Those omissions are decision-relevant. They mean that a responsible review can recommend discovery and planning without presenting an unsupported deadline, adoption rate, return on investment, or technology winner.1

Missing, conflicting, and limiting evidence

The cited source set is consistent on the direction of travel: future quantum computing is described as a threat to some current cryptographic systems; NIST finalized three principal PQC standards in 2024; and government guidance encourages organizations to begin discovery, prioritization, vendor engagement, and migration planning. It is not a complete market or implementation dataset. It contains no primary-source survey results on enterprise adoption, no inventory statistics, no comparative deployment benchmarks, and no quantified migration-cost or performance study.213

There are also scope and version limitations. The NIST PQC overview is dated August 13, 2024 and marked current in the source metadata. The joint quantum-readiness fact sheet is dated August 17, 2023. The NCSC migration guidance is dated March 20, 2025 and marked current, while the NIST CSF 2.0 is dated February 26, 2024. The NIST CSWP 39 Update 1 record is marked final, published December 19, 2025, and updated June 29, 2026. These dates should not be collapsed into a single undated “current view.” The source set also includes an OWASP CycloneDX passage that identifies the project as vendor-neutral and provided without warranty; the cited excerpt does not establish a PQC adoption metric or a specific inventory implementation result.14562

Finally, this review does not infer that finalized standards are universally deployable without engineering work, that every vendor will meet a particular timeline, or that every organization faces the same urgency. NCSC explicitly notes differences in sectoral cryptographic maturity, and its guidance distinguishes commodity platforms from bespoke and operational technology environments. The appropriate conclusion is conditional: the case for discovery and planning is supported broadly, while the order, cost, design, and timing of implementation remain organization- and system-specific.43

Conclusion

The closed primary-source evidence supports a disciplined Future Technology Watch posture: monitor authoritative standards and guidance, record dates and document status, identify dependencies, and convert credible signals into risk-owned plans. For PQC, the evidence is sufficiently mature to justify cryptographic discovery, prioritization, supplier engagement, testing, and migration planning now. It is not sufficient to justify a precise quantum-computer timetable, universal migration deadline, adoption statistic, cost estimate, or claim that one implementation path fits all environments. Readiness therefore means acting on known dependencies while documenting what remains uncertain.134