Post-Quantum Cryptography on Cisco 8000 Series Secure Routers for IKEv2 Sessions

Overview of Post-Quantum Cryptography

Post-Quantum Cryptography (PQC) refers to cryptographic algorithms designed to be secure against attacks from quantum computers which can break many classical encryption methods. Current widely used encryption methods—such as Diffie-Hellman (DH), and Elliptic Curve Diffie-Hellman (ECDH) – are vulnerable to being broken as quantum computing technology advances.

Implementing quantum-safe encryption now is critical for the long-term confidentiality and integrity of sensitive communications, particularly for government, military, and financial sectors.

Key Elements of Post-Quantum Cryptography

Post-Quantum Cryptography is implemented by using the algorithms available as part of Module-lattice based Cryptography. Module-lattice based cryptography is a type of quantum-resistant public-key cryptography that uses structured, high-dimensional grid points (lattices) to secure data. Cisco implements Post-Quantum Cryptography into protocols like IKEv2 for VPN security.

These algorithms are resistant to quantum attacks and are used for secure key establishment, encryption, and digital authentication or signatures.

This table lists the various ML-KEM algorithms available for VPN security:

Area of implementation ML-KEM algorithm What this algorithm means

IKEv2 tunnels

mlkem 512

mlkem 768

mlkem 1024

MLKEM stands for Module-Lattice Key Encapsulation Mechanism, which is a quantum-resistant key exchange algorithm based on module-lattice mathematics.

The number 512 or 768 or 1024 indicates the security parameter or key size variant of the MLKEM algorithm.

Implementation of Post-Quantum Cryptography

Cisco utilizes a hybrid approach to implement PQC. The hybrid approach to PQC combines a quantum-resistant algorithm, such as the module-lattice based ML-KEM (e.g. mlkem768), with a classical elliptic curve key exchange algorithm like NIST P-256 or X25519, along with a hash function such as SHA-256.

This combination provides enhanced security by protecting against both classical and quantum attacks while maintaining compatibility and performance with existing cryptographic protocols.

Cisco implements this hybrid approach in protocols like IKEv2 allowing configurations that enforce the use of ML-KEM algorithms for quantum resistance without falling back to classical-only key exchanges.
Figure 1. Post-Quantum Cryptography exchange with MLKEM algorithms
Post-Quantum Cryptography exchange using MLKEM algorithms

Supported Platforms for Post-Quantum Cryptography

Starting release Cisco IOS XE 26.1 and later, Post-Quantum Cryptography can be configured only on these platforms in the autonomous mode:

  • C8100 Series Secure Routers

  • C8200 Series Secure Routers

  • C8300 Series Secure Routers

  • C8400 Series Secure Routers

  • C8500 Series Secure Routers

Protocol Requirements for Post-Quantum Cryptography

PQC for VPN solutions such as IPsec, DMVPN, and FlexVPN is integrated into the IKEv2 protocol for the initial key establishment phase. PQC cannot be implemented on IKEv1 as it is a legacy, weak protocol that does not support the necessary extensions for PQC.

Restrictions for Post-Quantum Cryptography

Review these restrictions for Post-Quantum Cryptography

PQC support for GETVPN

In Cisco IOS XE 26.1 release, PQC is not supported on Cisco GETVPN

MTU causing fragmentation

ML-KEM-1024 (Size 1568) can cause IP fragmentation with commonly used MTU of 1500 bytes. It is recommended to enable IKEv2 Fragmentation (IKEv2 MTU of 1400 bytes) to avoid IP fragmentation and potential packet drops by using the crypto ikev2 fragmentation mtu command.

Deployment Scenarios for Post-Quantum Cryptography

Post-Quantum Cryptography can be enabled across these solutions and technologies:

Area of implementation What PQC implementation does
Site – Site Secures VTI tunnels
DMVPN

Provides quantum-resistance for hub-and-spoke and dynamic spoke-to-spoke architectures.
Remote Access Integrates ML-KEM into the IKEv2 negotiation for FlexVPN deployments.

Factors to Consider Before Deploying Post-Quantum Cryptography

Backward compatibility with classical algorithms

In a WAN deployment with multiple devices, if a device is configured for PQC and the peer does not support PQC, the session fails and no connection is established. To allow communication with such non-PQC devices, the optional keyword is used to allow fallback to classical algorithms.

