Quantum Threat Timeline

What the quantum threat timeline can—and cannot—tell us

The central distinction is between a technology forecast and a risk-management timeline. The cited evidence does not provide a dependable year in which a CRQC will become available. RFC 9794 states that current predictions vary on when, or if, such a device will exist. NIST likewise explains that it is not possible to predict exactly when—or even if—quantum computers will break present-day encryption. A statement that a CRQC could be possible in less than 10 years is presented as one view among widely varying predictions, not as a consensus forecast. These limitations rule out treating a predicted breach date as a sound planning assumption.12

The timeline is nevertheless actionable. Observable milestones include the publication and status of standards, the availability of implementations, protocol and product support, migration guidance, validation activity, and the retirement dates of vulnerable algorithms. These milestones can be monitored and assigned to owners even while hardware forecasts remain uncertain. A practical program therefore uses scenarios—early, middle, and delayed CRQC arrival—while requiring progress against the same migration work in every scenario.234

What counts as a cryptographically relevant quantum computer

A quantum computer is not automatically a threat to every cryptographic system. RFC 9958 defines a CRQC as a quantum computer with sufficient logical qubits to break traditional asymmetric cryptographic algorithms—such as RSA or elliptic-curve cryptography—within a practical timeframe. This definition focuses on cryptographic capability, not a headline count of physical qubits or general-purpose performance.4

The distinction between physical and logical qubits explains why hardware forecasts are difficult to translate into security dates. A physical qubit is a basic physical unit that is prone to noise and errors. A logical qubit is a fault-tolerant qubit constructed from multiple physical qubits through quantum error correction; it is the effective unit for reliable quantum computation. Consequently, a credible threat assessment must consider whether a system can produce enough reliable logical qubits, with sufficiently low error, to run an attack against the target algorithm within a practical timeframe. The cited evidence does not provide a required logical-qubit count, hardware architecture, error rate, or completion date for that capability.41

The expected cryptographic impact is also uneven. Shor’s algorithm threatens the integer-factorization and discrete-logarithm assumptions underlying widely used public-key systems, including RSA, finite-field Diffie–Hellman, and elliptic-curve Diffie–Hellman. The cited engineering guidance describes the risk to asymmetric cryptography as significantly greater than the risk to symmetric cryptography and hash functions. Grover’s algorithm creates a lower and generally more manageable concern for symmetric cryptography and hashes; where applicable, the cited guidance says the risk can typically be mitigated by doubling key and digest lengths. This does not mean that every cryptographic component should be changed identically.146

The observable migration timeline

The first major observable milestone is the completion of NIST’s initial PQC standards. NIST’s overview, created on August 13, 2024, says that the first three finalized PQC standards were released in 2024. The cited NIST project material identifies the foundation of most deployments as ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. FIPS 203 became effective immediately upon final publication and specifies three ML-KEM parameter sets with different security-strength and performance tradeoffs. FIPS 204 and FIPS 205 are final digital-signature standards.236

The second milestone is the continuing development of transition guidance. NIST IR 8547, dated November 12, 2024, is an initial public draft rather than a final standard. Its cited passage says that application-specific standards and guidelines may specify earlier transitions for particular algorithms, techniques, and protocols. It also says NIST expects to prioritize migration to quantum-resistant key-establishment schemes to address harvest-now-decrypt-later attacks, particularly in interactive protocols such as TLS and IKE. The document recognizes that application areas have different risks, security needs, and adoption challenges.5

The third milestone is the federal planning horizon. NIST IR 8547 IPD records NSM-10’s goal of mitigating as much quantum risk as feasible by 2035 through the transition of federal cryptographic systems. The same passage cautions that migration timelines vary by use case and application. Therefore, 2035 is best used as an external planning reference and urgency signal, while system owners should establish more specific dates based on data lifetime, replacement difficulty, protocol dependencies, and applicable requirements.5

The fourth milestone is ecosystem readiness. Public-key migration is not merely a library replacement. Engineers must account for certificates, key establishment, signatures, protocol negotiation, message sizes, processing, device constraints, supplier support, and coexistence between upgraded and non-upgraded agents. ETSI notes that some post-quantum key exchanges have public keys too large for the available IKEv2 space without fragmentation, while RFC 9958 describes staged migrations in which upgraded and non-upgraded agents must communicate. These are deployment facts that can be tested now, independently of hardware forecasts.74

Why the risk begins before a CRQC exists

Harvest now, decrypt later changes the time horizon. An adversary can record encrypted communications today and attempt decryption after obtaining a CRQC. RFC 9794 specifically states that data encrypted in 2025 with an algorithm vulnerable to a quantum computer can be stored for future decryption. RFC 9954 similarly identifies retroactive decryption as a reason to accelerate PQC adoption. The immediate question is therefore not only “When will a CRQC arrive?” but also “How long must this information remain confidential, and can the cryptography protecting it be replaced before that period ends?”18

This exposure is most consequential for long-lived sensitive information, recorded handshakes, encrypted communications, long-lived signing keys, and systems that cannot be updated or replaced easily. The evidence also distinguishes confidentiality from authentication: key-establishment protection and digital-signature migration have different technical and operational dependencies. Organizations should identify both the data whose confidentiality must survive into the future and the signatures or roots of trust that may need to remain verifiable for many years.18

Scenario planning instead of a predicted breach date

