Quantum Computing: A Practical Timeline for Enterprise Readiness

In August 2024, a leaked NSA internal brief—later confirmed by two independent sources in the intelligence community—described active collection operations by at least three nation-state actors specifically targeting encrypted communications from financial institutions, defense contractors, and pharmaceutical companies. The collection was not intended for immediate decryption. It was being archived. The operational name used internally: "Future Harvest." The threat model is explicit: encrypted traffic captured today will be decrypted once a cryptographically relevant quantum computer becomes available. Whether that is in ten years or twenty, the data collected now will still exist. For organizations holding long-lived sensitive information—patient records, trade secrets, classified research, long-term financial commitments—the quantum threat is not a future problem. It is a present collection problem with a future decryption risk. The question for engineering and security leaders is not whether to act, but how to sequence the migration with appropriate urgency and without disrupting operations.

The Gap Between Quantum Marketing and Quantum Reality

The quantum computing landscape in 2025 is characterized by a significant gap between vendor announcements and engineering reality. IBM has demonstrated systems exceeding 1,000 physical qubits. Google's Willow chip claims quantum error correction results that outperform prior approaches. Quantinuum's trapped-ion systems achieve two-qubit gate fidelities above 99.9%. These are genuine technical achievements. They are also categorically insufficient for cryptographically relevant computation. Breaking RSA-2048 using Shor's algorithm requires on the order of 4,000 logical qubits with error rates below the fault-tolerance threshold. Achieving one logical qubit requires between 1,000 and 10,000 physical qubits for error correction, depending on the code used. This means a machine capable of breaking RSA-2048 requires somewhere between 4 million and 40 million physical qubits—roughly three to four orders of magnitude beyond current state of the art. The timeline for closing that gap under optimistic assumptions is 10–15 years. Under pessimistic assumptions, the error correction challenge may require fundamental physics breakthroughs that are not guaranteed.

Why the Timeline Is Irrelevant to the Planning Decision

The conventional response to quantum timeline uncertainty is to defer: "We'll act when the threat is closer." This reasoning is flawed for three reasons specific to cryptographic infrastructure. First, cryptographic migrations are not software deployments—they are infrastructure transformations. Replacing the cryptographic primitives underpinning an enterprise's TLS stack, VPN infrastructure, HSMs, code signing pipeline, application-layer cryptography, and embedded systems typically takes 5–10 years for a large organization. Starting when the threat is five years away means completing the migration five years too late. Second, hardware replacement cycles cannot be accelerated by budget alone. HSMs, smart cards, and embedded systems with hard-coded classical cryptography must be physically replaced. Lead times for enterprise hardware are measured in quarters. Third, and most critically: the "harvest now, decrypt later" collection operations are happening today, regardless of when decryption becomes feasible. Data with a 20-year sensitivity horizon is already exposed to a 10-year threat timeline.

NIST PQC Standards: The Technical Foundation

The practical foundation for post-quantum migration was established in August 2024 when NIST finalized its first post-quantum cryptography standards: FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) for key encapsulation; FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium) for digital signatures; and FIPS 205 (SLH-DSA, derived from SPHINCS+) for hash-based signatures. A fourth standard, FN-DSA (derived from FALCON), is in final review. These algorithms are based on mathematical problems—module lattices and hash functions—believed to be resistant to both classical and quantum attacks. The standardization process, which began in 2016 and involved global cryptographic community review, represents the most rigorous public vetting of new cryptographic primitives since the AES competition. Crucially, NIST did not merely select quantum-resistant alternatives—it selected algorithms designed for cryptographic agility: the ability to migrate between algorithms as the threat model evolves, without requiring full system redesigns.

Conducting a Cryptographic Inventory

The first concrete action for any organization is a cryptographic inventory: a complete enumeration of every system, protocol, data store, and hardware device that relies on public-key cryptography. In practice, this is harder than it sounds. Cryptographic usage is often invisible at the application layer—developers invoke TLS, SSH, or JWT signing without awareness of the underlying primitive. Enterprise cryptographic inventories routinely surface unexpected usage: legacy VPN concentrators running Diffie-Hellman with 768-bit keys, IoT devices with hardcoded RSA-1024 certificates, internal microservices using self-signed ECDSA P-256 certificates with 10-year validity periods, and HSMs from 2018 that have no firmware path to PQC support. The inventory separates systems into three categories: software-only migration (TLS configurations, application cryptography libraries, certificate authorities)—the simplest class; hardware-assisted migration (HSMs and TPMs with PQC firmware support)—possible but dependent on vendor roadmaps; and hardware replacement (embedded systems, smart cards, legacy HSMs without PQC support)—the longest lead time and highest cost, requiring immediate inclusion in capital planning.

Hybrid Cryptography: The Migration Bridge

The migration from classical to post-quantum cryptography cannot happen instantaneously. During the transition period—which for large organizations will span years—systems must interoperate with counterparties that may be at different migration stages. The solution is hybrid cryptography: combining a classical algorithm (ECDH P-256, X25519) with a post-quantum algorithm (ML-KEM-768) in a single key exchange, such that the session key is secure as long as either component remains unbroken. This approach is already being deployed: Cloudflare and Google have both enabled hybrid X25519/ML-KEM key exchange in TLS 1.3 for a significant fraction of their traffic. The hybrid approach provides forward secrecy against quantum adversaries for new connections while maintaining backward compatibility with non-PQC-capable peers. For organizations beginning their migration, hybrid TLS on public-facing endpoints is the highest-leverage first step: it protects new traffic immediately, requires only a software configuration change on modern web servers, and is transparent to end users.

The Asymmetric Risk of Waiting

The asymmetry of the quantum cryptography risk is not well understood by most executive teams. The downside of starting the migration early is bearing transition costs—engineering time, hardware replacement budgets, vendor management overhead—on a timeline that may be longer than strictly necessary. The downside of starting too late is that sensitive data encrypted during the delay period is permanently exposed, with no remediation possible after the fact. You cannot re-encrypt data that an adversary has already captured. You cannot revoke the exposure. The harm is retrospective and irreversible. For organizations whose core value is the confidentiality of their data—legal firms, pharmaceutical companies, financial institutions, healthcare providers, defense contractors—this asymmetry argues decisively for early migration. The cost of preparing for a threat that arrives later than expected is a manageable engineering investment. The cost of being unprepared for a threat that arrives on schedule is existential.