This model ensures backward compatibility with existing other Cisco networking infrastructure and classical cryptography.

Impact on computational time

The key size in PQC implementations may have an impact on the computational time due to the mathematical complexity and processing requirements of quantum-resistant algorithms. Larger key sizes generally increase the computational workload. PQC implementations must consider hardware acceleration and software optimizations to mitigate the increased computational time due to larger key sizes.

Hybrid approach for data privacy

As per Cisco implementation of PQC, using set pfs in the IPsec profile ensures that ML-KEM (Multi-Lattice Key Encapsulation Mechanism) algorithms are negotiated for Child Security Associations (SAs) and their rekeys, thereby enforcing quantum-safe Perfect Forward Secrecy (PFS). This means that the key exchanges for Child SAs use PQC algorithms rather than classical Diffie-Hellman groups. But in context of a third-party IKEv2 SA, both Diffie-Hellman and PQC algorithms are used for key negotiation.

Lifetime of Hub IPSec SA

It is important to configure the hub’s IPSec SA lifetime higher than the spokes using the crypto ipsec security-association lifetime seconds command. Failure to do so results in session downtime and packet loss due to failed rekey events and hard lifetime expirations.

Workflow to Set Up Post-Quantum Cryptography for VPN Solutions using IKEv2

These steps outline the various steps in setting up PQC for IKEv2 tunnels.

Summary

Post-Quantum Cryptography involves setting up the tunnel parameters by defining an IKEv2 proposal followed by an IPSec profile.

Workflow

Setting up Post-Quantum Cryptography involves these steps :

  1. Configure tunnel parameters:
    • IKEv2 proposal – This set of commands define the cryptographic algorithms for the IKEv2 Security Association (SA), including encryption, integrity, and the Additional Key Exchange (AKE) method. At this stage of the configuration, define association with PQC ML-KEM algorithm.
    • IPsec Profile: This set of commands connects the IKEv2 profile and the IPsec transform-set, defining the overall security parameters for the IPsec tunnel. Optionally also enable Perfect Forward Secrecy to generate unique encryption key for every IPsec SA negotiation therefore ensuring maximum data security.
  2. Verify that Post-Quantum Cryptography is implemented After PQC is configured, use show commands to verify that IPsec SA is quantum safe.

Configure Tunnel Parameters to Set Up Post-Quantum Cryptography for IKEv2

Use these steps to configure PQC for IKEv2 protocol to secure the initial key establishment phase of IPsec VPN tunnels thereby securing the entire VPN architecture against future quantum threats.

Procedure

Step 1

crypto ikev2 proposal ikev2proposal

Example:

crypto ikev2 proposal ikev2proposal
 encryption aes-cbc-256
 integrity sha512
 group 21
 pqc mlkem768 mlkem1024 optional

This command creates an IKEv2 proposal named ikev2proposal. It specifies the encryption algorithm (AES-CBC-256), integrity algorithm (SHA512), Diffie-Hellman group (21), and enables PQC algorithm (mlkem768) for enhanced security. It is mandatory to use a minimum of one MLKEM algorithm to implement PQC. The optional keyword indicates that the MLKEM algorithm is proposed but is not mandatory. Fallback to classical algorithms is permitted if the peer does not support MLKEM.

Step 2

crypto ipsec profile ipsec_profile_vti

Example:

crypto ipsec profile ipsec_profile_vti
 set transform-set tset1
 set ikev2-profile ikev2profile
 set pfs

This command creates an IPsec profile named ipsec_profile_vti . It applies the transform set (tset1), the IKEv2 profile (ikev2profile), and enables Perfect Forward Secrecy (PFS) for additional security during key exchanges.

Perfect Forward Secrecy (PFS) enhances security by deriving session keys with more randomness using key exchange (KE) methods. The KE can be Diffie-Hellman (DH), Module-Lattice Key Encapsulation Mechanism (MLKEM), or a combination of DH+MLKEM. PFS is not a mandatory configuration and can be disabled without changes to existing configurations.

This table indicates the compatibility and negotiation outcomes of Perfect Forward Secrecy (PFS) settings between an Initiator and a Responder considering different PFS configurations and the use of PQC with MLKEM (Module-Lattice Key Encapsulation Mechanism).

