Why Your PQC Migration Timeline Is Wrong
Most enterprises have post-quantum cryptography migration penciled in for 2030-2035. That timeline assumes Q-Day — the moment a cryptographically relevant quantum computer exists — is the starting gun. It isn't. The starting gun fired years ago, and every month of delay compounds the damage.
The Clock Already Started
The NSA, CISA, and every serious intelligence agency operates under a doctrine called Harvest Now, Decrypt Later (HNDL). The premise is straightforward: intercept and store encrypted traffic today, decrypt it when quantum hardware matures.
This isn't theoretical. Nation-state actors have the storage capacity and the strategic patience. If your organization transmits data that will still be sensitive in 10-15 years — financial records, health data, trade secrets, legal communications, infrastructure credentials — that data is already at risk. Not at risk someday. At risk now, in a vault, waiting.
HNDL means the threat model isn't "when can they break our encryption?" It's "how much of our encrypted traffic have they already captured?"
Every day you transmit RSA-2048 or ECDH-256 protected data across the public internet is another day of material added to that vault.
What CNSA 2.0 Actually Requires
In September 2022, the NSA released CNSA 2.0 — the Commercial National Security Algorithm Suite. The timelines are explicit:
- By 2025: Begin using ML-KEM (FIPS 203) for key establishment in new systems
- By 2030: All national security systems must use post-quantum algorithms exclusively
- By 2033: All legacy public-key cryptography must be deprecated
NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. The standards are done. The algorithms are standardized. There is nothing left to wait for.
If you're in defense, intelligence, or critical infrastructure, these deadlines are mandatory. If you're in commercial enterprise, you have less institutional support and slower procurement cycles — which means you need to start sooner, not later, to hit the same window.
The Three Things Enterprises Get Wrong
1. They think they have until Q-Day
Q-Day is irrelevant if your threat model includes HNDL. The question isn't when quantum computers arrive — it's how long your data needs to stay confidential. If the answer is more than 10 years, you're already in the exposure window.
The calculation is simple: Migration Time + Data Shelf Life > Time to Q-Day = Breach. Most enterprises have a migration timeline of 3-7 years and data that needs 10-25 years of confidentiality. The math doesn't work in your favor.
2. They don't know what cryptography they're running
Ask your CISO what cryptographic algorithms are in use across your organization. Most can name what's in the VPN and maybe TLS on the web servers. Almost none can tell you what's in the firmware update signing chain, the database connection strings, the IoT device authentication, the SCADA control protocols, or the third-party SaaS integrations.
You cannot migrate what you cannot inventory. Cryptographic discovery is the unsexy first step that most organizations skip, and it's the step that determines whether your migration takes 18 months or 5 years.
3. They plan migration as a project, not a process
PQC migration is not a one-time certificate rotation. It's a multi-year process that touches every layer of the stack: TLS libraries, key management systems, HSMs, certificate authorities, API authentication, firmware signing, database encryption, backup encryption, email encryption, and every third-party integration that touches any of those.
You don't replace RSA with ML-KEM in a sprint. You run hybrid mode — classical and post-quantum algorithms simultaneously — for months or years while you validate interoperability, measure performance impact, and build operational confidence.
What Migration Actually Looks Like
A credible PQC migration has five phases:
Phase 1 — Cryptographic Inventory. Automated discovery of every cryptographic algorithm, key length, certificate, and protocol in use across your infrastructure. This includes network traffic analysis, binary inspection, configuration scanning, and dependency auditing. The output is a complete map of your cryptographic surface area.
Phase 2 — Exposure Scoring. Not all crypto is equally urgent. Score each instance by: data sensitivity, exposure to public networks, regulatory requirements, and remaining certificate lifetime. A customer-facing TLS endpoint using ECDH-256 is more urgent than an internal database connection using AES-256-GCM (which is already quantum-resistant for confidentiality).
Phase 3 — Prioritized Replacement. Start with the highest-exposure, lowest-complexity targets. External-facing TLS endpoints are usually first. Then VPN tunnels. Then internal service-to-service communication. Then firmware signing. Then everything else.
Phase 4 — Hybrid Mode. Run ML-KEM alongside classical algorithms. This protects against quantum threats while maintaining backward compatibility with systems that haven't migrated yet. NIST explicitly recommends hybrid approaches during the transition period.
Phase 5 — Validation and Deprecation. Verify that post-quantum algorithms are performing correctly under production load. Monitor for interoperability issues. Once confidence is established, deprecate classical algorithms and remove them from the approved configuration.
The Cost of Waiting
Every quarter you delay Phase 1 is another quarter of HNDL-exposed traffic, another quarter of compliance drift from CNSA 2.0, and another quarter closer to the deadline with the same amount of work remaining.
The organizations that start cryptographic inventory today will complete migration on schedule. The organizations that wait for Q-Day headlines will discover they needed 5 years and have 18 months.
Start With Discovery
Matrix CR Studio's PQC-Scout automates Phases 1 and 2. It scans your infrastructure, inventories every cryptographic algorithm in use, scores each one for quantum exposure (CRITICAL / HIGH / MONITOR), and delivers a prioritized migration roadmap aligned to NIST FIPS 203/204/205 and CNSA 2.0 timelines.
The assessment takes days, not months. The output is a map of exactly what needs to change and in what order.
You can't migrate what you can't see. Start seeing.