The Quantum Deadline Nobody Had on a Calendar

A few months ago I got pulled into a planning session that was supposed to be about certificate renewals. It turned into something bigger fast: someone on the call asked, "so what's our actual plan for Q-Day?" and the room went quiet. Not because nobody had thought about it — everybody had a fragment. Someone knew we needed to move off RSA eventually. Someone else had read about ML-KEM. Nobody had it written down as a sequence with an owner and a deadline. That's the moment I realized most quantum readiness in the wild is a folder of good intentions, not a roadmap.

So I went and built one, and I want to walk through what it actually looks like in practice, not in a vendor deck.

Step One Is Boring, and That's the Point

Every version of this roadmap I've seen — including the joint guidance from CISA, the NSA, and NIST — starts in the same unglamorous place: a full cryptographic inventory. Catalog every certificate, key, and protocol in the environment. It sounds like busywork until you try to migrate something you didn't know existed. Most organizations genuinely don't have a current map of where RSA or ECDH handshakes are doing the work of key exchange across their systems, and you cannot prioritize, budget, or schedule what you haven't found.

The Math That Tells You What to Fix First

Once you have the inventory, the next question is triage: what gets migrated first? This is where Mosca's theorem earns its keep. It's a simple inequality — if the years your data needs to stay confidential, plus the years it will take you to migrate the system protecting it, add up to more than the years before a quantum computer can break today's encryption, you're already out of runway on that system. Run that math against your longest-lived data first: financial records, government contracts, anything with a shelf life measured in decades.

From there the roadmap is six steps: inventory, then classify and prioritize by sensitivity and exposure, then pick a migration strategy (usually hybrid — post-quantum algorithms and physical-layer protection running side by side on the highest-risk links), then prepare your PKI for signatures that are meaningfully larger than what RSA produces, then test and roll out in phases with rollback plans, then build in crypto-agility so the next algorithm swap doesn't mean starting over. NIST's post-quantum program keeps expanding past ML-KEM, ML-DSA, and SLH-DSA, so that last step isn't optional — the standards are still moving.

Curious what makes recorded traffic a different problem than a broken key exchange? The Complete Guide to Post-Quantum Data-in-Transit Protection walks through why PQC alone doesn't finish the job.

Where the Roadmap Runs Out of Road

Here's the part that took me longest to internalize: none of this protects data that's already been copied off the wire. An adversary tapping a fiber link today doesn't need to break anything in real time — they record the encrypted payload and the RSA or ECDH handshake, and they wait. Once a quantum computer can break that stored handshake, they recover the session key and decrypt everything, regardless of how good your migration eventually gets. This is harvest-now-decrypt-later, and it's not hypothetical — physical tapping of trunk lines and submarine cables is a documented, ongoing risk.

Worth noting: Grover's algorithm only halves AES-256's effective strength, which is still well above the 128-bit threshold NIST and NSA require, so nobody's asking you to replace your symmetric cipher. The real exposure is the asymmetric key exchange, and it's worth staying honest about scope here — a recent Anthropic research result had Claude Mythos Preview cut the effective key strength of HAWK-256 (a candidate, not a deployed signature algorithm) in half in about 60 hours, and separately sped up an attack on a deliberately weakened, 7-of-10-round version of AES-128. Neither breaks anything running in production today, but it's a live reminder that whatever gets recorded now eventually meets better tools later.

Do you know Harvest Now, Decrypt Later: The Quiet Threat to Encrypted Data? It walks through exactly how that recording risk plays out on a real link.

Three Ways People Are Actually Closing the Gap

Most of the attention in this space goes to software-side PQC orchestration — companies like SandboxAQ and QuSecure help enterprises discover crypto assets and manage the algorithm migration itself, which is genuinely useful for the inventory-and-rollout steps. What neither of them touches is the recording problem: their protection lives in the math, so the encrypted signal is still a coherent, capturable artifact on the fiber the whole time. CyberRidge's Carmel platform takes a different angle — it operates at the physical, optical layer, spreading the signal and encoding it with a continuously changing key so a tapped link yields nothing usable to store in the first place. It's not a replacement for PQC migration or for orchestration tools; it's a parallel track for the highest-exposure links while the rest of the roadmap is still underway.

What I'd Actually Tell a Team Starting This

Do the inventory first regardless of deadline pressure — everything downstream depends on it. Pace against Executive Order 14412, which sets December 2030 for PQC key establishment and December 2031 for digital signatures across federal high-value systems (and cascades to contractors on the same 2030 date) — that's a tighter and more current benchmark than NIST's 2035 backstop. And for the links carrying your longest-lived, highest-exposure data, don't wait for the full migration to finish before doing something about what's being recorded right now.

FAQ

Q: What's the first real step in a quantum readiness roadmap?

A: A cryptographic inventory — cataloging every certificate, key, and protocol in use. Prioritization and migration strategy both depend on this baseline.

Q: Does migrating to post-quantum algorithms protect data that's already been intercepted?

A: No. PQC protects key exchanges established after the upgrade. It does nothing for traffic already recorded, since the encrypted payload stays a capturable signal on the wire regardless of which algorithm protects the keys.

Q: What is Mosca's theorem, in plain terms?

A: It's the rule security teams use to rank migration urgency: if the years your data must stay confidential plus the years it takes to migrate the system protecting it exceed the years until quantum computers can break today's encryption, that system is already past its safe window.

Q: How is CyberRidge's Carmel different from PQC orchestration tools like SandboxAQ or QuSecure?

A: Orchestration tools help manage the algorithm migration itself — discovery, inventory, rollout. Carmel operates at the physical layer to make the transmitted signal physically unrecordable, closing the harvest-now-decrypt-later gap that migration alone leaves open. The two are complementary, not competing categories.

Q: Does Carmel replace the need to migrate to post-quantum algorithms?

A: No. It runs alongside a standards-based PQC migration, protecting the physical signal while the broader migration to ML-KEM, ML-DSA, and related standards proceeds.

Q: How long does deploying Carmel typically take compared to a full PQC rollout?

A: CyberRidge reports Carmel deploys in weeks as a drop-in line-card replacement. A full enterprise PQC migration across certificates and PKI typically runs months to years, which is why physical-layer protection is often deployed first on the highest-exposure links.