Post-Quantum Crypto in Cisco Campus Networks: What Operators Need to Know

Campus networks are getting pulled into the post-quantum conversation faster than most operators expected. NIST finalized three post-quantum cryptography (PQC) standards in August 2024, and Cisco has started making "quantum-ready" claims about the Catalyst 9000 lineup. Before you do anything with that information, it's worth separating what those claims actually mean in practice from the marketing framing, and building a realistic picture of where your campus network is exposed, what the timeline actually looks like, and what needs attention now versus what you can safely monitor for a few more years.

Why PQC Is Entering the Campus Conversation Now

Three things converged to make this a real planning concern rather than a theoretical one.

The NIST standards are finalized. In August 2024, NIST published the first three post-quantum cryptography standards: FIPS 203 (ML-KEM, the key encapsulation mechanism derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, the signature algorithm from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, from SPHINCS+). A fourth algorithm, FN-DSA (from FALCON), is pending finalization as FIPS 206. A backup key encapsulation algorithm called HQC was selected in March 2025, with a draft standard expected in early 2026. The absence of finalized standards was the primary reason most organizations weren't moving on PQC. That reason is gone.

The harvest-now-decrypt-later (HNDL) threat is already active. Nation-state actors are capturing encrypted traffic today on the assumption that quantum computers will eventually be able to decrypt it. You don't need to believe Q-day is imminent to take this seriously. If data you're encrypting right now should still be confidential in ten to fifteen years, HNDL is a concrete risk. Expert surveys conducted by the Global Risk Institute suggest over 50% probability of cryptographically relevant quantum computers emerging within fifteen years. Research published in June 2025 by Craig Gidney reduced the estimated qubit requirement for breaking RSA-2048 from approximately 20 million to under one million superconducting qubits, which effectively pulled the threat timeline closer. The exact date remains genuinely uncertain; the direction of progress does not.

Long infrastructure lifecycles make campus networks unusually exposed. This is the point most security briefings skip over. A campus switch bought today might stay in production for ten to fifteen years. A server bought today will likely be refreshed within five. The practical implication: traffic encrypted over campus infrastructure today could still be traversing that same infrastructure when a capable quantum computer exists, if current research projections hold. Server infrastructure adapts quickly through refresh cycles. Campus switch infrastructure often doesn't, unless you're intentionally planning for it.

What Post-Quantum Actually Means for Network Crypto

Before you evaluate any vendor PQC claim, you need a clear picture of where cryptography actually lives in a campus network. It isn't one thing. There are at least five distinct cryptographic planes in a typical enterprise campus, each with a different exposure profile and a different migration path.

The most important thing this table illustrates: MACsec's symmetric encryption is already quantum-resistant at the 256-bit key size. Grover's algorithm (the quantum attack that applies to symmetric ciphers) effectively halves the key length, meaning AES-256 behaves like AES-128 against a quantum adversary. AES-128 against a quantum computer is still secure by any practical definition. If you're already running GCM-AES-256 on your MACsec links, the data plane is not your exposure.

Where the real exposure lives is in the asymmetric key exchange and certificate layers. RSA and ECDH (the algorithms used to negotiate session keys in IPsec, TLS, and SSH) are vulnerable to Shor's algorithm on a sufficiently capable quantum computer. Any session key negotiated using RSA or ECDH is retrospectively vulnerable: an adversary who captured that session today could decrypt it once quantum hardware arrives. This is the core of the HNDL threat, and it applies to every layer in the table above that uses an asymmetric key exchange.

What Cisco Is Actually Claiming

Cisco announced that the Catalyst 9000 Smart Switches support "full-stack post-quantum cryptography" as of IOS-XE 26. This is a meaningful claim, but it covers multiple distinct things, and the level of maturity varies significantly by layer.

The honest read of this table: the most concrete and shipping PQC capability on campus Catalyst hardware is the secure boot chain, which protects supply chain integrity rather than data in transit. That is a genuinely useful capability (hardware supply chain attacks are real), but it isn't protecting the MACsec or TLS sessions your operators are thinking about when they hear "quantum-safe campus."

For MACsec, the "quantum-safe" claim today is largely about symmetric key size, not PQC key exchange. GCM-AES-256 with a properly random PSK is indeed adequate against quantum attacks on the data plane. But if your MACsec is using GCM-AES-128 (the default on many configurations), migrating to 256-bit keys is genuinely useful and unrelated to whether you buy new hardware. Dynamic PQC key agreement for MKA (the protocol that manages MACsec session keys) is described as in development, with timelines subject to change. Don't plan around features that aren't in a released configuration guide.