Table 1. Compatibility and Negotiation outcomes of Perfect Forward Secrecy settings between an Initiator and a Responder
Initiator/Responder Initiator : no set pfs Initiator : set pfs Initiator: set pfs <group> Initiator : set pfs <group> pqc <mlkem>
Responder : no set pfs negotiation succeeds without PFS negotiation fails if Responder requires PFS but Initiator does not set it negotiation succeeds using Diffie-Hellman (DH) group negotiation fails if Responder requires PQC MLKEM but Initiator does not
Responder : set pfs negotiation succeeds, Initiator uses MLKEM inherited from IKEv2 SA negotiation succeeds with MLKEM inherited negotiation succeeds using a combination of DH and MLKEM inherited. negotiation succeeds using DH and MLKEM inherited
Responder : set pfs <group> negotiation succeeds using DH group negotiation fails if Responder requires PFS but no group specified. negotiation succeeds using DH group negotiation fails if Responder requires PQC MLKEM but Initiator only sets DH
Responder : set pfs <group> pqc <mlkem> negotiation succeeds using both DH and MLKEM negotiation succeeds with DH and MLKEM inherited negotiation succeeds using both DH and MLKEM negotiation succeeds using both DH and MLKEM

Verify Post-Quantum Cryptography for IKEv2

Procedure

Step 1

Use these command to verify that PQC implementation is successful for IKEv2 negotiations:

Example:

show crypto session detail

show crypto ikev2 sa detail

show crypto ipsec sa detail

Step 2

Use the details in this table to confirm that upgrade was successful.

Command Purpose What to look for in the command output
show crypto session detail

Displays Crypto session current status

 
Interface: Tunnel0
Profile: IKEv2_PROFILE
Uptime: 00:00:06
Session status: UP-ACTIVE
Peer: 10.0.149.217 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 10.0.149.217
      Desc: (none)
Refer Sample Show Command Outputs for complete show command output.
show crypto ikev2 sa detail Displays information about active IKEv2 security associations, including encryption algorithms, hash methods, Diffie-Hellman (DH) groups, peer IPs, and SPI values. 
IPv4 Crypto IKEv2  SA 
Tunnel-id Local                 Remote                fvrf/ivrf            Status 
1         10.0.149.203/500      10.0.149.217/500      none/none            READY  
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:16, Auth sign: PSK, Auth verify: PSK
      PQC Key Exchange: ML-KEM-768
      Life/Active Time: 86400/3982 sec
      CE id: 0, Session-id: 1
      Local spi: FAFDAD2E944DFBB9       Remote spi: A28909CE0B7DC230
      Status Description: Negotiation done
PQC Key Exchange: ML-KEM-768 
Quantum-safe Encryption using PQC: ML-KEM-768
Refer Sample Show Command Outputs for complete show command output.
show crypto ipsec sa detail Displays real-time information about active IPsec Security Associations (SAs), including SPI values, encryption/authentication algorithms, and packet counters (encaps/decaps) to verify tunnel health 
local crypto endpt.: 10.0.149.203, remote crypto endpt.: 10.0.149.217
     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
     current outbound spi: 0xA5BA289B(2780440731)
     PFS (Y/N): Y, DH group: group21, PQC Key Exchange: ML-KEM-1024
Refer Sample Show Command Outputs for complete show command output.

Workflow to Upgrade Devices to Post-Quantum Cryptography

This section provides the necessary requirements, procedures, and considerations for upgrading Cisco IOS-XE devices to support PQC using Hybrid Key Exchange (DH + ML-KEM).

Summary

  • Verify router software versions and models

  • Upgrade the Hub router before upgrading the Spoke router

  • Upgrade Spoke routers

  • Configure IKEv2 Fragmentation

  • Configure Perfect Forward Secrecy

  • Apply PQC configuration

