Imported from the-vibey-project/vibey (src/vibey_tools/skills/plugins/quantum-computing/skills/quantum-applications-and-post-quantum-crypto/SKILL.md). Install upstream with npx skills add the-vibey-project/vibey --skill quantum-applications-and-post-quantum-crypto. Copyright stays with the author.

Quantum Computing: Applications, Networking and Sensing, and Post-Quantum Cryptography

Part 4 of 5 of the Quantum Computing reference (plugin quantum-computing), covering §11–§13. Sibling skills: quantum-foundations-and-algorithms (§0–§3), quantum-noise-error-correction-and-hardware (§4–§7), quantum-software-and-resource-estimation (§8–§10), quantum-reference (§14–§20). Section numbers are shared across the set; a reference written as §N → skill points into that sibling skill.

Currency: Verified August 2026. See §17 → quantum-reference for the currency snapshot and what goes stale first.

How to read this. Reference, not tutorial. Sections are independent. Three markers:

• [DURABLE] — physics, mathematics, or complexity theory. Does not expire.
• [VERSIONED] — hardware state, roadmaps, software versions, regulatory deadlines. Moving fast; verify before relying on it.
• [CONTESTED] — genuine scientific or strategic disagreement, of which this field has an unusual amount.

⚠️ GOTCHA boxes mark the misconceptions that produce bad technical decisions and bad business decisions.

The three framings that organize everything below:

1. A quantum computer is not a faster computer. It is a different computer with a narrow set of exponential advantages. For the overwhelming majority of workloads there is no quantum speedup, and none is expected. The interesting question is never "how fast" — it's "does this specific problem have exploitable structure?"
2. Nearly every headline conflates physical qubits with logical qubits. A distance-7 surface code uses 49 physical qubits to make one logical qubit; breaking RSA-2048 needs millions of physical qubits. Any number quoted without specifying which kind is nearly meaningless.
3. The cryptographic migration is urgent independently of when the hardware arrives. "Harvest now, decrypt later" makes today's encrypted traffic a future liability, and regulators have stopped waiting for hardware predictions and published binding dates. §13 is the section with real deadlines attached.

§11. Applications

11.1 Quantum chemistry and materials — the strongest case

[DURABLE] Simulating molecules and materials is the application where the exponential advantage is least disputed, because the problem is a quantum system. Targets: catalysis (nitrogen fixation is the canonical example), battery chemistry, superconductors, drug binding affinities. Near-term: VQE on small molecules (⚠️ heuristic, barren plateaus, §4.4 → quantum-noise-error-correction-and-hardware). Fault-tolerant: quantum phase estimation on industrially relevant systems — which requires §5 → quantum-noise-error-correction-and-hardware-scale hardware.

⚠️ Reality check: classical computational chemistry (DFT, coupled cluster, DMRG, quantum Monte Carlo) is very good and improving, and the quantum-advantage crossover point for industrially relevant molecules is genuinely uncertain.

11.2 Optimization

Portfolio optimization, routing, scheduling, supply chain — the most-marketed application and the weakest technical case. QAOA and quantum annealing are heuristics with no proven advantage, and classical solvers (Gurobi, CPLEX, specialized heuristics, and simulated annealing) frequently match or beat quantum approaches on the same problems. [CONTESTED] §16.4 → quantum-reference.

11.3 Quantum machine learning

⚠️ The most oversold area. Two structural problems: the data-loading bottleneck — there is no efficient way to load a large classical dataset into a quantum state, and QRAM remains theoretical — and dequantization (§10.3 → quantum-software-and-resource-estimation), which removed the claimed speedup from a whole family of QML algorithms. Add barren plateaus (§4.4 → quantum-noise-error-correction-and-hardware) and the result that provable absence of barren plateaus may imply classical simulability, and the honest position is that QML's advantage case is currently weak. The plausible exception: machine learning on data that is natively quantum (from quantum sensors or quantum simulations), where the loading problem doesn't arise.

11.4 Finance, and everything else

Derivative pricing via amplitude estimation (quadratic — see §9.3 → quantum-software-and-resource-estimation for why that may not survive), risk analysis, fraud detection. Real bank R&D programs exist; no production quantum advantage has been demonstrated in finance. The reasonable framing for enterprises is capability-building and option value, not near-term ROI.

§12. Quantum Networking and Sensing

[DURABLE] These are separate fields from quantum computing and are commercially closer.

Quantum sensing is the most mature quantum technology commercially: atomic clocks, magnetometry (SQUIDs, NV centers), gravimetry, inertial navigation. Real products, real revenue, today — and often ignored because it isn't a computer.

Quantum networking / repeaters — entanglement distribution, quantum memories, the long-term "quantum internet" vision, and near-term links between quantum processors (which is how trapped-ion and photonic architectures plan to scale).