For IPsec PQC key exchange, Cisco's ML-KEM-1024 support is shipping on the Catalyst 8000 (their WAN aggregation/edge router platform) and ISR 4000/ASR 1000 series. The campus campus switch parity question (specifically which Catalyst 9300/9400/9500 IOS-XE version carries which PQC feature) requires verification against the actual security configuration guide for your target release, not a marketing brief.

Ask the right questions when evaluating vendor claims. "Do you support post-quantum cryptography?" will always get a yes. The useful questions are: which specific NIST algorithm (ML-KEM-768? ML-KEM-1024? ML-DSA-44?), in which IOS-XE version, on which hardware platforms, and is the key exchange quantum-resistant or just the bulk encryption cipher? A vendor who can't answer those questions specifically is selling positioning, not a feature.

Crypto Agility: The Thing That Matters Most

Before any specific algorithm claim, crypto agility is the most strategically important property to evaluate in any infrastructure you're procuring or renewing right now. Crypto agility means the ability to swap cryptographic algorithms through a software or configuration change, without replacing hardware.

The reason this matters: the PQC standards landscape is still evolving. NIST finalized three algorithms in August 2024 and is still standardizing a fourth and a backup KEM. Some of the selected algorithms may be weakened by future cryptanalysis (as happened with SIDH/SIKE, a PQC candidate that was broken in 2022 before it could be standardized). The algorithms that are strong today may not be the algorithms you're running in 2035. Infrastructure that can upgrade cryptographic primitives through IOS-XE software updates is in a fundamentally different position than infrastructure that requires a hardware swap to change cipher suites.

When evaluating Cisco hardware for your next refresh, the question to ask is: if NIST releases a new or revised PQC standard in 2028, can this hardware run it with a software update, or does it require new ASICs? Cisco's positioning of IOS-XE as a software-upgradeable platform is designed to answer yes, but verify the specific feature against your platform and release.

The Real Planning Horizon

NIST IR 8547 (the transition guidance document, published as an initial public draft in November 2024) calls for deprecating quantum-vulnerable algorithms (RSA, ECDH, ECDSA) by 2030, and removing them from NIST standards by 2035. Regulatory frameworks that reference NIST, including federal agency requirements and FIPS compliance, will follow this timeline with varying lead times.

Ten years sounds like plenty of time. For most enterprises, the active work is limited for now. But two things compress the timeline in practice.

Certificate lifetimes create compounding complexity. If you have a ten-year CA root certificate issued in 2022 (not uncommon in enterprise environments), it will still be signing RSA-based device certificates in 2032, two years after NIST's deprecation deadline. Migrating that CA after 2030 means touching every certificate it issued, across every device that trusts it. The cost of that migration is much lower if you plan it today than if you inherit it as an emergency in 2030.

Infrastructure procurement cycles extend past the compliance window. If you're buying campus switches now on a typical 7 to 10 year lifecycle, those switches will be in production in 2033 or 2035. Buying hardware today that is not evaluable for PQC agility means inheriting an unresolved compliance question during the enforcement window.

Regulated Industries vs. Everyone Else

The urgency is not uniform. Regulated industries have compliance timelines that are already creating real deadlines. Most enterprises have time to plan and monitor without immediate action on cryptographic infrastructure, as long as they're doing the foundational work.

The PKI audit appears in every row for a reason. It's the foundational work that every organization can do today without buying anything, and without which you can't make informed decisions about anything else. You can't plan a certificate migration if you don't know what certificates you have, who issued them, what algorithms they use, and when they expire.

Practical First Steps for Operators

Here's the actual order of operations for a campus operator who wants to move from "aware" to "doing something useful."

Step 1: Audit your PKI and certificates

Identify every certificate in use on network infrastructure: management plane (HTTPS, SSH host keys), 802.1X (RADIUS server certificates, EAP-TLS client certificates), and any internal CAs issuing device identity certificates. Note key sizes, expiration dates, issuing CAs, and algorithm types. Any certificate with a lifetime extending past 2030 that uses RSA or ECDSA is a candidate for migration planning.

! On Cisco IOS-XE, list all trustpoints and certificate details
C9300# show crypto pki certificates verbose

! Check SSH host key type and size
C9300# show crypto key mypubkey all

