Part 9 migrated the key exchange across three routers, and it was smooth. The Hub router negotiates ML-KEM when it can and falls back when it can’t. You upgrade the hub, roll out to spokes at your own pace, zero outage.

Authentication doesn’t work like that.

This post is the operational reality: migrating ML-DSA authentication across a multi-router network, the experiments that show exactly where it breaks, and every gotcha we hit on 26.2. If you’re planning a PQC migration this is the post to read slowly.

The starting point: RSA certificates

Parts 9 and 10 used pre-shared keys for authentication. That kept things simple while we focused on key exchange and then on the ML-DSA certificate workflow. But most production IPsec networks don’t run PSK at scale. They use RSA (or ECDSA) certificates issued by an internal CA.

So for this migration experiment, we start from a more realistic baseline: RSA-2048 certificates on all three routers, imported via PKCS#12 the same way we imported ML-DSA in Part 10. Same process, classical algorithm. The question is: how do you get from RSA to ML-DSA across a live network?

The asymmetry

Check the difference in available capabilities between key exchange and authentication:

R1(config-ikev2-proposal)# pqc mlkem768 ?
  optional  Optionally negotiate PQ key exchange
  required  Must negotiate PQ key exchange

R1(config-ikev2-profile)# authentication local ?
  dynamic    Dynamically set local authentication method for responder
  eap        Extended Authentication Protocol
  ecdsa-sig  ECDSA Signature
  mldsa-sig  ML-DSA Signature
  pre-share  Pre-Shared Key
  rsa-sig    Rivest-Shamir-Adleman Signature

Key exchange offers optional. But for authentication you need to go with one method, no fallback. You pick mldsa-sig or rsa-sig or pre-share, period. That difference drives the entire migration strategy.

One hub, two signature algorithms

Same topology as Part 9’s phased migration. R2 is the hub with two tunnels. R1 is the already-migrated spoke (ML-DSA certificates). R3 is still running classical RSA.

R1  ==== Tunnel1, ML-DSA-65 ====  R2  ==== Tunnel2, RSA-2048 ====  R3

Both tunnels keep pqc mlkem768 optional, so the key exchange is quantum-safe on both legs. Only the signatures differ.

On R2 (hub), one profile per spoke handles this:

crypto ikev2 profile SPOKE-R1
 match identity remote address 10.0.12.1 255.255.255.255
 identity local address 10.0.12.2
 authentication local mldsa-sig
 authentication remote mldsa-sig
 pki trustpoint TP-MLDSA65

crypto ikev2 profile SPOKE-R3
 match identity remote address 10.0.23.2 255.255.255.255
 identity local address 10.0.23.1
 authentication local rsa-sig
 authentication remote rsa-sig
 pki trustpoint TP-RSA

Here’s the hub output in this mixed state:

R2# show crypto ikev2 sa
Tunnel-id Local                 Remote                fvrf/ivrf            Status
2         10.0.12.2/500         10.0.12.1/500         none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:20, Auth sign: MLDSA, Auth verify: MLDSA
      PQC Key Exchange: ML-KEM-768

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         10.0.23.1/500         10.0.23.2/500         none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:20, Auth sign: RSA, Auth verify: RSA
      PQC Key Exchange: ML-KEM-768

One hub, two tunnels, two different signature algorithms, both with ML-KEM-768. That’s a perfectly reasonable place to sit for months while you work through your network.

Can you cut over without an outage?

This is the question that matters operationally. And the answer is no. Here’s the experiment.

authentication remote is additive. Configure two methods and both stay listed:

R2(config-ikev2-profile)# authentication remote mldsa-sig

R2# show running-config | section crypto ikev2 profile SPOKE-R3
crypto ikev2 profile SPOKE-R3
 authentication remote rsa-sig
 authentication remote mldsa-sig
 authentication local rsa-sig
 pki trustpoint TP-RSA
 pki trustpoint TP-MLDSA65

So both ends can be told to accept either signature type, and the running tunnel stays up while you do it. Looks like the setup for a clean make-before-break: teach both ends to accept both, flip one side, flip the other.

It doesn’t work like that. Flip only R3’s authentication local to mldsa-sig (so R3 signs with ML-DSA while R2 still signs with RSA), and the tunnel dies:

R3(config-ikev2-profile)# authentication local mldsa-sig

R3# clear crypto ikev2 sa
R3# ping 192.168.102.1
.....
Success rate is 0 percent (0/5)

R3# show logging | include IKEv2
IKEv2-ERROR:(SESSION ID = 71,SA ID = 1):: Auth exchange failed

Both peers listed both methods and it still failed. The two ends have to present the same signature type, so the authentication cutover is atomic per peer. Change authentication local on both ends together and the tunnel comes straight back:

R2(config-ikev2-profile)# authentication local mldsa-sig

R2# show crypto ikev2 sa | include Auth sign
      Encr: ... DH Grp:20, Auth sign: MLDSA, Auth verify: MLDSA
      Encr: ... DH Grp:20, Auth sign: MLDSA, Auth verify: MLDSA

The planning table

The practical recipe: keep one IKEv2 profile per peer (or per migration group) on the hub. Stage the certificates everywhere first. Then flip peers in maintenance windows. Don’t expect the optional trick from Part 9 to save you here. And once every peer is migrated, drop the leftover authentication remote rsa-sig lines so a downgrade isn’t silently accepted.

DFUQ?

Once the tunnel is fully quantum-safe, show crypto session detail reports the status in a compact way:

R1# show crypto session detail
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
Q - Quantum-safe Encryption

Interface: Tunnel0
Profile: MLDSA-PROFILE
Session status: UP-ACTIVE
  IKEv2 SA: local 10.0.12.1/500 remote 10.0.23.2/500 Active
          Capabilities:DFUQ connid:2 lifetime:23:59:04

Read the capability letters against the legend: D is Dead Peer Detection, F is IKE Fragmentation, U is IKE Dynamic Route Update, Q is Quantum-safe Encryption.

DFUQ.

You cannot make these things up… 🙂 DFUQ is what a healthy post-quantum tunnel looks like on IOS XE. Dead Peer Detection, Fragmentation, Dynamic Route Update, Quantum-safe Encryption. All green. That’s the finish line.

Look how far we’ve come

Eleven parts. Two acts. One story.

In the container labs you built every moving part yourself: hybrid key exchange, the PPK alternative, the certificate size explosion, a live ML-DSA tunnel on your laptop. Then we took the same RFCs to three Cisco 8000 routers: ML-KEM with a phased rollout, ML-DSA certificates from an external CA, and the migration playbook that tells you where the platform is ready and where it still hurts.

You started Part 1 with a question: is your VPN ready for the quantum era? You can answer it now.

You know which pillar is urgent. Key exchange: harvest now, decrypt later, fix it with ML-KEM hybrid (or PPK as a stopgap). You know which one has the sneakier deadline. Authentication: long-lived trust anchors, forged identities, fix it with ML-DSA. You know what those fixes cost on the wire (~24 KB per handshake for a fully quantum-safe tunnel on IOS XE, not per packet). And you know the migration isn’t symmetric: key exchange rolls out with “optional”, authentication cuts over atomically, one peer at a time, in a maintenance window.

From “what even is post-quantum cryptography?” to watching both pillars negotiate on production hardware. The headlines about quantum computers breaking the internet? They stop being scary once you’ve seen a tunnel come up with your own eyes.

That’s the series. Containers first, Cisco second, honest about the rough edges throughout. If you’re planning a migration, you now have a map. If you’re still exploring, you know exactly where to start.

Go quantum-proof your network!