Workflow

  1. Verify router software versions and modelsReview the Cisco IOS XE hardware and software requirement before upgrading to PQC. Refer Prerequisite for Post-Quantum Cryptography.
  2. Upgrade the Hub router before upgrading the Spoke routerIt is important to upgrade the Hub (Responder) before the Spokes. If PQC is configured, till all the Spokes are upgraded spoke-to-spoke traffic may be disrupted. However all traffic reaches the destination as it is routed through the Hub. When the Hub is upgraded to version 26.1 first, it can be configured using the optional keyword in the IKEv2 proposal. This allows for a phased migration where upgraded spokes can negotiate a PQC-hybrid (DH + ML-KEM) session. Legacy spokes that are not yet upgraded can still fall back to a classical Diffie-Hellman (DH) exchange. This ensures that the Hub can communicate with both PQC and Non-PQC spokes simultaneously during the transition period.
  3. Upgrade Spoke routersOnce the Hub is ready and configured with the optional keyword, you can begin upgrading your Spokes to Cisco IOS-XE version 26.1.
  4. Configure IKEv2 FragmentationIKEv2 fragmentation is necessary on the Hub (and the Spokes) primarily due to the large size of PQC keys, which exceed standard network limits.
  5. Configure Perfect Forward SecrecyFor IPsec rekeys, configure PFS to use PQC. Between two IOS-XE devices, the set pfs command automatically inherits ML-KEM settings from the IKEv2 SA.
  6. Apply PQC configurationApply PQC configuration after all the devices are upgraded. Turn off the interface and then turn it on to ensure that the configuration is applied.

Upgrade Considerations

Upgrade Considerations

Before upgrading devices to Cisco IOS XE 26.1, review this guideline :

  • Spoke-to-Spoke traffic

    Spoke-to-Spoke traffic between routers running Cisco IOS XE version 26.1 and older releases is routed through the Hub. Spoke-to-Spoke communication between two routers running version 26.1 or two routers running older releases remains functional.

Upgrade Scenarios

The impact of upgrading to PQC depends on whether the Initiator and Responder are both running Cisco IOS XE 26.1 and how the PQC proposal is configured. Let’s review some scenarios:

Table 2. Different Post-Quantum Cryptography Upgrade Scenarios
Upgrade Scenario What happens after upgrade
New Initiator (PQC) to Old Responder The session fails.
Old Initiator to New Responder Sessions are formed using classic DH exchange.
New Initiator (Non-PQC) to New Responder Sessions form without PQC.
Site to Site Upgrade Phased migration is not supported. Both spokes must be upgraded simultaneously to maintain connectivity.
FlexVPN Upgrade Phased migration is not supported. Spoke-to-spoke sessions fail if only one side is upgraded.
DMVPN Upgrade Phased migration is supported. While spoke-to-spoke sessions are not formed initially between the PQC and Non-PQC device, traffic can be directed through the Hub.

Verify Upgrade to Post-Quantum Cryptography

Procedure

Step 1

Use these commands to verify that the devices are upgraded to Post-Quantum Cryptography algorithms:

Example:

show crypto ikev2 sa detail

show crypto ipsec sa detail

Step 2

Use the details in this table to confirm that upgrade was successful.

Command Purpose What to look for in the command output Sample command output
show crypto ikev2 sa detail Displays information about active IKEv2 security associations, including encryption algorithms, hash methods, Diffie-Hellman (DH) groups, peer IPs, and SPI values.

PQC Key Exchange: ML-KEM-768

uantum-safe Encryption using PQC: ML-KEM-768

 
IPv4 Crypto IKEv2  SA 
Tunnel-id Local                 Remote                fvrf/ivrf            Status 
1         10.0.149.203/500      10.0.149.217/500      none/none            READY  
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:16, Auth sign: PSK, Auth verify: PSK
      PQC Key Exchange: ML-KEM-768
      Life/Active Time: 86400/3982 sec
      CE id: 0, Session-id: 1
      Local spi: FAFDAD2E944DFBB9       Remote spi: A28909CE0B7DC230
      Status Description: Negotiation done
PQC Key Exchange: ML-KEM-768 
Quantum-safe Encryption using PQC: ML-KEM-768
show crypto ipsec sa detail Displays real-time information about active IPsec Security Associations (SAs), including SPI values, encryption/authentication algorithms, and packet counters (encaps/decaps) to verify tunnel health

PFS value indicating PQC algorithm was used.

 
local crypto endpt.: 10.0.149.203, remote crypto endpt.: 10.0.149.217
     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
     current outbound spi: 0xA5BA289B(2780440731)
     PFS (Y/N): Y, DH group: group21, PQC Key Exchange: ML-KEM-1024

Troubleshooting Post-Quantum Cryptography Errors

