Cisco Outlines Two-Pillar Post-Quantum Strategy

Cisco published a detailed overview of its post-quantum cryptography (PQC) strategy on February 5, outlining how the company plans to protect both network traffic and product integrity before cryptographically relevant quantum computers (CRQCs) arrive. The company's Security and Trust Organization blog post frames the quantum threat as more than a confidentiality problem — it's a systemic trust risk that could undermine digital signatures, device attestation, and secure boot processes across entire networks.

The Clock Is Running on "Harvest Now, Decrypt Later"

The most immediate concern isn't a future quantum computer cracking encryption in real time. It's adversaries collecting encrypted data today with the expectation of decrypting it once CRQCs become available. This "harvest now, decrypt later" (HNDL) strategy means sensitive communications intercepted in 2026 could be exposed in 2030 or 2035, depending on how quickly quantum hardware matures.

Cisco's Christian Chisholm, Senior Director in the company's Strategy and Planning division, points to recent milestones that have shortened the estimated timeline. Oxford's distributed quantum algorithm research and Google's Willow chip both suggest CRQCs could arrive before 2035 — earlier than many organizations assumed when NIST released its first three post-quantum standards in August 2024.

Those NIST standards — FIPS 203 (ML-KEM for key encapsulation), FIPS 204 (ML-DSA for digital signatures), and FIPS 205 (SLH-DSA for hash-based signatures) — provide the algorithmic foundation that vendors like Cisco are building on. Federal agencies already face mandates under NSM-10 to begin PQC migration, with most quantum risk expected to be mitigated by 2035.

Two Pillars: Secure Communications and Secure Products

Cisco's approach splits into two parallel tracks.

Pillar 1: Secure Communications addresses HNDL risk by adding quantum-resistant encryption to data-in-transit protections. The company's 8000 Series Secure Routers already feature dedicated hardware for this purpose — the Quantum-Flow Processor ASIC in higher-end models and a secure networking processor in branch routers, both designed to handle post-quantum algorithms without degrading throughput.

These routers will support hybrid encryption under RFC 9370, combining classical and quantum-safe cryptography within the same session. That hybrid approach matters because it preserves backward compatibility while adding quantum resistance across IKEv2 IPsec, SD-WAN, FlexVPN, DMVPN, MACsec, and SSH.

Pillar 2: Secure Products goes beyond encryption. Cisco is embedding quantum-resistant foundations into the trust mechanisms that underpin its platforms — firmware signing, identity certificates, secure boot chains, software update validation, and device attestation. This is the piece that doesn't get enough attention. If a quantum attacker can forge digital signatures, they don't need to decrypt your traffic. They can sign malicious firmware updates, impersonate trusted devices, or invalidate the security controls an organization depends on for operational decisions.

Why the Signature Problem Is Harder Than Encryption

Upgrading key exchange is the lower-hanging fruit. You generate new keys per session, and adding ML-KEM to existing protocols is a tractable engineering problem. Digital signatures are different. Certificates embedded in hardware, firmware signed years ago, long-lived root certificates — these all rely on algorithms that quantum computers could break.

Replacing those signatures means touching every layer of the trust chain: root CAs, intermediate certificates, code signing infrastructure, and device identity. Cisco's decision to treat this as a distinct "pillar" rather than a footnote suggests the company recognizes this will be the slower, harder migration.

The first PQC certificates aren't expected to be widely available until later in 2026, and adoption will lag availability by months or years. Organizations that mapped their AI security functions into distinct domains should consider adding PQC readiness as a dimension of their trust architecture.

What Organizations Should Do Now

Cisco isn't the only vendor pushing PQC readiness, but the specificity of its hardware investment stands out. For security teams evaluating their quantum risk, the priorities are:

1. Inventory your cryptographic dependencies. Know which algorithms protect your most sensitive data and longest-lived secrets. Anything with a confidentiality requirement extending past 2035 is already at HNDL risk.

2. Prioritize transport encryption upgrades. Hybrid key exchange (combining classical and post-quantum algorithms) is the fastest path to reducing HNDL exposure. Cisco's hybrid RFC 9370 support isn't unique — OpenSSH and several TLS libraries already offer experimental PQC key exchange.

3. Plan for the signature migration separately. This affects your PKI, secure boot processes, code signing, and device identity. It won't happen overnight, and rushing it creates its own risks. Building toward what the NetSecOpen validation of Cisco's 8375 router demonstrated — that PQC-capable hardware can be independently tested for performance — is a practical starting point.

4. Watch NIST's HQC timeline. The draft standard for the HQC algorithm (a code-based alternative to lattice-based ML-KEM) is expected in early 2026, with finalization in 2027. This additional algorithm gives organizations a second option if future research weakens lattice assumptions.

The Bigger Picture

Quantum computing hasn't broken anything yet. But the HNDL threat means the damage may already be accumulating in ways we won't see for a decade. Nation-state actors with the resources to store petabytes of encrypted traffic are the likeliest adversaries — the same groups behind campaigns targeting critical infrastructure and government networks.

Cisco's strategy acknowledges that the transition to post-quantum cryptography won't happen in a single product cycle. The two-pillar structure — treating communications and product integrity as separate workstreams with different timelines — is a realistic framing. The question for most organizations isn't whether to start migrating, but whether they can afford to wait while adversaries keep harvesting.