Annual QuantumGenie Industry Outlook

Scope, date, and evidence method

This article is a dated primary-source desk review assembled from the cited source set. It synthesizes current or final materials identified as coming from NIST, CISA, NSA, the UK National Cyber Security Centre (NCSC), and the OWASP Foundation. The sources include publication dates where cited: NIST’s PQC overview is dated August 13, 2024; the joint CISA, NSA, and NIST fact sheet is dated August 17, 2023; NIST CSWP 29 is dated February 26, 2024; the NCSC migration-timelines material is dated March 20, 2025; and NIST CSWP 39 Update 1 is marked published December 19, 2025 and updated June 29, 2026. The cited bundle does not provide a single “as of” date for this review, so these dates are preserved rather than collapsed into one publication date. [C1, C4, C5, C6, C7]13524

The method was deliberately documentary: compare statements about standards, migration, inventories, crypto agility, governance, and supply-chain visibility; retain the source’s uncertainty; and distinguish direct observations from implications for organizations. The evidence is authoritative and primary in the cited metadata, but it is not a representative industry survey, financial forecast, vendor census, or independently validated measurement of implementation progress. The review therefore quantifies only figures explicitly present in the sources—for example, NIST’s reported assessment of 82 algorithms from 25 countries and its earlier reference to 69 candidate algorithms—and does not infer adoption percentages from guidance documents. [C8, C9]2134

What the sources say is changing

The strongest observable industry signal is the movement of PQC from algorithm selection into standards-based migration. NIST says its PQC effort addresses the future threat that sufficiently capable quantum computers could eventually break widely used cryptographic systems. Following a multiyear international competition involving industry, academia, and governments, NIST released three principal PQC standards in 2024 and is developing additional standards as backups or alternatives. The cited project material identifies FIPS 203 as ML-KEM for key establishment, FIPS 204 as ML-DSA for digital signatures, and FIPS 205 as SLH-DSA for stateless hash-based digital signatures. [C2, C9]1

The standardization process itself is an important observation about how confidence is being built: NIST describes open evaluation, multiple rounds of analysis, and participation by cryptographers from around the world. The overview reports that 82 algorithms from 25 countries were assessed, while another passage describes 69 candidate algorithms submitted by experts from dozens of countries and subsequently analyzed. These figures refer to stages or descriptions within the selection process; they should not be treated as a count of deployable products or a market-share denominator. [C8, C1]2

The evidence also shows that standardization is continuing rather than ending with the first three FIPS publications. NIST’s project material says Falcon and HQC were selected for ongoing standardization, alongside a longer-term effort concerning additional digital-signature schemes. That supports an inference that organizations should plan for a standards ecosystem that can evolve, rather than hard-code a one-time cryptographic decision. The inference is consistent with NIST’s separate description of crypto agility as the capability to replace and adapt algorithms across protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. [C10, C11]15

Why preparation is treated as urgent

The cited sources do not give a reliable date for a cryptographically relevant quantum computer. They do, however, explain why organizations may need to act before such a machine exists. NIST describes “harvest now, decrypt later” as the collection of encrypted information today for possible decryption in the future, particularly where secrets remain valuable for many years. CISA, NSA, and NIST likewise warn that adversaries could target data now that still requires protection later. This is a risk rationale, not evidence that a particular adversary has obtained a particular dataset. [C12, C13]23

The affected technology surface is broader than a single encryption library. The evidence names public-key systems and examples including RSA, ECDH, and ECDSA, and it directs organizations to consider applications, networking and communications hardware, managed mobile devices, servers and workstations, IoT and industrial-control devices, end-user devices and tokens, field sensors, cloud services, and supplier technologies. NCSC cautions that an initial understanding need not be a formal asset register; understanding the nature and scale of systems, versions, patch levels, and dependencies is enough to begin planning. [C13, C14]4