Review this table to understand the resolution for some common Post-Quantum Cryptography errors.
Error Message / Symptom Likely Cause Resolution 
IKEv2-INTERNAL: Transform type 6 invalid
 Upgraded Initiator (Spoke) is connecting to an Old Responder (Hub) that doesn't support PQC. Upgrade the Hub to IOS-XE 26.1 first. Use the optional keyword in the Hub's PQC proposal to support older spokes. 
IKEv2-ERROR: Failed to parse the packet: The peer's proposal   is
                  invalid
 The Responder cannot understand the PQC transform sent by the Initiator. Upgrade the Responder or remove PQC from the Initiator's proposal until the Responder is ready.
Session is READY but show crypto ipsec sa shows no PQC IPsec rekey has not happened yet, or set pfs is not configured. Configure set pfs in the crypto ipsec profile . Note that PQC for IPsec only applies after a rekey.
NO_PROPOSAL_CHOSEN during rekey PFS configuration mismatch (e.g., one side has set pfs and the other has no set pfs . Ensure both sides have compatible PFS settings. Configure set pfs (without specific groups) on both devices is recommended for auto-inheritance.

Post-Quantum Cryptography Sample Configuration

This is an example of an end-to-end configuration of Post-Quantum Cryptography on a device 
Sample Initiator config:
!
crypto ikev2 proposal prop 
pqc mlkem1024
encryption aes-cbc-256
integrity sha512
group 15

crypto ikev2 policy pol 
 match fvrf any
 proposal prop
!
crypto ikev2 profile prof1
 match identity remote email x@cisco.com
 identity local email a@cisco.com
 authentication remote pre-share key cisco123
 authentication local pre-share key cisco123
 lifetime 1800
 no lifetime certificate
!
crypto ikev2 fragmentation mtu 1400
!
crypto ipsec profile gen
set pfs
set ikev2-profile prof1
!
interface Tunnel1
 ip address 22.22.22.1 255.255.255.0
 ip proxy-arp
 shutdown
 tunnel source Ethernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 1.1.1.1
 tunnel protection ipsec profile gen
!
interface Ethernet0/0
 ip address 1.1.1.2 255.255.255.0
 ip proxy-arp

Post-Quantum Cryptography Show Commands

Here are sample output from show commands that can be used to verify PQC configuration.

Device# show crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
R - IKE Auto Reconnect, U - IKE Dynamic Route Update
S - SIP VPN, E - Stronger IKE Encryption Enforced

Interface: Tunnel0
Profile: IKEv2_PROFILE
Uptime: 00:00:06
Session status: UP-ACTIVE
Peer: 10.0.149.217 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 10.0.149.217
      Desc: (none)
  Session ID: 1
  IKEv2 SA: local 10.0.149.203/500 remote 10.0.149.217/500 Active
          Capabilities:U connid:1 lifetime:23:59:54
  IPSEC FLOW: permit ip   0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) KB Vol Rekey Disabled/113
        Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) KB Vol Rekey Disabled/113

Device# show crypto ike sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         10.0.149.203/500      10.0.149.217/500      none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:16, Auth sign: PSK, Auth verify: PSK
      PQC Key Exchange: ML-KEM-1024
      Life/Active Time: 86400/46 sec
      CE id: 0, Session-id: 1
      Local spi: 344F7AC6A1758651       Remote spi: 8FCCD7B55AB5B9A9

 IPv6 Crypto IKEv2  SA

Device# show crypto ike sa detailed
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         10.0.149.203/500      10.0.149.217/500      none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:16, Auth sign: PSK, Auth verify: PSK
      PQC Key Exchange: ML-KEM-1024
      Life/Active Time: 86400/48 sec
      CE id: 0, Session-id: 1
      Local spi: 344F7AC6A1758651       Remote spi: 8FCCD7B55AB5B9A9
      Status Description: Negotiation done
      Local id: 10.0.149.203
      Remote id: 10.0.149.217
      Local req msg id:  3              Remote req msg id:  0
      Local next msg id: 3              Remote next msg id: 0
      Local req queued:  3              Remote req queued:  0
      Local window:      20             Remote window:      20
      DPD configured for 0 seconds, retry 0
      Fragmentation not  configured.
      Quantum-safe Encryption using PQC: ML-KEM-1024
      Dynamic Route Update: enabled
      Extended Authentication not configured.
      NAT-T is not detected
      Cisco Trust Security SGT is disabled
      Initiator of SA : Yes
      PEER TYPE: IOS-XE

 IPv6 Crypto IKEv2  SA