Harvest Now Decrypt Later (HNDL): A CISA-Aligned Post-Quantum Cryptography Risk Briefing

What to protect, what will not fall over, and what to fund before Q-Day. Revised to answer a devil’s-advocate review.

September 2026 · Prepared by Narracomm

0. Bottom line up front

No cryptanalytically relevant quantum computer (CRQC) is known to exist, and harvest now, decrypt later (HNDL) is a rational adversary strategy that no open source shows is being carried out against U.S. traffic.

That uncertainty cannot be resolved, because passive copying cannot be detected. The response should be proportionate: urgent for the small set of links and archives carrying secrets that must stay protected into the 2040s, routine everywhere else.

A CRQC would not stop the internet. The irreversible risk is recorded traffic on those few high-value paths, and the fixes there compete for the same people and money as classical breaches that are happening now.

Decide this quarter:

Name the crown-jewel paths and stores: the specific links, enclaves and archives carrying weapons, sources-and-methods, diplomatic and nuclear material with protection needs beyond 2040. Expect dozens per organization, not thousands.
Protect those first with the controls that already work: less data in transit, fewer copies, shorter retention, dedicated or physically protected paths, and hybrid post-quantum key exchange where the endpoints support it and it has been tested.
Start PKI and code-signing planning in parallel: list long-lived roots and device certificates, and set a maximum certificate lifetime for new issuance.
Fund FIPS 140-3 / NIAP validation capacity before tightening the 2027 CNSA 2.0 acquisition gate, so the gate produces compliant products rather than waivers.
Hold oversight on crown-jewel coverage and validation throughput, not on percentage of enterprise inventory completed.

1. What is established, what is assessed, and what is unknown

The easy argument is won: a CRQC would not stop packet routing, DNS or AES-256. The harder questions are whether the threat justifies urgent spending, how it ranks against current threats, and which actions are worth scarce operator time. Those rest on evidence of uneven strength, and this briefing grades it openly.

Claim	Status	Basis
Shor’s algorithm on a CRQC breaks RSA, DH, ECDH, ECDSA, EdDSA	Established	Mathematics; standard in NIST and NSA guidance
AES-256 and SHA-384/512 remain adequate	Established	Grover gives ~128-bit effective strength; CNSA 2.0 keeps AES-256
Bulk interception at carriers, clouds and chokepoints occurs	Established as a classical SIGINT fact	Open reporting over two decades
Adversaries are retaining ciphertext specifically to decrypt with a CRQC	Assessed, not observed	Capability plus incentive; CISA/NSA/NIST warning (2023); NSM-10
A CRQC exists	No public evidence	Current machines are NISQ; “supremacy” results were on non-cryptographic sampling tasks
A CRQC arrives in the 2030s	Plausible, contested	Expert surveys show wide disagreement
Resources needed to break RSA-2048 have fallen	Established as a paper result	~20M noisy qubits (2019) → <1M, about a week (2025), under stated assumptions such as 0.1% gate error and a 1 µs surface-code cycle

Two points follow. First, HNDL cannot be disproven: nobody can detect passive copying, so “assume they are doing it well” can never be shown wrong. That doesn’t make HNDL false, but it isn’t a measurement either. It can be used to measure risk.

Second, the 2025 resource estimate is a real reduction, but it describes a machine that has not been built. It justifies earlier planning. It does not by itself justify an enterprise-wide crash program.

2. Planning under uncertainty: Mosca’s inequality as sensitivity analysis

Mosca’s inequality says that if a secret’s shelf life (X) plus migration time (Y) exceeds the time until a CRQC exists (Z), that secret is at risk. It is a useful rule, but two of its three inputs are estimates. Z is a probability distribution with a long tail on both sides. Y depends on scope and on how many waivers are granted. X is a records-management judgment, and left unchecked, over-cautious tagging will label everything a 25-year secret, which guarantees the inequality always triggers.

Use it as a sensitivity test, not a verdict:

Data held today	Shelf life	CRQC in 2032	CRQC in 2037	CRQC in 2045
Weapons design, nuclear, sources and methods	40+ yrs	Exposed	Exposed	Exposed
Diplomatic, SCI finished intelligence	25 yrs	Exposed	Exposed	Exposed
DIB CUI, export-controlled technical data	15 yrs	Exposed	Exposed	Marginal
Health, legal, M&A archives	10 yrs	Exposed	Marginal	Not exposed
Payment sessions, retail TLS	< 1 yr	Not exposed	Not exposed	Not exposed

