Post-Quantum Cryptography: Separating the Real Deadline from the Marketing Deadline

Post-Quantum Cryptography: Separating the Real Deadline from the Marketing Deadline

I read Cisco's "Post-Quantum Cryptography (PQC) For Dummies" e-book [13] expecting a straightforward technical primer. It's a decent one, as far as vendor-sponsored primers go. But re-reading it with a more adversarial eye — and cross-checking its claims against independent sources — exposed a gap that matters more than the book itself. The book conflates "when should you be ready" with "when will the threat materialize." [13] Those are two very different numbers with very different levels of certainty.

This is a rewrite of an earlier, more uncritical take I published on the same topic. Same subject, different lens: less "here's what convinced me," more "here's what I'd push back on if a vendor pitched me this in a meeting."

Claim 1: "Harvest Now, Decrypt Later" — real mechanism, oversold urgency

The mechanics are not in dispute. NIST's own cryptography staff confirm the risk is real: organizations need to begin preparing for PQC migration because encrypted data may already face harvest-now-decrypt-later exposure [14]. That's a legitimate technical fact, not marketing spin.

What's missing from most vendor narratives, including this one, is the cost-benefit calculus underneath it. Practitioner discussion in security communities shows a split reaction. Teams handling long-lived sensitive data — state secrets, IP with decades of shelf life — take HNDL seriously and are building crypto-asset inventories. Teams without that kind of data explicitly say they are not prioritizing it, because in their own words they do not hold data worth the effort of this kind of attack [15]. HNDL is a genuine threat model for a specific class of data, not a universal five-alarm fire for every organization. A book built to sell switches understandably skips that nuance.

Claim 2: The compliance deadlines are firm — the underlying threat timeline is not

Cisco's chapter 6 lists hard dates: 2027 for several countries' first milestones, full transitions running 2030–2035. Those dates are real; they come from published government mandates [13]. What the book does not say clearly is that nobody knows when a cryptographically relevant quantum computer (CRQC) will actually exist. Independent estimates for CRQC arrival span from an optimistic 2027–2030 to a conservative 2035–2040 or beyond [3]. A separate estimate places significant probability specifically in the 2030–2035 window, with no consensus tighter than that [4].

That's a decade-plus of uncertainty on the one variable that actually determines urgency. It changes how you should read the regulatory deadlines: they are not "the quantum threat arrives in 2027." They are "regulators want you ready before an uncertain event, with a wide margin of safety." That's a defensible policy choice, but it's a risk-management deadline, not a scientific prediction — and vendor material tends to blur that distinction to manufacture urgency.

There's a useful sanity check on this from the quantum hardware side itself. IBM's own public roadmap — the company actually building the machines, with no PQC product to sell — targets a 200-logical-qubit system ("Starling") for 2029, scaling to a 2,000-logical-qubit system ("Blue Jay") by 2033 [18]. The Gidney–Ekerå factoring estimate that vendor slides love to cite (breaking RSA-2048 in 8 hours) calls for roughly 20 million noisy physical qubits [16] — a different unit than IBM's logical-qubit count, and easy to conflate if a chart puts both numbers side by side without saying so. Various estimates for how many logical qubits Shor's algorithm actually needs cluster in the 2,000–4,000 range. If that holds, IBM's own hardware trajectory doesn't cross that threshold until around 2033 at the earliest — which lines up with the conservative end of the independent CRQC estimates above, not the optimistic end, and comes from the people with the least incentive to hype the timeline.

Claim 2b: The Thailand angle — regulators and industry are already moving, independent of any single vendor's book

Thailand isn't waiting for global consensus on CRQC timing either. Thailand's National Cyber Security Agency (NCSA, สกมช.) has publicly set "Quantum-Ready 2030" as a national policy pillar [19][23], and reporting from March 2026 shows the NCSA and the Bank of Thailand jointly urging the banking sector to prepare for what they're calling the "Y2Q" transition, framing it explicitly as a Y2K-style operational deadline rather than a distant research problem [21]. The Thai Bankers' Association followed up with a dedicated PQC migration briefing for the sector in July 2026 [22].

