up:: The Threat MOC
Quantum Risk Models
Quantum risk models are the small set of frameworks that turn “a quantum computer will break RSA someday” into an answer you can act on, which of your data is at risk and how soon you have to move. Four ideas do the work: Mosca’s theorem is the clock that gives you a deadline, HNDL and Non-HNDL name the two kinds of exposure, blast radius sizes how bad each failure would be, and the CRQC plus the Quantum Threat Timeline tell you what the clock is counting down to. Put together, they convert an abstract industry headline into a prioritized migration queue for your own estate.
Map of content
A short overview of the quantum risk models, and the index that routes you to every note in this section. Skim it to get oriented, then follow the links to go deep.
The short version:
- The whole point is to answer two questions: which of my data is at risk, and how soon do I have to move. Everything below serves those two.
- Mosca’s theorem is the deadline. If the years your data must stay secure (X) plus the years to migrate (Y) is greater than the years until a capable quantum computer arrives (Z), you’re already behind.
- There are two kinds of exposure with two different clocks. HNDL is a confidentiality problem that is live today because collection is happening now. Non-HNDL is a trust-forgery problem that bites only once the machine is real.
- Blast radius sorts the queue by consequence, so a root certificate authority moves ahead of a small internal app even when both use the same broken algorithm.
- The CRQC is the machine that finishes the threat, and the Quantum Threat Timeline is the expert-survey evidence for when it might arrive. No CRQC exists yet, and migration takes years, which is why you start now.
Think of it like triage in an emergency room. The whole job is sorting: who is hurt worst, and who will get worse fastest. Everyone gets seen in that order. Quantum risk models are that same triage system for your cryptography: one framework tells you the clock, one tells you which kind of injury you’re looking at, and one tells you how much bleeds out if you leave it. The output is an ordered list of what to fix first, which is far more useful than either alarm or complacency.
How do the quantum risk models fit together?
Each model answers a different question, and they only become a plan when you stack them. The order runs from timing, to kind, to consequence:
- Timing comes from Mosca’s theorem. One line of arithmetic,
X + Y > Z, decides whether an asset is urgent. It works because you don’t need to predict the arrival date of a quantum computer to know which assets are too important to gamble on. - Kind comes from HNDL versus Non-HNDL. HNDL is about secrecy lost later; Non-HNDL is about trust forged in real time. They carry different urgency and need different fixes, so naming which one you’re facing tells you what to replace.
- Consequence comes from blast radius. Two systems on the same vulnerable algorithm can sit at completely different priorities, because one is a bounded internal app and the other is a root of trust the whole estate depends on.
- The clock’s target comes from the CRQC and the Quantum Threat Timeline. The machine sets the deadline every other model is anchored to, and the timeline report is the defensible evidence for where that deadline sits.
The clock tells you when, the two exposure types tell you what kind, and blast radius tells you how bad. That combination is a prioritized migration queue, which is exactly what Doing the Work picks up.
What are the two kinds of quantum exposure?
There are exactly two, and confusing them is the most common way a program mis-sequences itself. HNDL is a confidentiality threat: an adversary records your encrypted traffic today and decrypts it years later once the machine exists, so long-lived secrets are exposed right now even though the computer is not. Non-HNDL is a trust threat: forged signatures, fake certificates, and impersonated identities, which only become possible once a quantum computer is actually running. They run on two separate clocks.
| The two clocks | Harvest Now, Decrypt Later (HNDL) | Non-HNDL |
|---|---|---|
| Core question | Can data encrypted now be read later? | Can trust or identity be forged once the math breaks? |
| What it threatens | Confidentiality of stored and transmitted data | Integrity and authentication of signatures and certificates |
| When it bites | Live now, because collection is happening today | Only once a CRQC is real |
| Is anything collected in advance? | Yes, the ciphertext is harvested and stored today | No, the public key is already published; the attacker waits on hardware |
| Cryptographic drivers | RSA key transport, DH, ECDH, X25519 | RSA signatures, ECDSA, Ed25519, the certificate ecosystem |
| Primary replacement | ML-KEM (key establishment) | ML-DSA / SLH-DSA (signatures) |
| Worst case | Retroactive breach of long-lived regulated data | PKI collapse, forging an entire trust hierarchy at once |
Source: NIST, “NIST Releases First 3 Finalized Post-Quantum Encryption Standards,” August 13, 2024, nist.gov.
The split matters because it sets the order of work. HNDL is a present-day prioritization problem for anything with a long confidentiality lifetime, since the harvesting is happening while you read this. Non-HNDL trust attacks can’t happen until the machine exists, so they follow the arrival clock. Teams that blur the two either panic about signature forgery that isn’t imminent or wave off harvesting that already is.
When do I have to start migrating?
Sooner than the arrival of a quantum computer, and Mosca’s theorem is how you prove it to yourself. The rule is X + Y > Z. Read it as a runway check: your data has to stay secure for X years, migration takes Y years, and the protection may fall in Z years. If the first two together exceed the third, you’re already operating inside the danger zone, because future compromise is being locked in by present inaction.
| Mosca variable | What it measures | Why it gets underestimated |
|---|---|---|
| X | How long the data or trust must stay secure | Confused with system lifetime, contract length, or data-retention policy |
| Y | How long migration actually takes | Cryptography is buried in products, appliances, firmware, vendors, and legacy |
| Z | How long until the cryptography can be broken | Genuinely uncertain, so it gets hand-waved away |
Source: Michele Mosca, “Cybersecurity in an Era with Quantum Computers, Will We Be Ready?” IEEE Security & Privacy, 2018, ieeexplore.ieee.org.
Three things make this robust rather than a guessing game:
- X is the required security lifetime, not the retention policy. Health records, legal strategy, defense data, trade secrets, roots of trust, and firmware anchors all carry a long X. Ephemeral telemetry carries a short one. The forcing question for a leader is how long this must stay confidential and how long this signature must stay trustworthy.
- Y is almost always longer than executives expect, because it includes inventory, dependency mapping, vendor-support lag, procurement, rollout, trust-store updates, validator upgrades, and re-encryption, not the flip of a setting.
- Z is uncertain, and the theorem is built for that. Run three values, a conservative (earlier) Z, a moderate Z, and an optimistic (later) Z. Some assets fall into urgent territory under all three, and those are the ones that don’t need a resolved timeline to justify moving now.
What should I prioritize first?
The highest-consequence trust surfaces, and blast radius is how you find them. Blast radius measures consequence rather than vulnerability: how much depends on a control, how privileged it is, how far its failure spreads, and how hard recovery would be. It’s what lets two systems running the identical vulnerable algorithm sit at completely different priorities.
| Blast-radius dimension | The question it answers | What raises the score |
|---|---|---|
| Population | How many people, systems, or datasets depend on the exposed thing? | More dependents |
| Privilege | How powerful is the compromised trust, does it sign code, gate admin access, or authorize machine identity? | Higher privilege |
| Reachability | How exposed is the surface, public-facing, partner-facing, or internal only? | Easier to reach, though low reachability is not low consequence |
| Propagation | How far does the failure spread once it starts, one system or a cascade? | More cascading |
| Recovery complexity | How hard is it to contain and recover, rotate in a day or trust-store updates across a whole fleet? | Slower, wider recovery |
Source: derived from the CISA/NSA/NIST cryptographic-inventory guidance in “Quantum-Readiness, Migration to Post-Quantum Cryptography,” CISA, 2023, cisa.gov.
Prioritizing by blast radius puts the high-consequence surfaces first: root certificate authorities, high-value transport, identity federation, central token issuers, and code and firmware signing. Isolated, low-privilege, bounded systems wait. The payoff is a defensible reason for where a program starts. “We’re starting with these certificate and identity systems because their blast radius is highest” holds up far better than “we’re starting here because they use RSA.”
What is the machine the clock counts down to?
A cryptographically relevant quantum computer is a quantum computer large and stable enough to break the public-key cryptography protecting most digital infrastructure. It’s a threshold, not a description of any machine that exists. The line sits where a quantum computer could run Shor’s algorithm against real-world key sizes, RSA-2048 or larger and 256-bit or larger elliptic curves, in a practical amount of time. No CRQC exists today, and the gap between current hardware and this threshold is large.
The threshold is measured in logical qubits, error-corrected and trustworthy, rather than the raw physical qubits vendors announce. A single logical qubit takes hundreds to thousands of physical ones to build, which is why the published resource estimates land where they do:
| Target | Logical qubits (most-cited estimate) | Physical qubits after error correction |
|---|---|---|
| RSA-2048 | ~4,000 (about 6,100 in the 2019 estimate) | ~20 million (2021 estimate), under 1 million (2025 optimization) |
| 256-bit elliptic curve (ECDSA, ECDH) | ~2,330 | millions |
Sources: Craig Gidney and Martin Ekerå, “How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits,” Quantum 5, 433, 2021, arXiv:1905.09749.
Craig Gidney, “How to factor 2048 bit RSA integers with less than a million noisy qubits,” 2025, arXiv:2505.15917.
Martin Roetteler, Michael Naehrig, Krysta M. Svore, Kristin Lauter, “Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms,” ASIACRYPT 2017, arXiv:1706.06752.
The CRQC is the pivot of every honest quantum-risk conversation. In Mosca’s theorem it’s the Z variable. For HNDL it’s the event horizon that sets when harvested data becomes readable. For Non-HNDL and PKI collapse it’s the precondition the whole attack waits on. Progress toward a CRQC is a different thing from progress in quantum computing generally, so qubit-count press releases and quantum-advantage demos on non-cryptographic problems don’t move the date.
When will a quantum computer break RSA?
Nobody knows the exact year, and the honest way to handle that is the Quantum Threat Timeline, the annual expert-survey estimate that turns “someday” into a defensible range. Published by the Global Risk Institute with evolutionQ and lead-authored by Michele Mosca and Marco Piani, it polls cryptographers and quantum-hardware researchers for the probability that a CRQC capable of breaking RSA-2048 exists within 5, 10, 15, 20, and 30 years, then reports the distribution. It carries no regulatory authority, and that’s the point: its credibility comes from the panel and the methodology, not from a mandate.
Credible expert and government estimates span roughly 2030 to 2040 and beyond, and the distribution translates cleanly into the three scenario values Mosca’s theorem wants: a conservative Z from the earlier-arrival end, a moderate Z from the median, and an optimistic Z from the later end. Alongside the technical evidence sits a policy anchor: U.S. national-security policy under CNSA 2.0 sets 2035 as the completion date for migrating national-security systems, giving a fixed deadline independent of where the hardware timeline lands.
Source: Mosca, M. and Piani, M., 2024 Quantum Threat Timeline Report, Global Risk Institute / evolutionQ, globalriskinstitute.org; NSA, “CNSA 2.0 FAQ” (PP-24-4014, December 2024 update), media.defense.gov.
How do the models produce a migration queue?
You run them in sequence over the assets you’ve inventoried, and a ranked list falls out. The exposure is measurable today, so this is a working method rather than a thought experiment: a 2026 survey of 8,443 real-world Nginx TLS configurations found that 28.9% relied on RSA key exchange with no forward secrecy, meaning any session recorded today can be decrypted retroactively once the server’s long-term key is recovered. That’s a live HNDL exposure you can find right now with a scan.
The synthesis runs in four passes over a cryptographic inventory:
- Classify the exposure. For each asset, is it an HNDL confidentiality risk, a Non-HNDL trust risk, or both? This tells you whether the fix is a key-establishment replacement (ML-KEM) or a signature replacement (ML-DSA and SLH-DSA).
- Apply the clock. Run
X + Y > Zon the asset class. Long-lived data or trust plus a slow migration against a shorter break horizon means it starts now. - Size the consequence. Score blast radius across its five dimensions. High-consequence trust surfaces move to the front regardless of whether their exploitation is imminent.
- Sequence. The assets where long lifetime, slow migration, and high blast radius overlap are the first phase. Bounded, low-privilege, short-lifetime systems wait.
Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026), arxiv.org.
That queue is the handoff. The models tell you what’s urgent and why; turning it into a sequenced program against your own systems is where Doing the Work begins.
Common misconceptions
- “If a quantum computer doesn’t exist yet, there’s nothing to do.” The collection behind HNDL is happening now, and migration takes years, so long-lived data is exposed today even though the machine is not.
- “Every system that uses RSA is equally urgent.” Blast radius separates a bounded internal app from a root of trust. Consequence, not the presence of a vulnerable algorithm, sets the priority.
- “Mosca’s theorem predicts when quantum computers arrive.” It’s a timing framework, not a forecast. Z is an uncertain input, and the theorem is designed to prioritize despite that uncertainty.
- “HNDL and Non-HNDL are the same threat.” One is lost confidentiality, on a clock that’s already running. The other is forged trust, on the arrival clock. They need different replacements and different sequencing.
- “Qubit-count records mean a CRQC is close.” Those are noisy physical qubits on non-cryptographic problems. A CRQC needs thousands of error-corrected logical qubits, which is a separate and much harder milestone.
- “The Quantum Threat Timeline is a countdown.” It’s an aggregation of expert opinion and its spread, best read as scenario bands feeding a conservative, moderate, and optimistic Z.
Questions people ask
Which model do I use first? Start with the two exposure types to classify each asset, then apply Mosca’s theorem to decide urgency and blast radius to rank consequence. Classification comes first because it determines whether you’re replacing key establishment or signatures.
Which is more urgent, HNDL or Non-HNDL? For data with a long confidentiality lifetime, HNDL is the present-day priority because the harvesting is live now. For long-lived trust infrastructure like root certificate authorities, the Non-HNDL migration is also urgent because it takes years and has to finish before the machine arrives. Blast radius decides which specific systems lead.
What number do I use for Z? Don’t use a single number. Take three from the Quantum Threat Timeline expert range, an earlier conservative Z, a median moderate Z, and a later optimistic Z, and check whether an asset is urgent under all three. Assets urgent in every scenario don’t need a resolved date to justify moving.
Do these models tell me my exact deadline? They give you a defensible band, not a single date. Mosca’s theorem converts the uncertain arrival into a per-asset runway check, and the honest output is “these classes are urgent under any plausible timeline,” which is enough to sequence a program.
Is a bigger RSA key a valid mitigation? No. Shor’s algorithm scales polynomially in key length, so moving from RSA-2048 to RSA-4096 raises the quantum cost only modestly while adding classical overhead. The durable fix is migrating to the post-quantum standards.
Where does the inventory come from? From a CBOM, the algorithm-level inventory of where cryptography actually lives in your estate. The risk models are the lenses you apply to that inventory; without it, there’s nothing to prioritize.
What about symmetric encryption like AES? It’s largely fine. Grover’s algorithm only halves symmetric strength, so AES-256 and the SHA-2 and SHA-3 hashes stay safe. The entire quantum transition is a public-key story, which is why these models focus on key establishment and signatures.
Go deeper
The clock: Mosca’s Theorem gives the X + Y > Z runway check that turns the industry timeline into your own deadline, and The Mosca Inequality, Worked plugs real year-counts into it with concrete examples so you can calculate which of your own assets are already too late.
The two kinds of exposure: Harvest Now, Decrypt Later (HNDL) is the confidentiality clock that’s already running; Non-HNDL is the trust-forgery clock that waits on the machine; PKI Collapse is the worst case of Non-HNDL, where one broken certificate-authority key forges an entire trust hierarchy at once; Forge-Later Attack draws the honest line on how much of the trust-forgery risk actually has a “capture now” element and how much simply waits on the machine.
What to prioritize: Blast Radius is the consequence model that sorts equally-vulnerable systems into a real order.
The machine and the evidence: Cryptographically Relevant Quantum Computer (CRQC) is the threshold the whole clock counts down to; Quantum Threat Timeline is the expert-survey evidence for when it might arrive. The list of what actually falls is in Quantum-Vulnerable Algorithm.
The deadlines that make this migration mandatory are in the mandates, and turning a prioritized queue into a sequenced program is in Doing the Work.
Everything here is the map, given freely. When your team needs these models run against your own inventory and turned into a defensible migration sequence, that’s the work I do, and there’s an alignment briefing for it.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.