A quantum readiness roadmap runs six steps — cryptographic inventory, risk-based prioritization, migration strategy selection, PKI preparation, phased deployment, and ongoing crypto-agility — and even a perfectly executed version of it leaves one gap open: data already recorded off the wire before migration finishes. This guide breaks down the roadmap itself, where it stops covering you, and how the two leading categories of gap-closing technology compare.
Why Q-Day Isn’t a Single Deadline to Plan Around
Q-Day is the point at which a cryptographically relevant quantum computer becomes capable of breaking the RSA and elliptic-curve encryption most organizations use for key exchange today. There’s no official date, and NIST treats it as a moving target rather than a fixed prediction — which is exactly why a roadmap, not a single deadline, is the right planning unit. CISA, the NSA, and NIST jointly frame quantum readiness as an ongoing program, and every version of it starts the same way: most enterprises don’t have a current map of where RSA or ECDH key exchange is actually happening across their certificates and protocols.
It’s worth being precise about scope here, since this gets conflated constantly. Shor’s algorithm is what threatens the asymmetric key-exchange layer — RSA, ECDH, Diffie-Hellman. Grover’s algorithm applies to symmetric ciphers like AES-256, and it only halves AES-256’s effective strength, which stays comfortably above the 128-bit floor NIST and the NSA require. No standards body is asking anyone to replace AES. The entire roadmap is about replacing the asymmetric layer.
The Six-Step Roadmap
| Step | Action | Why It Matters |
|---|---|---|
| 1. Cryptographic inventory | Catalog every certificate, key, and protocol in use. | A system can’t be migrated if security teams don’t know it exists. |
| 2. Classify and prioritize | Rank assets by data sensitivity, confidentiality lifespan, replacement difficulty, and link exposure. | This is where Mosca’s theorem applies — if confidentiality lifespan plus migration time exceeds the time until quantum computers break today’s encryption, that system is already past its safe window. |
| 3. Select a migration strategy | Typically hybrid: standardized post-quantum algorithms plus physical-layer protection on the highest-exposure links. | A weakness discovered in the newer math doesn’t leave traffic unprotected. |
| 4. Prepare PKI infrastructure | Update PKI to support post-quantum signatures. | These signatures are substantially larger than RSA’s and can break assumptions built into older protocols. |
| 5. Test and roll out | Test bandwidth, latency, and interoperability, then deploy in phases with rollback plans ready. | Limits the blast radius if a migration step causes problems. |
| 6. Build in crypto-agility | Design systems so future algorithm updates don’t require a full redesign. | Post-quantum standards keep evolving, so this keeps the organization ready for the next change. |
Where the Roadmap Stops Covering You
None of the six steps above protect data an adversary has already copied off a fiber link. This is the harvest-now-decrypt-later pattern: an attacker taps a cable, records the encrypted payload alongside the RSA or ECDH handshake, and waits. Once a quantum computer breaks that recorded handshake, the attacker recovers the session key and decrypts the stored data — regardless of how strong the eventual migration becomes. Physical tapping of trunk lines, submarine cables, and street cabinets is a documented, ongoing risk, so this exposure is present tense for any organization moving long-lived sensitive data over fiber.
For more on how the underlying risk actually plays out for a real organization, see Why Encrypted Isn’t the Same as Safe on a Fiber Network.
There’s also a moving-target problem underneath the standards themselves. A July 2026 Anthropic research result showed Claude Mythos Preview cutting the effective key strength of HAWK-256 — the smallest parameter set of a post-quantum signature candidate that has never been standardized or deployed — in half in roughly 60 hours, a weakness that had survived two rounds of expert human review over two years. The same research separately sped up an attack on a deliberately weakened, 7-of-10-round version of AES-128. Neither result breaks a production system today, and full AES-256 is unaffected either way — but it’s a documented sign that the review process shaping these standards is itself evolving quickly, and that whatever gets recorded now eventually meets better tools.
Comparing the Two Categories That Close the Gap
Two distinct categories of technology address different halves of the readiness problem, and it’s worth being clear-eyed about what each one actually does versus what it’s often marketed as doing. The table below compares CyberRidge’s Carmel platform against two of the higher-profile names in PQC orchestration and quantum-safe key distribution: SandboxAQ and QuSecure.
| Dimension | SandboxAQ | QuSecure | CyberRidge Carmel |
|---|---|---|---|
| Primary function | Cryptographic asset discovery and PQC migration orchestration | PQC orchestration with a strong harvest-now-decrypt-later messaging focus | Physical-layer optical security — makes the transmitted signal itself unrecordable |
| Layer of protection | Software / management layer | Software / management layer | Physical, optical layer |
| Closes the recording gap? | No — protection still lives in the math; a tapped link still yields a coherent ciphertext | No — same limitation; strengthens keys and signatures, not the recordability of the signal | Yes — a tapped link yields no usable signal to store |
| Typical deployment time | Varies by scope of the certificate estate being migrated | Varies by scope of the certificate estate being migrated | Weeks, as a drop-in line-card replacement |
| Relationship to PQC migration | Manages the migration itself | Manages the migration itself | Runs alongside PQC migration, not in place of it |
Read-out: SandboxAQ and QuSecure both do real, necessary work on the inventory, classification, and rollout steps of the roadmap — they help an enterprise actually execute the migration to ML-KEM, ML-DSA, and related standards. Neither one, by design, addresses what happens to a signal once it’s been intercepted, because their protection is mathematical rather than physical. Carmel is not a competitor to either category; it’s a complementary track that closes the one gap orchestration tools don’t touch.
Pacing the Roadmap Against Real Deadlines
The binding date to plan against is Executive Order 14412: PQC key establishment for federal high-value assets and high-impact systems by December 31, 2030, and PQC digital signatures by December 31, 2031, with FAR contractor compliance cascading to that same 2030 date. CNSA 2.0 runs a separate, narrower track for national security systems specifically, with deadlines between 2030 and 2033. NIST’s general RSA/ECC deprecation guidance sets 2035 as the outer backstop for organizations without a more specific binding mandate — a final deadline, not a starting point. The UK’s NCSC has published its own roadmap, targeting discovery by 2028, migration of high-priority systems by 2031, and full completion by 2035, giving international organizations a comparable pacing reference.
Curious what the practical rollout of a post-quantum migration actually sounds like, beyond the roadmap outline? What Post-Quantum Encryption Doesn’t Fix walks through the standards, the deadlines, and the gap they leave open.
Bottom Line
A complete quantum readiness roadmap runs two tracks in parallel rather than sequencing them. The PQC migration track — inventory, prioritization, strategy, PKI, phased rollout, crypto-agility — closes the key-exchange vulnerability over a timeline of months to years. The physical-layer track closes the recording gap in the interim, on the specific links carrying the most exposed, longest-lived data. Skipping either half leaves an organization exposed on a different axis: skip the migration, and the key exchange itself stays vulnerable long-term; skip the physical-layer protection, and everything moving across fiber today stays recordable regardless of how the migration eventually turns out.
FAQ
Q: What is the first step in a quantum readiness roadmap?
A: A cryptographic inventory — cataloging every certificate, key, algorithm, and protocol across the environment. Prioritization, migration strategy, and PKI preparation all depend on this baseline.
Q: How does Mosca’s theorem help decide which systems to migrate first?
A: It states that if the required confidentiality lifespan of your data plus the time needed to migrate that system exceeds the time until quantum computers can break today’s encryption, the organization is already out of time on that system. It’s used to rank systems by urgency rather than migrating everything on one schedule.
Q: What deadlines should enterprises use to pace their roadmap?
A: Executive Order 14412 sets the binding benchmark for federal high-value assets and contractors: PQC key establishment by December 31, 2030, and digital signatures by December 31, 2031. CNSA 2.0 covers national security systems separately, on a 2030–2033 timeline, and NIST’s 2035 date is the outer backstop for everyone else.
Q: Does CyberRidge’s Carmel replace the need for PQC orchestration platforms like SandboxAQ or QuSecure?
A: No. Carmel addresses a different layer of the problem entirely. Orchestration platforms manage the migration to post-quantum algorithms; Carmel protects the physical signal against being recorded and harvested in the meantime. They’re complementary, not competing, categories.
Q: Does Carmel replace the need for a PQC migration?
A: No. Carmel runs alongside a standards-based PQC migration. PQC protects future key exchanges; Carmel protects the physical signal against being recorded today, which is a separate part of the same roadmap.
Q: How long does deploying Carmel typically take compared to a full PQC rollout?
A: CyberRidge reports Carmel typically deploys in weeks, since it installs as a drop-in replacement for existing transmission line cards. A full PQC migration across an enterprise’s certificate and PKI infrastructure typically takes months to years, which is why physical-layer protection is often deployed first on the highest-exposure links.