The first two rows stay exposed under every scenario, including a CRQC that slips to 2045. That is the defensible urgency. Everything below them depends on which CRQC date you assume, and it should be funded like any other risk.

Guard against over-tagging. Require a named owner to set a shelf life above 15 years, and have it reviewed. A tagging exercise that marks the whole estate as long-lived produces an unfundable program and hides the items that matter.

The fix carries risk too. ML-KEM and ML-DSA rest on lattice assumptions that are much younger than RSA’s. NIST selected HQC as a backup key-encapsulation algorithm in 2025 for exactly this reason. Hybrid designs and hash-based signatures (SLH-DSA, LMS/XMSS) are hedges against the cryptanalytic risk of the fix itself, not just against the quantum risk.

3. Opportunity cost: where HNDL ranks

The same CIO, NSA, CISA, acquisition and DIB security staff are responsible for current problems that need no CRQC:

ransomware and wipers against OT;
ongoing foreign collection against poorly segmented CUI;
identity, logging and patching on systems already being breached classically;
the FIPS 140-3 validation backlog, which slows every cryptographic upgrade, quantum or not.

Rank HNDL below active classical compromise on the same systems. If an adversary already has an implant on a DIB design server, post-quantum TLS on its uplink changes nothing. Where a crown-jewel path is also classically exposed, fix the classical exposure first.

Fund recapitalization on its own merits. Replacing 20-year controllers is slow because of certification and budget cycles, not because of quantum physics. Labeling OT refresh as “HNDL” helps it get funded but ties it to a narrative that weakens if the CRQC date moves out. OT refresh is justified today by ransomware, safety and supportability, and the case should be made on those grounds, with post-quantum support as a requirement of any new purchase.

Be wary of readiness as a product. Post-quantum readiness assessments, cryptographic bill of materials (CBOM) tooling and inventory dashboards are a vendor market. Public-web migration happened because browsers and CDNs shipped hybrid key exchange, not because of mandated inventories. Buy tools that shorten time to protect a named path, not ones that report a percentage.

4. Threat mechanics: concentration, not universality

Three phases

Intercept, store, decrypt. Only decryption needs a CRQC. Storage is cheap. Indexing, attribution, retention decisions and, above all, CRQC machine time will be scarce and expensive.

A CRQC will be a scarce, tasked asset

Shor’s algorithm recovers one key at a time. A first-generation CRQC, if it arrives, will be a small number of machines, each taking hours to days per key under current estimates. It will be assigned by analysts. Most of what is collected at a chokepoint is low-value and short-lived. The sessions worth that time are few, and many of them are already targeted by better present-day means, such as endpoint compromise and insider access, that do not require waiting for fault-tolerant hardware.

Implication: the value at risk is concentrated in a small number of links and archives. Defense should be concentrated too. The work plan in §7 protects named paths first rather than surveying everything.

Why forward secrecy does not help against HNDL

TLS 1.3 and IKEv2 forward secrecy protect past sessions if a long-term key is stolen. They do not help if the ephemeral exchange is classical ECDH, because the recorded handshake contains exactly what Shor’s algorithm needs. On a crown-jewel path, only post-quantum or hybrid key establishment closes that gap. So do controls that stop the traffic from existing on a collectable link at all.

What a CRQC does not buy

It does not break AES-256 in practice or give control of routed traffic, and it does not decrypt every archive at once. The irreversible loss is limited to classically keyed sessions an adversary chose to keep, and then chose to spend machine time on.

5. Two clocks, and why Clock B cannot wait

Clock A: recorded sessions (confidentiality)

Anything recorded today under classical-only key exchange can be read after a CRQC exists. The fix is hybrid KEM (key encapsulation mechanism), which combines a classical and a post-quantum exchange: ML-KEM-1024 under CNSA 2.0 for National Security Systems, and X25519MLKEM768 on the commercial web. Hybrid key exchange works with today’s classical certificates, so do not wait for post-quantum certificates to turn it on.

Clock B: impersonation after a CRQC exists (authenticity)

Forging a certificate or code signature requires a CRQC at the time of the attack. That makes Clock B later, but not optional, and it is the harder of the two. On the day a CRQC is credibly reported, every root, device certificate and signing key that is still trusted becomes a live impersonation risk. Organizations with 10-year device certificates and air-gapped signing ceremonies cannot rotate in 72 hours. Stateful hash-based signing (LMS/XMSS) takes operational discipline, and ML-DSA roots take years to distribute.