A useful scenario plan separates what changes across scenarios from what does not. In an early-arrival scenario, organizations may face less time between credible capability evidence and operational exposure; high-value long-lived data, public-key key establishment, and irreplaceable trust anchors receive the highest priority. In a middle scenario, the organization continues staged deployment, interoperability testing, supplier coordination, and retirement planning while standards and implementation experience mature. In a delayed scenario, the same work reduces cryptographic debt and avoids a rushed transition. These scenarios are planning constructs, not forecasts cited by the evidence.

Decision triggers should be observable and owned. Examples include the completion of a cryptographic inventory; a finding that sensitive data has a confidentiality lifetime longer than the remaining replacement window; availability of a suitable final standard and validated implementation; support for PQC or an appropriately analyzed hybrid mode in a critical protocol; a supplier’s announced end-of-support date for a vulnerable algorithm; successful testing of message sizes, certificates, performance, and downgrade resistance; or an application-specific standard that sets an earlier transition. Each trigger can advance a work package without asserting that a CRQC is imminent.

Hybrid mechanisms can be useful during transition, but they are not automatically safe. NIST IR 8547 describes the desired property of hybrid key establishment as retaining security if at least one component scheme remains secure, while also noting that security properties must be analyzed case by case. ETSI identifies the difficulty of achieving hybrid interoperability and hybrid security together. NIST SP 800-227 warns that composite schemes add complexity and choices that can introduce vulnerabilities, including downgrade attacks. A hybrid deployment therefore requires an explicit security analysis, protocol review, implementation testing, and a plan to remove obsolete components.

A practical timeline for security teams

Start with discovery. Inventory applications, protocols, certificates, libraries, devices, services, vendors, and data flows that use public-key encryption, key establishment, or digital signatures. NIST’s overview specifically recommends that technology managers inventory systems using encryption and alert technology departments and vendors. Record algorithm, parameter set, key and signature roles, data-protection purpose, certificate or trust-anchor dependencies, update path, expected service life, and the confidentiality or authenticity lifetime of protected information.

Next, classify urgency. Prioritize recorded or recordable communications protecting long-lived secrets; systems with long replacement cycles; public-facing TLS and IKE deployments; identity and certificate infrastructure; firmware and software-signing roots; and systems whose vendors have not demonstrated an update path. NIST IR 8547 explicitly prioritizes quantum-resistant key establishment in the context of harvest-now-decrypt-later, while the cited RFC material identifies long-lived signing systems as at risk if they cannot be updated or replaced.518

Then, establish an engineering baseline. Select the applicable final standards, assess implementation quality, test protocol and product compatibility, and measure operational effects such as key sizes, ciphertext sizes, signature sizes, processing time, packet fragmentation, storage, and logging. Conformance alone is not an overall security guarantee: FIPS 203 and FIPS 204 state that secure implementation and system-level design remain the implementer’s responsibility. NIST SP 800-227 further explains that validation testing checks only sampled input-output behavior and does not guarantee correct functioning for all inputs.

Finally, govern the transition. Set milestones for inventory completion, architecture decisions, pilots, production deployment, vulnerable-algorithm retirement, supplier commitments, and recurring review. Maintain crypto agility so algorithms and parameters can be changed without redesigning every dependent system. Reassess assumptions when standards change, implementation evidence improves, application-specific guidance is issued, or credible information materially changes the assessment of quantum capability. This governance model remains useful whether the CRQC scenario arrives early, late, or not at all.23

What the timeline does not justify

The evidence does not justify naming a CRQC arrival year, claiming that a particular number of physical qubits is sufficient, or treating a laboratory milestone as proof that RSA or ECC can be broken in practice. It also does not justify assuming that PQC deployment alone secures an entire system. FIPS 203 and FIPS 204 both state that conformance does not ensure that a particular implementation or the overall system is secure. Secure key handling, randomness, private-key protection, protocol design, validation, access control, monitoring, and operational recovery remain necessary.124

Nor does “quantum-safe” mean that all risks disappear. PQC algorithms are intended to resist quantum and classical attacks, but the cited RFC material notes that many algorithms under consideration are relatively new and may not have received the same depth of study as RSA or older Diffie–Hellman systems. Conservative users may therefore retain uncertainty about some algorithms or parameterizations. Migration should manage cryptographic transition risk rather than replace one unexamined assumption with another.

Finally, PQC should not be conflated with quantum key distribution. The cited NSA material describes PQC as implementable on existing platforms and criticizes claims that QKD or quantum cryptography provides guaranteed security independent of implementation. That distinction matters to timeline planning: the evidence supports preparing for PQC migration through conventional platforms and standards, while any alternative technology must be assessed against its own engineering, operational, and assurance limitations.

Approved explanatory diagram

Conclusion

The quantum threat timeline has an uncertain hardware endpoint but a clear preparation path. No cited evidence can establish when—or whether—a CRQC will arrive, and a federal 2035 migration target must not be mistaken for a breach forecast. Organizations can still make timely, evidence-based decisions: inventory vulnerable public-key use, protect long-lived data against harvest-now-decrypt-later exposure, follow final standards while labeling NIST IR 8547 as an initial public draft, test real protocol and implementation constraints, analyze hybrid designs carefully, and use observable migration triggers. That approach reduces dependence on an unknowable date and makes the organization more resilient across multiple quantum scenarios.1258