By ByteBot
The countdown to quantum-resistant cryptography is on. In 27 months, on January 1, 2027, all new National Security Systems acquisitions must comply with CNSA 2.0, meaning they must use post-quantum cryptographic algorithms. But here’s the uncomfortable truth: if you’re starting your PQC migration in 2026, you’re already late. While Q-Day—the moment quantum computers break current encryption—might arrive around 2030, adversaries aren’t waiting. They’re harvesting your encrypted data TODAY, banking on decrypting it tomorrow with quantum computers. NIST finalized three post-quantum standards in August 2024. The tools are ready. The deadline is set. So why are most organizations still running RSA and ECC like it’s 2015?
The “Harvest Now, Decrypt Later” Threat Isn’t Future-Tense
Adversaries aren’t sitting around waiting for quantum computers to arrive. They’re executing what’s known as “harvest now, decrypt later” (HNDL) attacks—capturing your encrypted data today, storing it, and planning to decrypt it the moment quantum computers become powerful enough. Q-Day estimates put that threshold somewhere between 2030 and 2035. That’s 4 to 9 years from now.
But here’s the problem: once quantum computers reach the threshold to break RSA or elliptic-curve encryption, it’s too late to protect data stolen years earlier. If your organization handles data that must remain confidential for 10+ years—financial records, healthcare data, national security information, intellectual property—you’re already exposed. The threat has arrived. The data harvest is happening right now.
Industry consensus is clear: planning, discovery, and inventory must complete within the next 2 to 4 years. This isn’t a drill. PQC migration can’t be reactive. By the time Q-Day arrives, you’ve already lost.
NIST Finalized the Standards. Time to Stop Making Excuses.
In August 2024, NIST finalized three post-quantum cryptography standards after years of international competition and rigorous evaluation. These aren’t experimental algorithms—they’re production-ready standards designed to withstand attacks from both classical and quantum computers.
ML-KEM (FIPS 203): Module Lattice-Based Key Encapsulation Mechanism, based on CRYSTALS-Kyber. This replaces RSA key exchange and ECDH for secure communications. If you’re using TLS or any protocol that establishes a shared secret, ML-KEM is your go-to.
ML-DSA (FIPS 204): Module Lattice-Based Digital Signature Algorithm, based on CRYSTALS-Dilithium. This is the primary standard for digital signatures, replacing RSA signatures and ECDSA. NIST added a new HashML-DSA variant for hash-then-sign scenarios.
SLH-DSA (FIPS 205): Stateless Hash-Based Digital Signature Algorithm, based on SPHINCS+. This serves as a backup standard with different security assumptions, useful for long-term security and specific use cases. It offers 12 parameter sets covering SHA2 and SHAKE variants.
Two additional standards are in progress: Falcon (digital signatures) and HQC (key encapsulation), selected in March 2025. The toolbox is expanding. The “waiting for standards” excuse expired in 2024.
The 5-Step Migration Roadmap You Should Have Started Yesterday
Here’s what developers and security teams need to do—starting right now in Q1 2026:
Step 1: Inventory (Q1 2026 – NOW)
Identify every single place you use cryptography. That means RSA, ECC, AES, Diffie-Hellman—everything. Map your data flows, trust relationships, and cryptographic dependencies. Use automated discovery tools if you have them, but don’t skip manual code reviews for critical systems. If you don’t know where your crypto lives, you can’t migrate it.
Step 2: Risk Assessment (Q1-Q2 2026)
Not all systems need to migrate at once. Prioritize based on data sensitivity and “shelf life.” Ask: how long must this data remain secret? Systems handling long-lifetime sensitive data (10+ years), national security systems, and critical infrastructure move to the front of the line. HNDL exposure is highest here.
Step 3: Testing (Q2-Q4 2026)
Set up a PQC sandbox environment using OpenSSL 3.5 or later. Test ML-KEM and ML-DSA in TLS. Measure performance—CPU usage, latency, bandwidth consumption. PQC keys and signatures are 10-100x larger than RSA/ECC, so you need to know how that impacts your systems. Test hybrid mode (classical + PQC) for backward compatibility. Document breaking points, MTU limits, and client-server compatibility issues.
Step 4: Hybrid Implementation (2026-2027)
Deploy hybrid cryptography configurations: run classical and PQC algorithms simultaneously. For example, pair X25519 (classical) with ML-KEM, or ECDSA with ML-DSA. This way, if one algorithm fails, the other still protects you. Start with low-risk, high-value pilots. Maintain backward compatibility. Roll out gradually—no “big bang” migrations.
Step 5: Full Migration (2027-2030+)
Migrate high-priority systems to pure PQC. Replace or retire legacy systems that can’t be upgraded. Maintain crypto-agility architecture so you can swap algorithms without downtime if future vulnerabilities emerge. Document everything for compliance and audits. This step takes YEARS, not months.
Developer Tools Are Ready. Use Them.
OpenSSL 3.5 shipped with native support for ML-KEM, ML-DSA, and SLH-DSA. If you’re running OpenSSL 3.5 or later, you can start testing PQC algorithms today. The Open Quantum Safe (OQS) project provides an OQS Provider for OpenSSL integration and a liboqs library for experimentation.
Major vendors are onboard. Red Hat’s OpenShift is targeting quantum-safe support in RHEL 9.8 and 10.2 (Spring 2026). Cloudflare has PQC support in TLS. wolfSSL supports ML-KEM and ML-DSA. First PQC certificates are expected in 2026, though they won’t be enabled by default yet. Production adoption will ramp through 2026-2027.
There’s no technical blocker here. If you’re not testing PQC in 2026, it’s a prioritization problem, not a tooling problem.
Yes, Migration Is Hard. Do It Anyway.
PQC migration comes with real challenges. Key and signature sizes are 10-100x larger, which strains bandwidth, storage, and latency budgets—especially for IoT devices, healthcare systems, and retail infrastructure. Legacy systems with hard-coded cryptography in firmware or protocols can’t be easily updated. Industrial control systems, satellites, medical devices, and smart meters may have 10-20 year operational lifetimes. You can’t just patch those over the air.
There’s also an expertise shortage. Only a small number of engineers worldwide have hands-on experience with lattice-based or hash-based cryptography. Many organizations lack full visibility into where and how they use cryptography across their environments. Enterprise-wide cryptographic transformation takes years.
But none of these challenges justify inaction. The solution is crypto-agility: design systems with abstraction layers so you can swap algorithms without rewriting everything. Use hybrid mode during the transition. Prioritize high-risk systems. Start training your teams. Partner with vendors who support PQC. Accept that migration takes years and start NOW.
The CNSA 2.0 deadline is January 1, 2027. The EU requires organizations to start transitioning by end of 2026 and migrate critical infrastructure by 2030. If you haven’t started planning, you’re already behind schedule.
Start Your Inventory Today
Post-quantum cryptography isn’t a future-proofing exercise. It’s a present-day emergency. NIST released the standards. OpenSSL shipped the tools. The 27-month countdown to CNSA 2.0 compliance is ticking. Adversaries are harvesting your data right now.
The question isn’t whether you’ll migrate to PQC. The question is whether you’ll finish before it’s too late.
