Post-quantum cryptography, Harvest Now Decrypt Later, the SIKE warning, crypto-agility, firmware, and why your cryptographic agility dashboard must never touch the Internet.
Harvest Now, Decrypt Later
Post-Quantum Cryptographic timelines mention jan 2027.
So why do I say today?
Because if an adversary is recording your encrypted traffic, their clock started the day they pressed record.
Not in 2027.
Now.
Every message you send with conventional encryption.
Today, if you run conventional encryption, you are at risk.
Because if your messages are recorded, you are facing a significant problem.
Prelude: Why This Is Critical – The Numbers Keep Falling
RSA and elliptic-curve cryptography protect almost every TLS handshake, VPN tunnel, code signature, and banking session on the planet.
Shor’s algorithm, running on a cryptographically relevant quantum computer (CRQC), breaks both.
For years, the comfort blanket was scale.
In 2019, the estimate for factoring RSA-2048 was roughly 20 million noisy qubits.
In May 2025, Google’s Craig Gidney cut that to under a million qubits, running for less than a week, under the same hardware assumptions.
In February 2026, Iceberg Quantum’s Pinnacle architecture claimed fewer than 100,000 physical qubits using QLDPC codes—in simulation, not in hardware.
In March 2026, Google Quantum AI estimated that 256-bit elliptic-curve keys could fall to fewer than 500,000 physical qubits in minutes—and chose to withhold the circuits, publishing a zero-knowledge proof instead.
The researchers judged the attack details sensitive enough to hold back.
No machine on Earth can run these attacks today.
My confidence that a CRQC exists in 2026: low.
My confidence that the estimates will keep falling faster than enterprise migrations move: very, very high.
The Core: Harvest Now, Decrypt Later – The Case for Starting Today
Here is the incredibly scary part.
A quantum computer does not need to exist today to steal today’s secrets.
An adversary only needs a network tap, a storage array, and patience.
Record the ciphertext now.
Decrypt it later.
That is Harvest Now, Decrypt Later (HNDL), and the U.S. government no longer treats it as theory—Executive Order 14412 opens by warning of the risk of adversaries collecting information now and decrypting it later.
The cleanest way to reason about HNDL is the inequality popularised by Michele Mosca of the University of Waterloo.
Let X be how many years your data must stay secret.
Let Y be how many years your migration will take.
Let Z be how many years until a CRQC exists.
If X + Y > Z, that data is already exposed.
Not in the future – now.
Run it against a real portfolio.
Medical records, sovereign contracts, defence designs, and biometric templates can easily need to stay confidential for 10 to 25 years.
Enterprise cryptographic migration—inventory, vendor upgrades, testing, re-certification—can consume 5 to 10 years, and FIPS 140-3 validation alone has been reported to average over 500 days from submission.
If Z turns out to be 15 years or less, the inequality already fails for much of the regulated data held today.
Encryption you migrate tomorrow cannot protect a packet captured yesterday.
Nothing conventionally encrypted is safe.
The SIKE Moment: When A Finalist Falls In An Hour
Post-quantum algorithms are new.
And new cryptography breaks.
SIKE—Supersingular Isogeny Key Encapsulation—was not a fringe proposal.
It reached the fourth round of NIST’s standardization process, counted Microsoft’s research team among its developers, and carried a $50,000 Microsoft cracking bounty.
In the summer of 2022, KU Leuven’s Wouter Castryck and Thomas Decru broke SIKEp434 in about 62 minutes on a single core of an Intel Xeon released in 2013.
The level-5 parameters, SIKEp751, fell in about 20 hours and 37 minutes.
No quantum computer.
No supercomputer.
One ordinary core and a “glue-and-split” theorem published by Ernst Kani in 1997.
I have coined a term for this—the SIKE Moment—the day a trusted algorithm collapses on commodity hardware, long after everyone stopped worrying about it.
The SIKE Moment is not a reason to distrust ML-KEM (FIPS 203), ML-DSA (FIPS 204), or SLH-DSA (FIPS 205), all finalized by NIST in August 2024.
Lattice cryptography has faced public cryptanalysis since the 1990s and hash-based signatures since Ralph Merkle’s work in 1979, while SIDH, the problem underneath SIKE, was only proposed in 2011.
But – It is a reason to plan for failure anyway.
NIST plainly agrees—it selected HQC in March 2025 as a code-based backup to the lattice standards.
A backup algorithm is worthless if your systems cannot switch to it.
Swappable, Not Hard-Coded: Designing for the Day AI Finds the Crack – Cryptographic Agility
Now add artificial intelligence to the threat model.
In January 2026, OpenSSL patched 12 vulnerabilities, and security firm AISLE reported that its autonomous AI system found all 12.
Three of those bugs had been sitting in the code since 1998 to 2000.
In June 2026, a high-severity use-after-free in OpenSSL’s PKCS#7 verification, CVE-2026-45447, was discovered by a researcher working with Claude.
Let me be precise about what these are.
They are implementation and tooling flaws, not mathematical breaks of the algorithms themselves.
But AI systems are now finding bugs that sat unnoticed in heavily audited cryptographic code for decades, and nobody can promise that the search for mathematical weaknesses will stay beyond their reach.
If that day arrives for an algorithm you hard-coded into ten thousand devices, every one of those devices becomes an attack surface overnight.
The defence is architectural, and it has a name: cryptographic agility.
- Never hard-code the algorithm. Negotiate it, configure it, or load it through a provider interface—OpenSSL 3 providers, a KMS, or an HSM policy—so that a swap is a configuration change, not a recompile.
- Go hybrid during the transition. Pair ML-KEM with X25519 so that an attacker must break both a classical and a post-quantum scheme to win.
- Maintain a Cryptographic Bill of Materials. OMB Memorandum M-26-15 treats a centralized, continuously updated cryptographic inventory as the foundation of every federal agency’s migration.
- Rehearse the swap. A runbook you have never executed is not a plan.
Firmware: The Cryptography Nobody Remembers Shipping
Every conversation about PQC drifts toward browsers and TLS.
The bigger risk sits lower in the stack.
Secure Boot chains, BMCs, TPMs, PLCs, smart meters, medical devices, automotive ECUs, and satellite modems all verify signatures in firmware—usually with RSA or ECDSA, and often with a root key or key hash fixed in boot ROM or one-time-programmable fuses at manufacture.
Industrial and embedded devices also tend to stay in service far longer than the laptops and servers around them.
That is why CNSA 2.0 gives software and firmware signing its most aggressive timeline: support and prefer by 2025, exclusive use by 2030, using the stateful hash-based schemes LMS and XMSS from NIST SP 800-208.
And firmware key hygiene is already worse than most boards realize.
In 2024, Binarly’s PKfail research found that more than 10% of analysed UEFI firmware images used untrusted test Platform Keys, some literally labelled “DO NOT TRUST”, in a supply-chain failure spanning 12 years.
If vendors could not replace a test key, I would not bet the enterprise on them having built a swappable signature algorithm.
So here is my call to action.
- Check the firmware. List every device that performs cryptography—servers, network gear, HSMs, IoT, OT, vehicles, medical equipment—and record its firmware version, signature algorithm, key size, and whether its root of trust is updatable.
- Count the devices at risk. Tally how many rely on RSA, ECDSA, or ECDH, how many anchor trust in immutable ROM keys or fuses, and how many are past vendor support—then write that number on the first slide of your next board deck.
- Develop the transition plan. Rank devices by data shelf-life and remaining service life, demand FIPS 203–205 and CNSA 2.0 roadmaps in every vendor renewal, schedule replacement for anything with a hard-coded root of trust, and put dates against every line.
Airgap the Cryptographic Agility Dashboard
Do all of this properly and you will have built something extraordinary.
A single dashboard showing every weak key, every vulnerable device, every unpatched firmware image, and every migration gap in the enterprise.
To you, that is a cryptographic agility dashboard.
To an attacker, it is a target list with directions.
That dashboard must be air-gapped.
You may have heard stories of hackers breaching nuclear launch codes.
I need to be straight with you: I can find no verified public case of that ever happening.
The documented stories are unsettling enough.
Former Minuteman launch officer Bruce Blair claimed that, until 1977, the authorization code for U.S. Minuteman missiles was eight zeroes—a claim the Air Force rejected in a document for Congress.
By 2010, Stuxnet had destroyed nearly a thousand centrifuges at Iran’s air-gapped Natanz facility, after attackers used USB drives to infect connected third-party companies.
And there are more documented cases, but you have probably heard of them yourself!
Two lessons follow.
- No system connected to the Internet is safe.
- And an air gap is a starting line, not a finish line—pair it with strict removable-media control, one-way data diodes for inbound inventory feeds, logged physical access, and two-person integrity for every change.
Your Enterprise Security Overhaul Needs to Begin Today
No cryptographic algorithm is perfect.
You need to design your systems with cryptographic agility in mind.
And that includes embedded devices.
Inventory.
Hybridize.
Abstract.
Rehearse.
Air-gap.
Swap.
Concretely: your next firmware release should verify an LMS signature, your next TLS terminator should negotiate an ML-KEM hybrid, and your next National Security System contract should name ML-KEM-1024 and ML-DSA-87 in writing.
And if you run security for any enterprise – start the firmware count this week.
HNDL is real.
What we do about it could be the most important security decision your organization makes – for the next 20-50 years.
Action must happen today!
Keep your data – safe.
Not just today – but for the next 20 years – or as long as necessary.
References
- Encryption Consulting—What Is CNSA 2.0?: https://www.encryptionconsulting.com/education-center/what-is-cnsa-2-0/
- NIST—IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
- The White House—Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks (PDF): https://www.whitehouse.gov/wp-content/uploads/2026/06/eo-14412.pdf
- Federal Register—Securing the Nation Against Advanced Cryptographic Attacks: https://www.federalregister.gov/documents/2026/06/25/2026-12909/securing-the-nation-against-advanced-cryptographic-attacks
- OMB—Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography: https://www.whitehouse.gov/wp-content/uploads/2026/06/M-26-15-Execution-of-the-Migration-to-Post-Quantum-Cryptography.pdf
- Sidley Data Matters—White House Issues Executive Orders on Quantum Innovation and Security: https://datamatters.sidley.com/2026/07/01/white-house-issues-executive-orders-on-quantum-innovation-and-security/
- Zscaler—Accelerating Post-Quantum Readiness Timelines: https://www.zscaler.com/blogs/product-insights/accelerating-post-quantum-readiness-timelines-new-executive-order-securing
- OpenPolicy—Twin Executive Orders Tackle U.S. Quantum Innovation and Resilience: https://www.openpolicy.co/resources/twin-executive-orders-tackle-u-s-quantum-innovation-and-resilience
- Craig Gidney, Google Research—How to Factor 2048 Bit RSA Integers With Less Than a Million Noisy Qubits: https://research.google/pubs/how-to-factor-2048-bit-rsa-integers-with-less-than-a-million-noisy-qubits/
- The Quantum Insider—Q-Day Just Got Closer: Three Papers in Three Months: https://thequantuminsider.com/2026/03/31/q-day-just-got-closer-three-papers-in-three-months-are-rewriting-the-quantum-threat-timeline/
- Michele Mosca—Cybersecurity in an Era With Quantum Computers: Will We Be Ready?: https://eprint.iacr.org/2015/1075
- PostQuantum.com—CNSA 2.0 for Defense Contractors: https://postquantum.com/cnsa-2-0/defense-contractors/
- Wouter Castryck and Thomas Decru—An Efficient Key Recovery Attack on SIDH: https://eprint.iacr.org/2022/975.pdf
- The Register—Post-Quantum Crypto Cracked in an Hour With One Xeon Core: https://www.theregister.com/security/2022/08/03/post-quantum-crypto-cracked-in-an-hour-with-one-xeon-core/1312703
- AISLE—AISLE Discovered 12 out of 12 OpenSSL Vulnerabilities: https://aisle.com/blog/aisle-discovered-12-out-of-12-openssl-vulnerabilities
- AISLE—AISLE Discovers 20 OpenSSL Zero-Days in 6 Months: https://aisle.com/blog/aisle-discovers-20-openssl-zero-days-in-6-months
- OpenSSL—Security Advisory, 27 January 2026: https://openssl-library.org/news/secadv/20260127.txt
- SecurityWeek—OpenSSL Patches High-Severity Vulnerability Found With AI: https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/
- CyberInsider—PKfail: Untrusted Keys Expose Major Vulnerability in UEFI Secure Boot: https://cyberinsider.com/pkfail-untrusted-keys-expose-major-vulnerability-in-uefi-secure-boot/
- BleepingComputer—PKfail Secure Boot Bypass Lets Attackers Install UEFI Malware: https://www.bleepingcomputer.com/news/security/pkfail-secure-boot-bypass-lets-attackers-install-uefi-malware/
- Binarly—BRLY-2024-005 PKfail Advisory: https://www.binarly.io/advisories/brly-2024-005
- Nextgov/FCW—Pentagon Insists Nuclear Missile Launch Code Was Never ‘00000000’: https://www.nextgov.com/digital-government/2014/01/pentagon-insists-nuclear-missile-launch-code-was-never-00000000/77351/
- Foreign Policy—Air Force Swears: Our Nuke Launch Code Was Never ‘00000000’: https://foreignpolicy.com/2014/01/21/air-force-swears-our-nuke-launch-code-was-never-00000000/
- Black Duck—Throwback Thursday: Whatever Happened to Stuxnet?: https://www.blackduck.com/blog/whatever-happened-to-stuxnet.html
About the Author
Thomas Cherickal is an Emerging Technologies Educator, acting as a Generative AI Consultant and a Quantum Computing Consultant based in Chennai, India, available for work globally, on a remote and asynchronous basis. He has 500+ published articles across 10+ platforms covering AI, agentic systems, quantum computing, LLMs, Local AI, Quantum AI, and other emerging technologies, for which he acts as a consultant. Skilled in Python, Golang, Rust, and Mojo. Find his work at thomascherickal.com and thomascherickal.github.io.
Let’s Work Together
Thomas writes for power users, developers, enterprises, and executive audiences on AI agent orchestration, enterprise AI deployment, local LLM deployment, quantum computing training and content, and emerging technology. Available for technology writing engagements, technology training, and AI/quantum upskilling sessions for individuals, teams, and enterprises.
- Technical Writing — deep, sourced, developer-grade long-form content
- AI Consulting for Content Strategy — helping teams communicate complex Generative AI systems clearly
- Quantum Consulting for Content Strategy — helping teams communicate complex quantum computing systems clearly
- CXO-Level AI/Quantum Briefings — cutting through the hype for decision-makers and executives
Connect on LinkedIn (linkedin.com/in/thomascherickal) for a free introductory chat.
Find Me On
- 📰 HackerNoon
- ✍️ Medium
- 💻 Hashnode
- 📬 Substack
- 🐙 GitHub
- 🏋️ Exercism
- ⭕ Code 360
- 🥷 CodeWars
- 🌲 Linktree
- 💡 LeetCode
- 🏆 HackerRank
- 📄 HubPages
- 🧠 Deep-ML
- 🏅 CodersRank
- 🌍 HackerEarth
- ❓ Quora
📬 Newsletter
Emerging tech, explained properly — thomascherickal.kit.com
Work With Me
| 1-on-1 Consults | Digital Products & Playbooks | Exclusive Member Content |
|---|---|---|
| topmate.io/thomascherickal | thomascherickal.gumroad.com | patreon.com/thomascherickal |
© 2026 Thomas Cherickal · The Digital Futurist · thomascherickal.com · thomascherickal.github.io · Chennai, India 🇮🇳
