The decision
The cost of waiting
Data captured today can be decrypted later — the timeline is unknown, which is exactly why waiting for certainty is the expensive choice.
6 min read · 6 min 28 sec film
What you'll be able to do
- Explain harvest-now-decrypt-later risk without predicting when a capable quantum computer will exist.
- Apply the Mosca heuristic as a planning tool, not a measurement.
- State which post-quantum standards are final today and which are still drafts.
Lesson film
Watch: The cost of waiting
Nobody can tell you when. That turns out not to matter, because the decision never depended on knowing.
6 min 28 sec · 8 scenes
6 min 28 sec, narrated by your browser's voice. Captions and a full transcript are below — nothing here needs sound.
The most common reason organisations do nothing about this is a reasonable-sounding one.
With the player focused: Space plays or pauses, ← → seek ten seconds, Home restarts, M toggles narration.
Full transcript
1. The uncertainty argument
2. Recorded today, read later
3. Three numbers
4. Why the ranking holds
5. What is actually settled
6. Answering the objection
7. One migration already happened
8. Takeaway
The written lesson
Some data captured on the wire today can be decrypted later, once a sufficiently capable quantum computer exists. No such machine exists today, and this course will not predict when one will. That uncertainty is not a reason to wait — it is the reason waiting is expensive.
- X — secrecy lifetime
- How many years this data must stay confidential. A contract clause: months. A patient record or a state secret: decades.
- Y — migration time
- How many years your organization actually needs to find, prioritize, fund, and migrate the systems that protect this data.
- Z — time to a capable machine
- Unknown. No one can measure it, and anyone who gives you a confident date is guessing.
The heuristic: if remaining secrecy time X plus migration time Y exceeds an assumed capability horizon Z, delaying the program may leave future data exposed. An already captured record instead depends on its remaining secrecy need and whether its captured protection path can later be broken. Z is uncertain, so use scenarios rather than treating the inequality as a forecast or proof of capture.
| Body | Status | What it means for you |
|---|---|---|
| NIST FIPS 203, 204, 205 (ML-KEM, ML-DSA, SLH-DSA) | Final — published August 2024 | Core key establishment and signature algorithms are final; protocol, product, and interoperability readiness still need checking. |
| HQC (backup key-establishment algorithm) | Selected March 2025, not yet standardized | A backup exists if ML-KEM is ever weakened. Do not deploy it as a primary choice yet. |
| A FALCON-based signature standard | Under development, not final | Expect a smaller-signature option later; do not plan around it today. |
| NIST IR 8547 (deprecating classical algorithms) | Initial public draft | Proposes deprecating 112-bit classical public-key algorithms after 2030 and disallowing them after 2035 — a signal, not yet a rule. |
| NSA CNSA 2.0 | Published requirement, milestones into the early 2030s | Check whether a specific national-security-system obligation or customer contract applies; do not infer a general enterprise deadline. |
Hybrid key exchange, combining classical and post-quantum mechanisms such as the standardized TLS group X25519MLKEM768, is available in some deployed paths. Do not infer end-to-end protection from a browser or CDN setting: inspect negotiated connections through to origins and partners. Authentication, signatures, certificates, and long-lived trust roots are separate migration workstreams whose order depends on the system.
| Claim type | What a leader should check |
|---|---|
| Algorithm standard | Is the algorithm published as a final FIPS, selected for future standardization, or still under development? |
| Protocol and product support | Which version is implemented and actually negotiated; what are the compatibility limits? |
| Transition guidance | Is this a published rule or a draft proposal; which algorithms and strengths are in scope? |
| Contract or program obligation | Does it apply to this organization, a specific customer, system, or vendor contract? |
A final algorithm standard does not automatically make every protocol, device, HSM, or vendor ready. A draft transition date is useful for planning but is not itself a binding deadline. Record the precise source and applicability of any claimed requirement, then use exposure and migration lead time to decide whether earlier work is justified.
Primary reading and claim sources
Publication status checked on the date shown. Draft guidance can change.
- Selected Algorithms for StandardizationNIST · Current project status · checked 2026-09-26
- IR 8547: Transition to Post-Quantum Cryptography StandardsNIST · Initial public draft; proposed dates are not final rules · Transition tables and introduction · checked 2026-09-26
- Commercial National Security Algorithm Suite 2.0 FAQNSA · Published guidance for National Security Systems and applicable vendors; December 2024 update · checked 2026-09-26
- Cybersecurity in an Era with Quantum Computers: Will We Be Ready?Michele Mosca · Research paper · checked 2026-09-26
- TR 104 016: A Repeatable Framework for Quantum-Safe MigrationsETSI · Published technical report · checked 2026-09-26
Marking a lesson complete only updates this browser.