Don’t declare victory on Clock A and let Clock B slide. Measure progress on Clock B now with metrics you can act on: maximum certificate lifetime for new issuance, the number of roots valid past 2035, and the share of new firmware platforms with a post-quantum or hash-based signing path. Turning on hybrid key exchange is quick; fixing Clock B takes years.

6. What the fixes actually cost

Hybrid key exchange is not free

Middleboxes: larger handshakes break older firewalls, TLS inspection appliances and load balancers. The failures appear in production-like testing, not in the lab.
New code, new bugs: hybrid is “no weaker than the stronger half” only if the combiner, the implementation and downgrade handling are correct. Side channels and misconfiguration are real risks in young code.
Certification: constrained and certified systems can’t take the larger keys without recertification, and recertification sets the schedule, not the standards process.
Coverage: browsers and edges moved fast (Cloudflare reported a majority of human-initiated traffic at its edge using post-quantum key agreement in late 2025). Origin servers, site-to-site VPNs and IKE lag behind. Crown-jewel paths often end on exactly the systems that can’t yet move.

Conclusion: enable hybrid key exchange where it’s supported and tested. It’s sensible practice, but it doesn’t finish the job for SCI bearers, OT or coalition links.

Inventory produces paper unless it is scoped

OMB M-26-15 (June 2026) already requires federal agencies to maintain a continuously updated cryptographic inventory, and the June 2026 executive order directs CISA guidance on CBOMs. Certificate and library data go stale in months, and firmware, HSM and archive estates rarely appear in a clean configuration database.

A 100 percent target leads either to made-up numbers or to an endless exception list. Inventory what you will act on: crown-jewel paths end to end, the keys that wrap long-lived archives, and signing roots. Treat the rest as ordinary configuration management.

Re-wrapping archives protects your copy, not theirs

If an adversary already copied the ciphertext and the wrapped key blob, re-wrapping your remaining copies does nothing to theirs. Re-wrapping protects your own storage against future theft. It does not undo past collection. Finding every RSA-wrapped key across tape, backup appliances, cloud snapshots and partner shares is harder than the cryptography. The most effective archive control is often retention: delete what no longer needs keeping. A risk acceptance counts as a control only if it has a named owner and an expiry date and is reviewed. Otherwise it’s just a memo an inspector general will later quote.

The 2027 acquisition gate needs validated supply

From 1 January 2027, new NSS acquisitions must support CNSA 2.0 unless an exception is documented. A hard gate without validation capacity produces waivers or a small pool of vendors charging premium prices.

Flowing the same dates down through DFARS to subcontractors who can’t yet field ML-KEM-1024 and ML-DSA-87 produces paper compliance. Sequence it: fund validation throughput, publish realistic phase-in for subcontractors, and report exceptions openly rather than hiding them in awards.

QKD, and the rest of the market

NSA does not support QKD for National Security Systems. It needs dedicated links, doesn’t authenticate on its own, and doesn’t protect stored data or endpoints. Keep it out of NSS architecture. Apply the same skepticism to post-quantum readiness products that report scores instead of protected paths.

7. Operator work plan (ranked by value, not by calendar)

Now: crown jewels

Name the crown-jewel paths and stores: the links, enclaves and archives carrying secrets needing protection beyond 2040. Assign an owner to each, and require review for any shelf life above 15 years.
Cut exposure on those paths without new cryptography: reduce data in transit, remove redundant copies, shorten retention, and move traffic to dedicated or physically protected paths where already authorized.
Fix classical exposure first on those same systems: segmentation, identity, logging and patching.
Enable hybrid key exchange on crown-jewel paths where both ends support it and it has passed production-like testing. Record which paths can’t, and why.

Next 12 months: both clocks

Inventory signing roots and long-lived certificates. Set a maximum lifetime for new certificates. Count roots still valid after 2035.
Pilot ML-KEM and ML-DSA on one external service and one site-to-site VPN. Measure handshake size, latency, middlebox failures and operational load.
Build a post-quantum firmware-signing path (LMS/XMSS or approved ML-DSA) for new platforms, including the state management that stateful hash-based signatures require.
Map archive-wrapping keys for crown-jewel stores only. For each archive, choose one: delete, re-wrap, or accept the risk with an owner and an expiry date.
Run a Clock B tabletop: “A peer credibly reports a CRQC. Which identities can we actually rotate in 30 days? 180?” Fund the gaps it reveals.

Through 2027–2031: routine migration