A practical implication follows: prioritize by the combination of data lifetime, business impact, exposure, technical dependency, and replacement difficulty. CISA, NSA, and NIST specifically call for priority attention to high-impact systems, industrial-control systems, and systems with long-term confidentiality or secrecy needs. They also note that custom-built products, especially older systems, may require the most effort, while commercial off-the-shelf and cloud products require direct vendor or provider engagement. This is a recommended prioritization model, not a quantified ranking of sectors. [C15, C16]3

From inventory to migration execution

The evidence converges on an inventory-first operating model. A cryptographic inventory should provide visibility into how cryptography is used across IT and OT, identify quantum-vulnerable algorithms in network protocols and assets, connect technology to the criticality of the data it protects, and reveal dependencies that are otherwise difficult to see. The joint fact sheet says that organizations are often unaware of the breadth of application and functional dependencies on public-key cryptography. It recommends involving IT and OT procurement experts, cybersecurity and privacy risk managers, and supply-chain vendors. [C3, C17]3

The inventory should be useful for decisions, not merely exhaustive. NCSC advises capturing system scale, available version and patch information, and dependencies between components and services. CISA, NSA, and NIST emphasize correlating vulnerable technology with data criticality and identifying data that could be targeted now and decrypted later. Inference: a register that records algorithm names but omits ownership, suppliers, data lifetime, business impact, and upgrade path will be less useful for sequencing migration. The cited sources support the need for those categories, but do not prescribe one universal inventory schema. [C14, C17]4

Migration planning should then be expressed as activities and decision points. NCSC lists researching technology options, procurement, commissioning, testing, backup and data migration, rollout, business-continuity planning, outage tolerance, and rollback. For all but the simplest systems, it expects staged migration rather than a single “big bang” uplift. It also notes that traditional and PQC certificates may need to operate simultaneously for a period, and that quantum-secure authentication is not achieved until PKI migration is complete and traditional certificates have expired or been revoked. [C18, C19]4

Testing and assurance are not optional finishing steps in the reviewed guidance. NCSC warns that systems may suffer loss of service or weakened security if migration is not verified, and recommends checking that standardized PQC cipher suites are actually being used rather than silently falling back to traditional cryptography. It suggests metrics such as the number of software clients using PQC and identification of those that are not. These measures can show progress and support decisions about retiring traditional algorithms, but the sources do not establish a universal target percentage or deadline for every organization. [C20]135

Governance, agility, and supply-chain transparency

The broader governance evidence supports treating PQC as an enterprise risk and modernization program rather than an isolated cryptography project. NIST CSF 2.0 describes concurrent functions—Govern, Identify, Protect, Detect, Respond, and Recover—and says that governance, identification, protection, and detection activities should occur continuously, while response and recovery should remain ready. Applied carefully, this suggests that PQC work should connect policy, asset and risk information, safeguards, monitoring, incident response, and restoration. That application is an inference from the framework, not a PQC-specific requirement stated in CSF 2.0. [C21, C22]234

Crypto agility gives that governance model a technical objective: the ability to change algorithms and related implementations while preserving security and operational continuity. It should be considered alongside protocol negotiation, certificate and PKI sequencing, software and firmware update paths, hardware replacement cycles, and supplier roadmaps. CISA, NSA, and NIST advise asking vendors how they address quantum readiness; for commercial products, the roadmap should explain when and how updates or upgrades will enable PQC, including expected migration cost where available. [C11, C16, C19]234

Supply-chain transparency can reinforce this work. The cited OWASP material describes CycloneDX as ECMA-424, a full-stack bill-of-materials standard supporting SBOM, SaaSBOM, HBOM, ML-BOM, CBOM, MBOM, OBOM, vulnerability disclosure reports, VEX, and attestations. It also describes a cryptography bill of materials as one supported form. The evidence does not say that CycloneDX alone solves PQC discovery or that all suppliers provide complete cryptographic inventories. Its defensible relevance is narrower: standardized component and cryptography information may improve the visibility needed for dependency analysis and supplier conversations. [C23]234

Practical implications for the coming planning cycle

