P(Q Doom)₂₀₃₅

P(Q Doom) is the probability that cryptographically relevant quantum capability arrives before systemically important digital infrastructure completes its transition away from sole dependence on quantum-vulnerable public-key cryptography. The benchmark is written as P(TQ < TM), where TQ is the quantum-arrival clock and TM is the migration-completion clock.

QDI v1.0 estimates P(Q Doom)₂₀₃₅ at 34%, with a 90% calibrated uncertainty interval of 22–48%. The estimate is a structured calibration informed by expert CRQC timelines, migration-adoption evidence, standards maturity, and observed engineering progress. The interval is not presented as a formal Bayesian posterior credible interval in v1.0, and 34% is not a claim that Q-Day is certain by 2035. ^{[1] [14]}

No. P(Q Doom) is a race probability, not a standalone Q-Day forecast. It measures the probability that quantum cryptanalytic capability arrives before migration is sufficiently complete, so it depends on both the quantum timeline and the migration timeline.

Q-Day is the point at which a quantum computer can practically defeat widely deployed public-key cryptography at a scale and cost relevant to real systems. Different systems can face different effective Q-Days because algorithms, key types, exposed public keys, implementation choices, and attack economics differ.

A CRQC is a fault-tolerant quantum computer capable of running cryptanalytic algorithms, such as Shor's algorithm, at the scale needed to compromise widely deployed public-key cryptography. A large physical-qubit count alone does not make a machine cryptographically relevant; error correction, logical qubits, gate fidelity, runtime, and architecture matter.

No. No publicly demonstrated quantum computer can currently execute the full fault-tolerant workloads required to break widely deployed RSA or elliptic-curve cryptography. Current research instead measures how hardware, error correction, logical-qubit performance, and attack-resource estimates are converging. ^[31]

2035 is long enough to capture material CRQC probability while still overlapping with major government and industry migration horizons. It also provides enough probability mass for the benchmark to measure the race between technology progress and migration progress rather than only near-term tail risk.

Because 2030 is becoming a major institutional migration milestone, not because QDI claims Q-Day occurs in 2030. U.S., EU, and UK transition roadmaps create material milestones around 2028–2031, while large institutions can require years for discovery, architecture, vendor coordination, testing, and deployment. ^{[24] [11] [30]}

Migration Runway is the time remaining between today and the date by which an institution needs a target cryptographic state, after accounting for how long discovery, redesign, testing, procurement, vendor coordination, and deployment are likely to take. It converts a distant risk horizon into a present-day implementation question.

The Last Safe Start Date is the latest date at which a migration program can begin and still reach its target state with an appropriate implementation buffer. Conceptually: Last Safe Start Date = target completion date − expected migration duration − safety buffer.

Quantum Migration Debt is the accumulated time, cost, dependency, and retrofit burden created when systems remain dependent on quantum-vulnerable cryptography while the migration window shrinks. It has both a stock and a flow: legacy systems represent existing debt, while new systems built today with avoidable future retrofit requirements create new debt.

Because planning is itself part of the migration. The UK NCSC says large organizations may need roughly 2–3 years for discovery, strategy, and an initial plan, while U.S. and EU frameworks place important migration milestones around 2030–2031. Delaying discovery consumes the same runway needed for implementation. ^{[30] [24] [11]}

The exact timeline varies by jurisdiction and system, but several major roadmaps cluster in this period. The UK NCSC targets discovery and an initial plan by 2028, highest-priority migration by 2031, and completion by 2035; U.S. Executive Order 14412 sets key-establishment and signature milestones around 2030–2031; the EU roadmap targets high-risk use cases by end-2030. ^{[30] [24] [11]}

HNDL is the strategy of collecting encrypted data today and storing it until a future quantum computer can decrypt it. That means long-lived confidential data can be exposed before a CRQC exists, because the relevant deadline is the data's secrecy lifetime plus migration time, not only the date of a future quantum break. ^[18]

Public-key systems based on integer factorization or discrete logarithms are the core concern, including RSA and widely used elliptic-curve systems. In digital assets, this includes signature and consensus components that rely on ECDSA, BLS, and related public-key assumptions; the exact risk depends on how and when public keys become exposed and what the protocol verifies. ^{[7] [12] [13]}

Yes, important parts of both ecosystems rely on quantum-vulnerable public-key cryptography. Bitcoin uses secp256k1 signatures, while Ethereum currently relies on quantum-vulnerable cryptographic components across accounts, consensus, commitments, and proofs; both ecosystems are actively studying migration paths. ^{[12] [13]}

No. IonQ's 2026 work is a modeled resource estimate, and its 2028 hardware target is a company roadmap; neither proves that a cryptographically relevant machine will exist in 2028. The planning signal is that a published ECC attack resource estimate and a commercial hardware roadmap have moved into a similar order of magnitude, which reduces the comfort of assuming late-2020s capability is irrelevant. ^[31]

Several organizations publicly target 2029 for different engineering milestones, including defensive PQ migration, protocol-level quantum resistance, and fault-tolerant hardware roadmaps. This is not a shared Q-Day forecast; it is a useful planning signal that leading ecosystems are allocating engineering effort around a similar late-2020s horizon. ^{[26] [13] [28]}

AI is already contributing to measurable parts of the quantum stack, including error decoding and research workflows. QDI therefore tracks demonstrated AI-enabled improvements through hardware, error-correction, and algorithm-efficiency evidence rather than applying an arbitrary 'AI acceleration' multiplier. ^[22]

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. These standards provide standardized post-quantum primitives for key establishment and digital signatures, giving institutions a concrete technical destination for migration. ^[8]