Buy CNSA 2.0-capable systems for NSS as validated products become available. Report exceptions; don’t bury them.
Meet the category dates: under CNSA 2.0, firmware signing and traditional networking equipment exclusively by 2030, and the rest by 2033. Under 2026 executive direction, federal high-value assets need post-quantum key establishment by end of 2030 and signatures by end of 2031. Commercial dependencies should follow NIST’s IR 8547 direction: deprecate RSA-2048 and 256-bit curves around 2030 and disallow them by 2035.
Fund OT refresh on its own grounds (ransomware, safety, supportability) and make post-quantum support a purchase requirement.
Build in crypto agility so the next algorithm change, including a switch to a backup such as HQC, is a configuration change.

8. Hill / oversight agenda

Oversight questions

How many crown-jewel paths and archives has each component named, and who owns each one?
On those paths, what share still uses classical-only key exchange, and what share has open classical findings such as segmentation, identity or patching?
What evidence supports each component’s HNDL assessment, and how does it separate observed collection from capability-plus-incentive inference?
What CRQC date assumption drives each component’s plan, and what changes if it moves five years in either direction?
What is the FIPS 140-3 / NIAP validation queue for post-quantum modules, and what would clear it before the 2027 gate?
How many CNSA 2.0 exceptions have been granted since January 2026, and in which product categories?
How many signing roots and device certificates remain valid past 2035, and what is the maximum lifetime of certificates issued today?
Which archives have been deleted, re-wrapped or risk-accepted, and do the acceptances have owners and expiry dates?
Is OT refresh funding justified on ransomware, safety and supportability grounds independent of quantum risk?
How much is being spent on post-quantum readiness products that measure progress rather than protect paths?

Funding priorities

Fund validation capacity, interoperability testbeds, crown-jewel path hardening and PKI modernization. Fund OT refresh as a separate line on its own merits. Don’t fund a public-internet quantum program, enterprise-wide inventory targets, or QKD for NSS.

Legislative do and don’t

Do: require named crown-jewel coverage reporting; tie procurement gates to validated supply; require public exception counts; set Clock B metrics (certificate lifetimes, long-lived roots).
Don’t: use 100 percent inventory as the success measure; name QKD as the national fix; set a single Q-Day date; mandate post-quantum certificates before the ecosystem can issue them; tie OT recapitalization to a quantum timeline.

Allies

A classical-only coalition link carrying crown-jewel traffic is a collection route around U.S. protections. Coordinate on those specific links first, not on whole-of-network timelines.

9. What “done” looks like

Every named crown-jewel path uses approved post-quantum or hybrid key exchange, or has a documented, owned and time-limited alternative (dedicated path, reduced transit, deletion).
No crown-jewel path has open high-severity classical findings.
New certificates have a defined maximum lifetime, and the count of roots valid past 2035 falls each year.
New firmware platforms ship with a post-quantum or hash-based signing path.
CNSA 2.0 exceptions are reported publicly and decline year over year as validated supply grows.
Federal high-value-asset deadlines (end of 2030 for key exchange, end of 2031 for signatures) are met.

10. Closing

The failure is quiet and after the fact, and that remains the strongest reason to act. But the payoff to an adversary is concentrated in a small number of links and archives, the machine that would unlock them is still a paper design, and the people who would protect them are also fighting classical breaches today.

The right response is proportionate. Protect the crown jewels now with every tool available, cryptographic and not. Start the slow work on signing roots and certificates, because that clock can’t be shortened at the last minute.

Let the rest of the migration run on normal procurement cycles, funded on its own merits. Don’t turn a careful correction of “the internet dies” into a new mandatory program measured in inventory percentages.

For a commander: Name the handful of links carrying secrets that must survive past 2040, protect those first with every control we have, and start rotating long-lived identities now, because that can’t be rushed later.

For a member: The risk is real but concentrated. Fund validation capacity and crown-jewel protection, demand evidence and exception counts, and don’t buy a quantum program measured in spreadsheets.

Sources