1. Establish ownership and scope. Put the work under an accountable governance structure spanning security, architecture, infrastructure, applications, OT, procurement, privacy, legal, and business risk. Define the first organizational or system profile rather than attempting an undifferentiated enterprise inventory.
2. Build a decision-useful cryptographic inventory. Record where public-key cryptography and related certificates, protocols, libraries, devices, services, and suppliers are used; add owners, versions, patch levels, dependencies, data criticality, confidentiality lifetime, and replacement constraints where available.
3. Prioritize exposure and consequence. Start with high-impact systems, long-lived secrets, industrial-control environments, externally exposed services, custom-built legacy technology, and systems whose suppliers have uncertain upgrade paths.
4. Engage vendors and cloud providers early. Ask for PQC roadmaps, supported standards, implementation and configuration plans, testing evidence, update paths, costs where available, and the treatment of dependencies. Do not infer readiness merely from a general security or quantum statement.
5. Design staged migration and agility. Plan coexistence where necessary, certificate and PKI sequencing, testing, business continuity, rollback, and eventual retirement of traditional algorithms. Ensure architecture and procurement decisions preserve the ability to adapt.
6. Measure actual use and residual exposure. Test for fallback, identify clients and services not using PQC, track remediation, and report progress through governance and risk processes. Treat metrics as organizational controls rather than as an industry benchmark.

The main inference from this evidence is that readiness is best understood as a capability, not a switch. An organization can make meaningful progress before every dependency is migratable by improving visibility, prioritizing long-lived risk, securing supplier commitments, and validating the behavior of systems already changed. Conversely, a nominal policy commitment without inventory, testing, ownership, and rollback evidence does not demonstrate operational readiness. The sources support this distinction through their repeated emphasis on inventories, staged execution, assurance, and crypto agility; they do not provide a maturity scoring model. [C3, C11, C17, C20]2

Missing data, conflicts, and limitations

The cited source set contains no industry sample, respondent counts, sector-by-sector adoption data, market revenue, implementation-cost dataset, or verified percentage of systems using PQC. Accordingly, this review cannot calculate market penetration, compare organizations, forecast spending, or claim that a particular sector leads. It also cannot determine the probability or date of a cryptographically relevant quantum computer. Statements about urgency are grounded in the cited threat rationale and migration guidance, not in a quantified forecast. [C2, C7, C12]134

The documents differ in purpose and scope. NIST’s standards and project materials address algorithm selection and standardization; the joint fact sheet addresses preparation and migration; NCSC provides migration-planning guidance; NIST CSF 2.0 supplies a broader cybersecurity governance structure; NIST CSWP 39 Update 1 addresses crypto agility; and CycloneDX addresses bill-of-materials transparency. These are complementary, but they are not interchangeable evidence of implementation. The cited bundle also includes AI RMF passages that are relevant to open, collaborative risk-management processes but do not provide PQC adoption data; they are not used here to make a quantum-specific market claim. [C5, C6, C11, C23]134

Finally, the source metadata preserves uncertainty about document timing. Some records are marked current without a cited publication date, while CSWP 39 Update 1 carries both a publication and later update date. This review does not silently harmonize those statuses or extrapolate beyond the passages cited. Future standards, vendor implementations, regulatory expectations, hardware cycles, and operational test results may change the practical picture. Readers should therefore treat the article as a reproducible evidence snapshot and refresh it against current primary documents before making investment or compliance decisions. [C4, C6, C7]134

Conclusion

The cited primary sources describe an industry direction rather than a measured market outcome: PQC has entered a standards-and-migration phase, and readiness depends on disciplined execution. The defensible near-term agenda is to govern the work, inventory cryptography and dependencies, prioritize long-lived and high-impact exposure, engage suppliers, design for crypto agility, migrate in stages, and verify actual system behavior. The evidence is strong enough to support those actions, but not to claim universal adoption, a single deadline, market size, or a predictable quantum-computer timetable. [C1, C3, C11, C18, C24]1