That's independent corroboration, from a regulator and an industry association with no vendor affiliation, that the "start now, migrate in phases" posture isn't just Cisco's sales pitch — it's the working assumption of the institutions actually setting compliance expectations in this market. Worth noting for any technical evaluation done for a Thai enterprise audience: the regulatory clock here runs on the same 2030 marker used elsewhere globally, but it's arriving via sector-specific guidance (banking first) rather than a single blanket mandate — plan the crypto-asset inventory step accordingly, starting with whichever regulator or industry body actually governs your sector.

Claim 3: The "just enable ML-KEM" framing skips real engineering cost

The book presents Cisco's PQC integration — ML-KEM in IKEv2/IPsec, TLS 1.3, SSH, EAP-TLS/MACsec — as essentially a configuration toggle [13]. NIST finalized the underlying standard, FIPS 203 (ML-KEM), in August 2024 [1][2], so the cryptography itself is mature. The deployment cost is not zero, though:

• ML-KEM-768 measured overhead is roughly 150 microseconds per handshake versus classical X25519 — small per connection, but it compounds at scale on high-connection-rate systems [11].
• Hybrid KEM configurations, which most organizations will actually run during the transition period for backward compatibility with legacy peers, incur higher handshake latency and bandwidth overhead than either pure classical or pure post-quantum KEMs alone [12].
• On platforms without hardware acceleration for lattice-based math, PQC operations can add measurable CPU overhead on management-plane operations at scale, not just the data plane [8].

None of this makes PQC migration a bad idea. It does mean "enable it and move on" is not an accurate description of the work. Capacity planning and hybrid-mode performance testing are real line items, and a fair technical evaluation should say so.

Claim 4: "Cisco is first" needs a market context the book doesn't provide

Cisco's own release notes for IOS-XE 26.1.1 describe the C9000 Smart Switch PQC implementation as an "industry-first full-stack implementation of post-quantum cryptography" [7]. That is Cisco's characterization of its own product, not an independent benchmark. Competitors are running parallel efforts on their own timelines: Palo Alto Networks publishes its own PQC feature support and migration documentation [9], and Fortinet has published its own PQC preparation roadmap [10]. Both are at a comparably early stage to Cisco's rollout. A vendor's "first" claim about its own hardware should be read as marketing copy until an independent third party validates the comparison, not taken at face value.

Claim 5: The one thing independent cryptographers and the vendor material actually agree on

Bruce Schneier — no Cisco affiliation, no product to sell — makes a point that survives the marketing filter intact. Today's panic about quantum computers "breaking everything" mostly comes from people who don't understand cryptography [5]. But the actionable takeaway underneath that pushback is still real: build cryptoagility, because whatever NIST standardizes now will likely get broken or superseded sooner than anyone wants, so systems need to be able to swap algorithms without a redesign [6]. That is the one claim in the Cisco book I would keep without reservation, not because Cisco said it, but because it holds up independently of who's saying it.

Where that leaves a technical evaluation

If you're doing vendor-neutral architecture planning, here's the version of this story I'd actually act on:

1. Inventory crypto assets by data sensitivity and shelf-life. This holds regardless of CRQC timeline uncertainty [3][4], because the migration lead time itself — multi-year for anything embedded in hardware or firmware — is the real constraint, not the quantum threat's arrival date.
2. Treat vendor "we're first" claims as unverified until independently benchmarked. Cisco [7], Palo Alto [9], and Fortinet [10] are all racing toward the same NIST-defined finish line; none of them gets to grade its own homework.
3. Budget for hybrid-mode performance testing, not just a feature-flag flip. The overhead numbers above are individually small but compound at connection scale [11][12], and hybrid mode — which most migrations will run for years — is measurably heavier than either pure mode.
4. Use government deadlines as planning anchors, not risk predictions. They tell you when to be ready, not when the threat arrives [13][14]. Conflating the two is exactly the move that turns a legitimate multi-year infrastructure project into unnecessary panic-buying.

