Vendor compatibility
Cisco post-quantum VPN support
Cisco IOS and IOS XE routers, Catalyst platforms, ASA and Secure Firewall (FTD) appliances, and Meraki MX security appliances terminating site-to-site IPsec.
Last reviewed
3 compatibility records
Direct answer
Cisco's post-quantum position varies by platform, train and licence, and cannot be summarised as a single yes or no. Cisco maintains several independent VPN terminating platforms — IOS XE, ASA, Secure Firewall and Meraki MX — with separate release trains and separate cryptographic roadmaps. Establish the exact platform, the exact running release and the peer's capability before treating any Cisco gateway as migratable.
Practical status
What this means in a real estate
Treat "Cisco" as at least four separate compatibility questions. A Catalyst 8000 running a recent IOS XE train, an ASA 5500-X near end of support, an FTD-managed Secure Firewall and a Meraki MX are different products with different key establishment capabilities, and a statement about one tells you nothing reliable about the others. The practical consequence for an estate audit is that the inventory must record the platform family, the exact release string and the licence tier for every Cisco gateway before any migration wave can be planned.
What to establish about key exchange
The question to answer per platform and release is which of the two IKEv2 mechanisms is available: RFC 8784 post-quantum preshared keys, which mixes an out-of-band symmetric key into the derived keys, or RFC 9370 additional key exchanges, which negotiates one or more further key exchanges alongside the classical one. These are different mechanisms with different operational costs, and a platform may implement one, both or neither.
Why authentication is a separate question
Neither RFC 8784 nor RFC 9370 changes peer authentication. A Cisco tunnel using a hybrid key exchange still authenticates with the same RSA or ECDSA certificate, or the same preshared key, that it used before. Post-quantum authentication depends on certificate and PKI support for signature algorithms such as ML-DSA, which is a separate programme from key establishment and is generally further behind it.
Products and versions
Compatibility records
Each record is scoped to a product and a version range. Key establishment and authentication are stated separately, because they migrate on different timelines through different mechanisms.
| Product | Key establishment |
|---|---|
| Cisco IOS XE routers (Catalyst 8000, ISR 4000, ASR 1000) | Post-quantum key establishment: Requires exact-version review |
| Cisco ASA 5500-X and Secure Firewall in ASA mode | Post-quantum key establishment: Requires exact-version review |
| Cisco Meraki MX security appliances | Post-quantum key establishment: Unknown |
Cisco IOS XE routers (Catalyst 8000, ISR 4000, ASR 1000)
17.xIOS XE spans a wide release surface with separate feature availability per train and per platform. Establish the exact release string and platform before assessing.
Migration implication: Plan for a per-platform, per-train capability matrix rather than a single IOS XE answer. Estates that mix Catalyst 8000 and older ISR platforms should expect to split into separate migration waves.
Caveats
- Feature availability is not uniform across IOS XE trains
- Devices outside their software maintenance window may never receive the capability
Last reviewed · low confidence · 1 source
Cisco ASA 5500-X and Secure Firewall in ASA mode
9.xASA is a separate codebase from IOS XE with its own release train. A capability present in IOS XE implies nothing about ASA.
Migration implication: Where an ASA model is past software maintenance, treat the connection as a hardware decision rather than a configuration decision and price replacement or an overlay into the migration plan.
Caveats
- Several ASA 5500-X models have passed end of software maintenance
- Hardware crypto capability differs across models and affects the performance profile
Last reviewed · low confidence · 1 source
Cisco Meraki MX security appliances
MX 18.x and later firmwareMeraki firmware is delivered through the cloud dashboard, so the customer's control over the running version is different from an on-premises appliance.
Migration implication: Migration sequencing follows the Meraki firmware release and scheduling model rather than a per-device maintenance window, which usually simplifies waves but reduces control over timing.
Caveats
- Configuration surface is narrower than a CLI-driven appliance
- Firmware scheduling is governed by the dashboard's upgrade model
Last reviewed · low confidence · 0 sources
Prerequisites
Establish these before assessing migratability.
- Exact platform family and running release string for every gateway
- Licence tier, because cryptographic feature availability can be licence-gated
- Confirmation that the device is within its supported software lifecycle
- Available flash and memory headroom for the target release
Peer compatibility
A tunnel is governed by the weaker of its two peers.
- Both peers must support the same mechanism; a hybrid key exchange cannot be enabled on one side alone
- Where the peer is another Cisco platform, confirm capability separately for each platform family
- Where the peer is a third-party or partner device, its release must be established before a change window is booked
Operational limitations
Constraints that shape the plan rather than block it.
- Larger key exchange payloads can interact with fragmentation behaviour on constrained paths
- Platforms near end of software maintenance may never receive the relevant capability
- Hardware crypto acceleration coverage differs by platform and can change the performance profile of a migration
Migration paths
The routes available when the current state is not the target.
- Upgrade to a release that carries the required capability, where one exists for the platform
- Replace the platform where the required capability will not be delivered to it
- Terminate an overlay gateway behind the existing device where replacement is not yet viable
- Defer and track, with the dependency recorded in the blocker register
Verification requirements
What must be evidenced before a change is recorded as complete.
- Confirm the negotiated key exchange method on an established SA, not the configured intent
- Capture evidence from both peers, because a one-sided view cannot prove what was agreed
- Re-verify after any failover, because an HA peer may be running a different release
Sources
No primary sources have been recorded for this entry yet. Until they are, nothing here is presented as a confirmed capability.
Individual compatibility records carry their own sources, listed against each record in the compatibility matrix.
Related reading
- GuideHybrid Post-Quantum IPsec in Practice
- GuideOptions for Legacy VPN Gateways That Cannot Migrate
- GuideVerifying a Post-Quantum VPN Migration
- Standard · RFC 7296, RFC 8784, RFC 9242, RFC 9370IKEv2 Post-Quantum Migration: The Protocol Mechanisms Available
- Standard · RFC 9370Hybrid Key Establishment: Why Migrations Combine Classical and Post-Quantum
Need this mapped to your actual Cisco estate?
A readiness assessment establishes the exact release, licence and peer position for every gateway you run — and tells you which tunnels can move first.