CISA, NSA and NIST, Quantum-Readiness: Migration to Post-Quantum Cryptography (August 2023): https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography
National Security Memorandum 10 (May 2022): https://www.presidency.ucsb.edu/documents/memorandum-promoting-united-states-leadership-quantum-computing-while-mitigating-risks
Gidney and Ekerå, How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits (2019): https://arxiv.org/abs/1905.09749
Gidney, How to factor 2048 bit RSA integers with less than a million noisy qubits (2025): https://arxiv.org/abs/2505.15917
Global Risk Institute, Quantum Threat Timeline Report 2024: https://globalriskinstitute.org/publication/2024-quantum-threat-timeline-report/
Cloudflare, State of the post-quantum Internet in 2025: https://blog.cloudflare.com/pq-2025/
NSA, CNSA 2.0 FAQ: https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
NIST, FIPS 203/204/205 release (August 2024): https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
NIST, draft IR 8547, Transition to Post-Quantum Cryptography Standards: https://csrc.nist.gov/news/2024/draft-nist-ir-8547-is-available-for-comment
NIST selects HQC as a backup KEM (March 2025, HPCwire): https://www.hpcwire.com/2025/03/12/nist-selects-hqc-as-fifth-algorithm-for-post-quantum-encryption/
OMB M-26-15, Execution of the Migration to Post-Quantum Cryptography (June 2026): https://www.whitehouse.gov/wp-content/uploads/2026/06/M-26-15-Execution-of-the-Migration-to-Post-Quantum-Cryptography.pdf
June 2026 executive order on PQC deadlines (Cybersecurity Dive summary): https://www.cybersecuritydive.com/news/quantum-cryptography-white-house-executive-order/823530/
NSA, Quantum Key Distribution (QKD) and Quantum Cryptography: https://www.nsa.gov/Cybersecurity/Quantum-Key-Distribution-QKD-and-Quantum-Cryptography-QC/

Annex A — Member / Commander card

BLUF: HNDL is a rational strategy and an unproven campaign. No CRQC is known to exist. The risk is irreversible but concentrated in a small number of links and archives carrying secrets that must survive past 2040. Protect those now. Start the slow work on signing roots. Let the rest migrate on normal cycles.

Three facts

A CRQC would break public-key cryptography (RSA, elliptic curve), not AES-256, routing or DNS.
The best public estimate for breaking RSA-2048 fell below one million noisy qubits in 2025, under stated assumptions. No such machine is known to exist.
NIST post-quantum standards are final (FIPS 203/204/205, 2024), the CNSA 2.0 acquisition gate starts 1 January 2027, and federal high-value-asset deadlines are end-2030 (key exchange) and end-2031 (signatures).

Three myths

“Q-Day stops the internet.” It threatens confidentiality and authenticity, not availability.
“We know they’re harvesting our traffic.” It is assessed from capability and incentive, not observed.
“A complete inventory means we’re safe.” Protected crown-jewel paths mean you’re safe. Inventory percentages don’t.

Five actions

Name the crown-jewel paths and archives, each with an owner.
Protect them first: less transit, fewer copies, shorter retention, fixed classical findings, hybrid key exchange where tested.
Set maximum certificate lifetimes, and count roots valid past 2035.
Fund validation capacity before tightening the 2027 gate.
Fund OT refresh on its own merits. Keep QKD out of NSS.

Annex B — Glossary

AES-256: Symmetric cipher retained by CNSA 2.0. About 128-bit effective strength against Grover’s algorithm.
Asymmetric (public-key) cryptography: Key pairs used for key exchange and signatures (RSA, ECDH, ECDSA). This is what Shor’s algorithm breaks.
CBOM: Cryptographic bill of materials, a list of the cryptography a product or system uses.
CNSA 2.0: NSA’s required algorithms and timelines for National Security Systems.
Crown-jewel path: A named link, enclave or archive carrying secrets needing protection beyond 2040.
CRQC: Cryptanalytically relevant quantum computer, a fault-tolerant machine able to run Shor’s algorithm at real key sizes. None is known to exist.
Forward secrecy: Fresh key exchange per session. It does not defeat HNDL if that exchange is classical.
HNDL: Harvest now, decrypt later. Retaining ciphertext to decrypt after a CRQC exists.
HQC: A code-based key-encapsulation algorithm selected by NIST in 2025 as a backup to ML-KEM.
Hybrid KEM: Key establishment combining classical and post-quantum algorithms (e.g., X25519MLKEM768).
LMS / XMSS: Stateful hash-based signatures approved for firmware and software signing.
ML-DSA / ML-KEM: NIST’s lattice-based post-quantum signature (FIPS 204) and key-encapsulation (FIPS 203) standards.
Mosca’s inequality: Shelf life + migration time > time to CRQC means exposure. Best used as a sensitivity test, not a verdict.
NISQ: Noisy intermediate-scale quantum, today’s error-prone devices.
QKD: Quantum key distribution. It needs dedicated links, and NSA does not support it for NSS.
SLH-DSA: NIST’s stateless hash-based signature standard (FIPS 205), a hedge against lattice weaknesses.