Analysis, framing, and critique are the author's own. Full source list below.

Sources

[1] https://csrc.nist.gov/pubs/fips/203/final — NIST FIPS 203 (ML-KEM) Final
[2] https://quantumsecuritydefence.com/insights/nist-fips-standards/ — NIST FIPS 203/204/205 finalized August 2024
[3] https://qramm.org/learn/quantum-threat-timeline.html — CRQC timeline: expert estimates 2030–2040
[4] https://www.encryptionconsulting.com/education-center/crqc-timelines-quantum-threat-landscape/ — CRQC Timelines: 2030–2035 range
[5] https://www.schneier.com/news/archives/2025/01/have-a-good-bullshit-detector-advises-computer-security-expert-bruce-schneier.html — Schneier: panic over quantum crypto is overblown
[6] https://www.schneier.com/blog/archives/2023/08/you-cant-rush-post-quantum-computing-standards.html — Schneier: cryptoagility is the real requirement
[7] https://community.cisco.com/t5/networking-knowledge-base/ios-xe-26-1-1-what-s-new-for-cisco-switching/ta-p/5545263 — Cisco IOS XE 26.1.1 PQC on C9000 (industry-first claim)
[8] https://www.pinglabz.com/post-quantum-crypto-in-cisco-campus-networks-what-operators-need-to-know/ — PingLabz: PQC compute overhead on Cisco Campus
[9] https://docs.paloaltonetworks.com/network-security/quantum-security/administration/quantum-security-concepts/support-for-quantum-features — Palo Alto Networks PQC support docs
[10] https://www.fortinet.com/resources/articles/post-quantum-cryptography-preparation — Fortinet PQC preparation roadmap
[11] https://dev.to/abraham_arellanotavara_7/choosing-between-ml-kem-and-ml-dsa-for-your-post-quantum-migration-part-2-4dip — ML-KEM-768 overhead: ~150 microseconds/handshake
[12] https://www.sciencedirect.com/science/article/pii/S1389128625009223 — Hybrid KEMs incur highest handshake latency/bandwidth overhead
[13] https://www.cisco.com/c/dam/en_us/solutions/networking/pqc/post-quantum-cryptography-for-dummies.pdf — Cisco, "Post-Quantum Cryptography (PQC) For Dummies, Cisco Special Edition," Lawrence Miller, John Wiley & Sons, Inc., © 2026 (original source)
[14] https://thequantuminsider.com/2026/07/30/nist-andrew-regenscheid-post-quantum-cryptography-transition/ — NIST's Andrew Regenscheid on HNDL risk
[15] https://www.reddit.com/r/cybersecurity/comments/1sfushf/quantum_cryptography_and_the_harvest_now_decrypt/ — r/cybersecurity: HNDL cost-benefit reactions
[16] https://arxiv.org/abs/1905.09749 — Gidney & Ekerå (2019), "How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits"
[18] https://www.ibm.com/roadmaps/quantum/ — IBM Quantum Roadmap: Starling (2029, 200 logical qubits), Blue Jay (2033, 2,000 logical qubits)
[19] https://cybreplus.ncsa.or.th/news/detail/19042569 — Thailand NCSA (สกมช.): "Quantum-Ready 2030" policy
[21] https://thailandedition.com/i/y2k-y2q-ncsa-urges-banks-prep-quantum-crypto-00a569bb28d0c723646eb753 — Thailand NCSA + Bank of Thailand urge banking sector to prepare for the "Y2Q" era
[22] https://www.exequantum.com/insights/preparing-for-post-quantum-cryptography-migration-in-banking-four-recommendations-from-our-thai-bankers-association-presentation — Thai Bankers' Association PQC migration briefing, July 2026
[23] https://siamrath.co.th/economy/technology/155933 — NCSA 5-year vision reiterating "Quantum-Ready 2030"