Cisco quantum readiness: what your router actually supports

A branch tunnel comes up. The dashboard turns green. The router’s product page mentions quantum readiness. Can the change record now say that the branch has verified post-quantum protection?

Connectivity alone cannot answer that question. The record needs evidence of the negotiated cryptography, the applicable support conditions, and the behavior after rekey or failover. A product capability, a configured option, and an observed session are different pieces of evidence.

This Field Note accompanies the Module 3 video, Cisco Quantum Readiness: What Your Router Actually Supports. It follows the same path through platform support, VPN behavior, management access, and hardware trust.

Technical sources reviewed October 15, 2026. Release-specific statements below describe those sources and require rechecking before a deployment.

Give every support claim an exact address

Start with the exact model, hardware revision, software release, and operating mode. Then name the service you want to protect. A release number without a platform and feature does not establish support.

For example, a virtual Catalyst 8000V and an 8000 Series Secure Router are different platforms. Similar names do not make their capabilities interchangeable. The applicable feature guide, restrictions, release notes, and hardware requirements must agree with the equipment you intend to use. Cisco quantum-ready migration guide.

Use three evidence labels in your notes:

Label	What it establishes
Observed	A named test produced a recorded result on specified equipment.
Documented	A vendor source describes support under stated conditions.
Planned	A roadmap describes intended future availability.

A lab result is bounded by its test conditions. A support document is not a successful deployment test. A roadmap is not current availability.

PPK practice and ML-KEM support are separate claims

A post-quantum preshared key, or PPK, contributes an additional shared secret to IKEv2 key derivation. Its usefulness depends on suitable secret strength, secure distribution, and continued secrecy. It is a different mechanism from ML-KEM key establishment. RFC 8784; Cisco PPK configuration guide.

The course reports manual PPK observations on its C8000V and IOL-XE 17.18.02 lab images. Its ML-KEM and ML-DSA exercises are explicitly documentation exercises. This boundary matters: a virtual lab can provide useful evidence for the feature it exercises without demonstrating every capability of newer hardware.

For the hybrid IKEv2 workflow discussed in Module 3, Cisco’s guide identifies the supported C8100 through C8500 Secure Router platforms, IOS XE 26.1 or later, and autonomous mode. The reviewed guide excludes GETVPN for that release. Check the current platform table and restrictions rather than extending the statement to every IOS XE device. Cisco PQC for IKEv2.

Evaluate both peers, the topology, the upgrade sequence, and the mixed-fleet period. Initial establishment, rekey, failover, packet handling, and the return path all belong in the acceptance plan.

A green tunnel can still be a failed acceptance test

Consider this illustrative record:

Required outcome: hybrid key establishment
Local configuration: hybrid option offered
Peer capability: classical only
Migration policy: classical fallback permitted
Connectivity: PASS
Negotiated result: classical
Reported readiness: VERIFIED

The final line is unsupported. The connection works, but it did not achieve the required cryptographic outcome. Cisco’s documented optional proposal behavior permits classical fallback; whether that fallback is acceptable depends on the migration policy. Cisco PQC for IKEv2.

An accepted temporary exception should be recorded as an exception. A mandatory hybrid acceptance test should fail when only a classical session is established. Inspect the negotiated result and repeat the check after rekey. Do not let a reachability test silently become a cryptographic verification test.

Check the administrator’s connection separately

IPsec support does not automatically change SSH. The reviewed Secure Router SSH guide documents hybrid key exchange for its named platforms and releases, requires explicit enablement, and excludes FIPS mode for that implementation. These restrictions are scoped to that implementation, not to every possible use of SSH or post-quantum cryptography. Cisco PQC for SSH.

The client and server must offer compatible methods. A configuration listing shows what may be offered; session evidence shows what was selected. Host authentication remains another question: changing key exchange does not, by itself, replace the host’s signing key.

MACsec keying does not establish management HTTPS support

MACsec protects link traffic. Cisco’s documented post-quantum EAP-TLS workflow uses ML-KEM in the handshake that supplies keying material for that protection. An administrator’s HTTPS or RESTCONF connection terminates at a different service. Support in the EAP-TLS workflow does not prove support in that management web server. Cisco PQC for EAP-TLS.

The course’s reviewed management guides did not confirm the corresponding management-service capability. Treat that as an evidence limit. It is not a claim that such support is permanently impossible. Record the service and recheck current product documentation before making a deployment decision.

Hardware trust answers a different question

Secure boot checks whether the device should run the software it receives. Tunnel protection concerns the confidentiality and integrity of network traffic. Neither result establishes the other.

Cisco’s Trustworthy Systems Guide ties its C9610 LMS-signed bootloader example to hardware version 2.0. That is a platform-specific requirement, not a statement that the C9610 is the only supported platform. A software upgrade cannot supply a missing hardware capability. Record the exact hardware revision and the boot requirements that apply to it. Cisco Trustworthy Systems Guide, PDF page 13.

Would you sign off this change?

The platform and release match the feature guide. The configuration contains a hybrid option. A ping succeeds. The record contains no negotiated algorithm and no rekey result.

Before opening the explanation, name the missing evidence in one sentence.

Compare your reasoning

Hybrid protection is not yet verified. The platform and release establish eligibility; the configuration establishes intent; the ping establishes reachability. Request the negotiated session result and evidence that rekey behavior meets the stated policy. If fallback is permitted, record whether it occurred and whether the policy accepts it.

Build a readiness record you can defend

For each service, record the platform and hardware revision, release and mode, both endpoints, the applicable support source, the intended cryptography, the negotiated result, rekey and failover evidence, and the fallback decision. Keep untested or undocumented items visible.

Module 3 of Cisco Quantum Readiness develops these distinctions through platform support, IPsec and IKEv2, SSH, TLS, MACsec, and hardware requirements. The following module provides manual PPK practice and clearly labeled documentation exercises. The useful outcome is a bounded claim you can support with evidence for your own environment.

RouteSwitchU is an independent training publisher and is not affiliated with or endorsed by Cisco Systems, Inc.