! Identify all trustpoints configured
C9300# show crypto pki trustpoints

If you're running an internal CA (whether Microsoft AD CS or a dedicated PKI), export the certificate inventory and look specifically for root and intermediate CA certificates with long lifetimes that use RSA-2048. These are the ones that will cause the most operational pain in 2028-2030 if you don't start migration planning now.

Step 2: Verify your MACsec key sizes

If you're running MACsec, check whether your MKA policies are using GCM-AES-128 or GCM-AES-256. GCM-AES-128 has adequate classical security but is theoretically weakened by Grover's algorithm to approximately 64 bits of quantum security. GCM-AES-256 is effectively quantum-resistant for the data plane. Migrating to 256-bit keys is a configuration change, not a hardware change, and you can do it today.

! Check active MACsec sessions and cipher suites in use
C9300# show macsec summary
C9300# show mka sessions detail

! Update MKA policy to require GCM-AES-256
C9300(config)# mka policy CAMPUS-PQC-READY
C9300(config-mka-policy)# macsec-cipher-suite gcm-aes-256
C9300(config-mka-policy)# confidentiality-offset 0

Note that GCM-AES-256 requires a Network Advantage license on Catalyst 9000 hardware. If you're currently on Network Essentials, verify licensing before pushing the change. Also, both ends of a MACsec link must agree on the cipher suite, so coordinate any change across all peers on a given segment.

Step 3: Evaluate IOS-XE version and hardware capability on your next refresh

Before your next campus switch procurement, add two questions to your evaluation criteria. First: which IOS-XE releases include verified PQC cipher suite support for management plane TLS and, when available, MACsec key exchange? Second: is the hardware capable of running those features without a significant performance impact? PQC algorithms (particularly ML-KEM and ML-DSA) are more compute-intensive than RSA and ECDH, and platforms without hardware acceleration for lattice-based operations may see CPU overhead on management plane operations at scale.

For the Catalyst 9000 series, Cisco's "full-stack PQC" claims are associated with IOS-XE 26 on the new Smart Switch hardware announced at Cisco Live Amsterdam 2026. Verify specific feature availability by checking the Security Configuration Guide for your target release and platform before building it into a deployment plan.

Step 4: Add crypto agility to your configuration template standards

Update your switch provisioning templates to default to AES-GCM-256 for MACsec, 4096-bit RSA or P-384 ECDSA for any certificates you generate, and SHA-384 or SHA-512 for hashing. These choices don't require PQC hardware, but they extend the safety margin of classical algorithms and make your infrastructure a cleaner starting point for the eventual PQC migration. They're also consistent with NIST's current guidance on classical algorithm key sizes while PQC deployment matures.

Step 5: Ask specific vendor roadmap questions

The useful questions for your Cisco account team or TAC are not "do you support PQC?" (they'll say yes) but rather: which specific algorithm (ML-KEM-768 or ML-KEM-1024?) is in which IOS-XE version on which hardware platform, what is the upgrade path if a future NIST revision changes the algorithm, and is the PQC implementation FIPS 140-3 validated? For environments with compliance requirements, the FIPS 140-3 module validation matters as much as the algorithm selection.

Key Takeaways

• The NIST PQC standards are finalized (FIPS 203, 204, 205 as of August 2024). The "waiting for standards" reason not to plan is gone.
• Campus networks are more exposed to harvest-now-decrypt-later risk than server infrastructure. Switch lifecycles of 10 to 15 years overlap significantly with reasonable Q-day projections.
• MACsec's symmetric data plane (AES-GCM-256) is already quantum-resistant. The key exchange layer, meaning IPsec IKEv2, TLS handshakes, and PKI, is where the real exposure is.
• Cisco's "full-stack PQC" claim on the C9000 is most concrete for secure boot supply-chain integrity. Dynamic PQC key exchange for MACsec is in development; treat timelines as uncertain until specific features appear in a released IOS-XE configuration guide for your platform.
• The most actionable near-term work for most operators is PKI and certificate lifecycle hygiene. Identify certificates with lifetimes extending past 2030 that use RSA or ECDSA, and start planning migration paths now.
• Regulated industries (federal, defense industrial base, financial, healthcare) have compliance trajectories that make PQC planning active work. Most general enterprises should plan, do the PKI audit, and monitor.
• Crypto agility, meaning the ability to swap cryptographic algorithms via software update rather than hardware replacement, is more strategically important than whether any specific product ships ML-KEM today. Ask about it in procurement.