Post-quantum cryptography is cryptography designed to remain secure against both classical and quantum adversaries while running on conventional computing hardware. It is different from quantum cryptography: PQC is deployed through software, protocols, hardware security modules, applications, and infrastructure that institutions already use. ^[8]

Crypto-agility is the ability to change cryptographic algorithms, keys, parameters, and policies without rebuilding an entire system. It matters because post-quantum standards and implementation preferences will continue to evolve, so institutions should avoid hard-wiring a single cryptographic assumption into long-lived infrastructure.

No. Institutions can begin with the highest-value cryptographic control surfaces and migrate incrementally. A practical program can protect selected authorization, custody, wallet, tokenization, PKI, network, or settlement workflows while broader infrastructure transitions over time. ^[29]

In many architectures, yes. Post-quantum controls can be introduced at selected authorization or control layers before every underlying protocol, vendor, or base network becomes fully PQ-native; however, that does not make every dependency in the end-to-end system quantum-safe, so scope and residual classical dependencies must be explicit.

No. MPC and HSMs can improve how classical private keys are generated, stored, and used, but they do not change the quantum vulnerability of the underlying ECDSA signature scheme. If a system ultimately authorizes value using a quantum-vulnerable public-key primitive, the cryptographic assumption itself still needs a migration path. ^[12]

PQ-native means post-quantum security is designed into the protected architecture from inception rather than added later as a retrofit. A PQ-native system should still be explicit about external dependencies—identity, networks, devices, counterparties, bridges, and other classical components—so 'PQ-native' is not the same as claiming every surrounding dependency is quantum-safe.

Because a new long-lived system built today on avoidable quantum-vulnerable controls can create a known future retrofit requirement before the system reaches the end of its intended life. Designing the protected control layer PQ-native from inception can avoid substantial classical-to-PQ migration debt later.

Start with one critical path where authorization matters and the boundary can be measured clearly: for example a wallet, custody workflow, tokenization control, asset-transfer authorization, or settlement instruction. The objective of the first pilot is not to replace everything; it is to prove integration, performance, policy, auditability, and operational control on a bounded workflow.

No. Vendor readiness can constrain execution, but institutions can begin cryptographic discovery, dependency mapping, architecture decisions, procurement requirements, crypto-agility work, testing, and bounded pilots before every supplier is ready. The UK NCSC explicitly tells organizations to identify supplier and physical-infrastructure dependencies and communicate migration needs to suppliers; waiting for the whole ecosystem can consume the same runway needed for implementation.^[30]

Not as a universal mandate. But where an institution controls the architecture, expects the system to be long-lived, and can use standards-aligned implementations without unacceptable operational trade-offs, it should evaluate PQ-native or crypto-agile controls at inception. That can avoid creating a preventable classical-to-PQ retrofit across the protected control layer while preserving algorithm flexibility as standards evolve.^[27]

It is a scoped engineering claim, not a blanket guarantee. A component or control is quantum-safe only with respect to the cryptographic function, algorithm, implementation, and threat model being described. External dependencies—endpoints, identity systems, networks, HSMs, counterparties, bridges, legacy integrations, or other classical cryptography—may remain outside that protection. The report therefore prefers claims such as “PQ-protected authorization layer” over saying an entire institution or ecosystem is quantum-safe.

Yes. The index should rise when credible evidence moves quantum capability closer or migration completion further away, and fall when hardware progress slows, attack-resource estimates worsen, or real production migration accelerates. A useful benchmark must be capable of moving in both directions.

QDI is defined as P(T_Q < T_M). In a fully specified implementation, that is computed by integrating the quantum-arrival distribution against the probability that migration remains incomplete over time. QDI v1.0 is a structured calibration across six factor families; until the public parameterization, data, code, and sensitivity package is released, the 34% should not be treated as an independently reproducible closed-form statistic.

P(Q Doom) measures the probability of losing the migration race. QVaR, or Quantum Value-at-Risk, measures the economic value or flow exposed to quantum-vulnerable cryptographic control. The two answer different questions: probability versus exposure.

The report uses Quantum Systemic Risk as a conceptual combination of probability, exposure, and migration friction: P(Q Doom) × QVaR × migration friction. It is a taxonomy for reasoning about systemic risk, not yet a single standardized monetary formula.

QDI is designed as a quarterly benchmark. Each edition should publish the current estimate and interval, evidence that moved the index, methodology version, source register, change log, and—once available—version-frozen data and code so changes can be audited over time.

The report is designed for external challenge, but full reproduction requires the planned methodology and data package: the TQ and TM distributions, source-to-variable mapping, weighting rules, correlation assumptions, sensitivity analysis, update rules, and calculation code. Until that package is published, the 34% should be treated as a transparent structured calibration rather than a fully reproducible public model.

EternaX develops post-quantum infrastructure, so the report discloses an unavoidable commercial conflict of interest. The safeguard is methodological: commercial considerations are not model inputs, sources and assumptions are published, roadmap evidence is separated from demonstrated achievement, and the index must be capable of falling when evidence improves.

EternaX supports two action paths defined independently in the report: protecting selected high-value control surfaces in existing infrastructure, and designing new protected infrastructure PQ-native from inception. The report's risk taxonomy is broader than any one vendor, and EternaX appears only after the vendor-independent action categories are established.

Use it as a forcing function for an internal estimate and a migration-runway discussion, not as a prediction to outsource judgment to. The practical questions are: what cryptography protects our critical assets and data, how long would migration really take, what external dependencies control that timeline, and what is our last safe start date?

Do not wait for certainty about Q-Day. Identify one critical cryptographic path, measure its migration runway and dependencies, and either begin reducing existing quantum migration debt or avoid creating new debt in the next system you build.