QKD (quantum key distribution) — [CONTESTED, and the disagreement is unusually sharp]. For: information-theoretic security grounded in physics rather than computational assumptions. Against: NSA, NCSC, and ANSSI all recommend post-quantum cryptography over QKD for national security systems, citing the requirement for special-purpose hardware, the inability to provide authentication (QKD needs a classical authenticated channel anyway), distance limitations and trusted-relay requirements, denial-of-service exposure, and side-channel attacks on real implementations. CNSA 2.0 explicitly rejects QKD for NSS. The practical guidance: PQC (§13) is the answer for essentially all organizations; QKD is a niche with specific physical-layer requirements.

§13. Post-Quantum Cryptography

[DURABLE] This is the part of quantum computing with the most immediate, concrete consequences for ordinary organizations — and it does not depend on when quantum computers arrive.

13.1 The threat

Shor's algorithm breaks RSA, Diffie-Hellman, and elliptic-curve cryptography. Grover halves the effective security of symmetric ciphers, so AES-256 remains fine and SHA-384/512 are recommended.

⚠️ "Harvest now, decrypt later" (HNDL) is why the timeline argument is a distraction. An adversary recording encrypted traffic today can decrypt it whenever a cryptographically-relevant quantum computer exists. If your data must stay confidential for 10+ years, it is already exposed. This applies to health records, state secrets, long-lived financial data, and anything with a legal retention requirement.

13.2 The standards

[VERSIONED] NIST finalized three standards on 13 August 2024 after an eight-year competition:

NIST also selected HQC in March 2025 as a fifth algorithm and additional KEM. HQC is code-based rather than lattice-based, providing a mathematically different backup to ML-KEM in case lattice assumptions fall — its standard is still being drafted, so it is not yet deployable. Use the FIPS names in procurement documents and specs.

⚠️ Use the FIPS versions, not the competition versions — parameters changed during standardization. And prefer hybrid (classical + PQC) constructions during transition: ETSI and the EU explicitly encourage hybrids, and they protect you if a PQC algorithm is broken (which has happened to competition candidates — SIKE and Rainbow were both broken classically during the process).

13.3 The deadlines — now binding, not advisory

[VERSIONED — verify against the current text; this is the highest-consequence table in the document.]

NIST (IR 8547 transition roadmap): quantum-vulnerable algorithms including RSA and ECC are deprecated after 2030 and disallowed after 2035. Algorithms at the 112-bit security level are deprecated after 2030 and disallowed after 2035 regardless.

US federal civilian — this became obligation in 2026:

• EO 14412 ("Securing the Nation Against Advanced Cryptographic Attacks," June 2026) mandates accelerated government-wide PQC migration, sets binding deadlines for high-value assets, and directs the Federal Acquisition Regulatory Council to require contractor compliance with NIST PQC standards.
• OMB M-26-15 sets the phased schedule: agencies named a PQC migration lead by late July 2026 and owed a full migration plan by late October 2026; inventories and planning through 2027, pilots through 2028, key establishment migrated by 31 December 2030, digital signatures by 31 December 2031, remaining systems by 2035. It directs agencies to fold PQC into cloud migrations and hardware refresh cycles rather than run it standalone, and requires identification of systems that cannot support PQC or hybrid.
• EO 14144 requires TLS 1.3 (or successor) across federal systems by 2 January 2030.

US national security systems (NSA CNSA 2.0) — excluded from the OMB track and moving faster, with ML-KEM-1024 and ML-DSA-87 specified alongside AES-256 and SHA-384/512: software and firmware signing leads (exclusive CNSA 2.0 use from 1 January 2027), all new NSS acquisitions CNSA 2.0 compliant from 1 January 2027, networking equipment by 2030, operating systems / custom applications / cloud services by 2033, and full quantum resistance across all NSS by 2035. ⚠️ These extend across the defense supply chain, affecting contractors and vendors.

EU — the NIS Cooperation Group roadmap (June 2025): initial national roadmaps and awareness by 31 December 2026; high-risk use cases addressed by 31 December 2030; full transition by 31 December 2035, with a focus on standardized, tested hybrid solutions.

UK NCSC — three-phase guidance to 2035. Australia (ASD) is more aggressive, advising elimination of classical public-key cryptography by 2030.

13.4 How to migrate

[DURABLE] In order: (1) inventory your cryptography — this is the hard part and where every program stalls; you cannot migrate what you can't find, and it lives in TLS configs, code signing, VPNs, HSMs, embedded firmware, third-party libraries, and vendor products. (2) Prioritize by data lifetime and HNDL exposure. (3) Build crypto-agility so the next migration is cheaper. (4) Push vendors — much of your exposure is in products you don't control. (5) Deploy hybrid first. (6) Watch the embedded and IoT long tail, where devices have 15-year lifetimes and no update path.

Realistic enterprise timeline: 42–54 months from start to compliance. The practical dates arrive years before the printed ones, because hardware refresh cycles and vendor readiness gate you.