Post-Quantum Cryptography Isn't a "Someday" Problem — Here's What Changed My Mind

Post-Quantum Cryptography Isn't a "Someday" Problem — Here's What Changed My Mind

I spent 14+ years doing network engineering — CCIE, mostly enterprise infrastructure and lately presale technical architecture for large-scale IT deals. If you'd asked me a year ago whether "quantum computing breaking encryption" was something I needed to worry about this decade, I'd have shrugged. Feels like sci-fi. Feels far away.

Then I sat down and actually read Cisco's "Post-Quantum Cryptography (PQC) For Dummies" e-book (Cisco Special Edition, published by Wiley, July 2026), and one concept flipped a switch for me: Harvest Now, Decrypt Later.

The thing that actually worries me

Here's the uncomfortable part. You don't need a working quantum computer today for your data to be at risk today. An adversary can capture your encrypted traffic right now — VPN sessions, TLS handshakes, whatever crosses the wire — and just... sit on it. Store it indefinitely. Then, whenever a cryptographically relevant quantum computer (CRQC) becomes available — could be 5 years, could be 10 — they run Shor's algorithm against the harvested key exchange, recover the session keys, and decrypt years of old traffic retroactively.

For most day-to-day data, who cares — it's stale by then. But think about what isn't stale in 10 years: state secrets, long-lived IP, M&A negotiations, health records, anything with a multi-decade confidentiality requirement. That data is being harvested right now, sitting in someone's archive, waiting.

That reframed the whole problem for me. This isn't a "wait until quantum computers exist" problem. It's a "the clock already started" problem.

What's actually breaking, and what isn't

The book does a good job separating the two halves of modern crypto:

• Symmetric encryption (AES-GCM) — mostly fine. Quantum computers weaken it a bit (need bigger keys), but they don't break it outright.
• Asymmetric encryption (RSA, Diffie-Hellman, ECC) — this is the one that's structurally doomed. It's the backbone of key exchange in IPsec, TLS 1.3, MACsec, SSH — basically every transport protocol you rely on assumes deriving a private key from a public key is computationally infeasible. Shor's algorithm on a CRQC removes that assumption entirely.

And that's the real gut-punch: it doesn't matter how strong your data encryption is if the key exchange that set it up can be broken. Cisco's line in the book stuck with me — it's like building a titanium vault and mailing the key in an unsealed envelope.

The NIST toolkit that's supposed to fix this

NIST already standardized the replacements:

• ML-KEM (FIPS-203) — replaces ECDH for key exchange
• ML-DSA (FIPS-204) — replaces RSA/ECDSA for digital signatures
• LMS — stateful hash-based signatures, mainly for firmware/secure-boot signing
• Plus beefed-up AES-GCM-256 and SHA-512 for the symmetric/hash side

Cisco's approach (per the book) is to weave ML-KEM into IKEv2/IPsec, TLS 1.3, SSH, and EAP-TLS/MACsec, and to anchor secure boot in a Trust Anchor module using quantum-safe signatures — with C9000 Smart Switches and 8000 Series Secure Routers as the first platforms.

Why I'm writing this as a presale/architect, not just a curious reader

The part that matters for my actual job is the compliance timeline chapter. Just a sample of what's already locked in:

• US: CNSA 2.0 requires quantum-resistant algorithms for new national security system acquisitions by 2027, full transition by 2030-2035
• EU: transition planning starts by end of 2026
• UK: migration plans due end of 2027
• Singapore, Japan, India, Taiwan: all have 2027 as a "start pilots / start migration" checkpoint

2027 keeps showing up. That's not far-future planning — that's next procurement cycle for a lot of organizations. If you're doing infrastructure planning, security roadmaps, or vendor evaluations for clients right now, "we'll think about PQC later" is already the wrong answer for anything with a multi-year lifecycle (which, let's be honest, is most enterprise network gear).

My actual takeaway

I'm not saying panic. I'm saying: cryptoagility — the ability to swap crypto algorithms without ripping out your infrastructure — should be a line item in every RFP and architecture review from here forward, the same way "IPv6 readiness" was a checkbox a decade ago. The book's 3-step framework (Learn → Identify your crypto assets by risk tier → Plan a phased migration) is a genuinely useful lens even outside the Cisco-specific pitch.

If you're in network/security architecture and haven't looked at this yet, it's a 30-minute read that's worth your time. Full e-book link again: cisco.com/c/dam/en_us/solutions/networking/pqc/post-quantum-cryptography-for-dummies.pdf

---

Sources: Lawrence Miller, "Post-Quantum Cryptography (PQC) For Dummies, Cisco Special Edition," John Wiley & Sons, Inc., © 2026 — full PDF via Cisco. All facts, figures, and quotes attributed to this source; commentary and opinions are my own.