How does ML-DSA IKEv2 authentication work for VPNs?

ML-DSA IKEv2 authentication means VPN peers prove their identity in the IKE_AUTH exchange of RFC 7296 by signing with ML-DSA, the lattice-based signature algorithm standardized in FIPS 204, rather than RSA or ECDSA. It protects the authentication half of an IPsec tunnel against future quantum computers, which complements post-quantum key exchange.

For organizations that run OT and critical infrastructure, the question is not just whether this works but when to deploy it, which parameters to pick and how to keep older gateways running during the transition. This article goes through each of those decisions using the current IETF and NIST documents.

Is post-quantum authentication in IPsec standardized yet, or is it still an IETF draft?

The building blocks are standardized, but the document that defines how IKEv2 uses them is still an Internet-Draft. The algorithms (FIPS 204, FIPS 205), the certificate format (RFC 9881) and the negotiation mechanism (RFC 9593) are final. The IKEv2 integration, draft-ietf-ipsecme-ikev2-pqc-auth, is not.

The working group draft specifies a generic mechanism for integrating post-quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. It began as an individual submission, draft-reddy-ipsecme-ikev2-pqc-auth, and the IETF Datatracker now lists that document as replaced by draft-ietf-ipsecme-ikev2-pqc-auth. When this article was written, the Datatracker showed revision -08 as the current version.

The certificate layer is further along. RFC 9881, published in October 2025, specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs.

In practice, the draft status means that code points and some details could still change. Lab interoperability testing makes sense now. Production rollout on gateways you cannot easily upgrade, such as substation or pipeline equipment, should wait for publication as an RFC.

How do you use ML-DSA certificates to authenticate IKEv2 VPN peers?

You issue each gateway an X.509 certificate that holds an ML-DSA public key (per RFC 9881), configure the peer to trust the issuing CA, and let IKEv2 use the RFC 7427 “Digital Signature” authentication method. The ML-DSA algorithm is identified inside the AUTH payload by its AlgorithmIdentifier.

Step 1: Build the certificate hierarchy

RFC 9881 uses one object identifier per parameter set. The AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-ml-dsa-*, where * is 44, 65, or 87. Decide early whether your root and intermediate CAs will also sign with ML-DSA. A gateway certificate with an ML-DSA key that is signed by an RSA root still leaves the chain dependent on a quantum-vulnerable algorithm.

Step 2: Signal that you can verify ML-DSA

Because IKEv2 has no built-in way to negotiate authentication methods, the draft describes several signals. One uses the Certificate Request payload: the initiator could indicate in the Certificate Request payload that it trusts a certificate authority certificate signed by an ML-DSA or SLH-DSA key. This indication implies that the initiator can process ML-DSA or SLH-DSA signatures. The more explicit route is RFC 9593, covered in the next section.

Step 3: Sign the AUTH payload in pure mode

ML-DSA hashes the message internally, so IKEv2 signs the SignedOctets directly. The draft favours pure mode for a practical reason: the prehashed versions of ML-DSA and SLH-DSA appear to be rarely used, making it likely that support for them in cryptographic libraries is limited or unavailable. Implementations can also use the ExternalMu approach, and both methods produce the same ML-DSA signature and are fully interoperable.

Step 4: Plan for large IKE_AUTH messages

ML-DSA certificates and signatures are much larger than their ECDSA equivalents, so an IKE_AUTH message carrying a full chain will span several packets. Turn on IKEv2 fragmentation (RFC 7383) on both peers, and check that firewalls and industrial DMZ devices along the path pass fragmented IKE traffic on UDP 500 and 4500.

How does RFC 9593 SUPPORTED_AUTH_METHODS negotiate post-quantum signature algorithms between VPN gateways?

RFC 9593 lets each peer send an ordered list of the authentication methods and signature algorithms it supports, so the other side can choose a credential that will verify. It does not force a choice. It cuts the risk of failed SA setup when gateways hold both classical and post-quantum certificates.

The mechanism adds one notification. When establishing an IKE SA, each party may send to its peer a list of the authentication methods it supports and is configured to use. For this purpose, this specification introduces a new Notify Message Type SUPPORTED_AUTH_METHODS.

• Value assigned: SUPPORTED_AUTH_METHODS is Notify Message Type 16443 in the IANA registry (RFC 9593, July 2024).
• Responder first: the responder places the list in the IKE_SA_INIT response, and this notification contains a list of authentication methods supported by the responder, ordered by their preference.
• Initiator second: the initiator sends its own list in the IKE_AUTH request.
• Backward compatible: If the initiator doesn’t support this extension, it ignores the received notification as an unknown status notify.

For post-quantum algorithms, the announcement uses the multi-octet format tied to the Digital Signature method, which carries a DER-encoded AlgorithmIdentifier. That is how a gateway states “ML-DSA-65” rather than just “signatures”. A Cert Link field can tie an announcement to a particular trust anchor: the announced authentication method is intended to be used only with the N-th trust anchor (CA certificate) from the Certificate Request payload(s) sent by this peer. This matters in a migration where an RSA CA and an ML-DSA CA run side by side.

Long lists can push IKE_SA_INIT past a safe size. In that case the responder can defer the list to the IKE_INTERMEDIATE exchange (RFC 9242), where IKE fragmentation [RFC7383] for long messages (which cannot be used in the IKE_SA_INIT exchange) is available.

Valery Smyslov, the author of RFC 9593, names post-quantum algorithms as a motivation for the extension, writing that emerging post-quantum signature algorithms may bring additional challenges for implementations, especially if so-called hybrid schemes are used.

Should site-to-site VPNs use ML-DSA-44, ML-DSA-65 or ML-DSA-87?

For most commercial site-to-site tunnels, ML-DSA-65 is a sensible default. Choose ML-DSA-87 where a policy demands the highest category or where certificates must stay trusted for a long time. ML-DSA-44 fits constrained paths where message size matters most.

The draft notes that ML-DSA is instantiated with 3 parameter sets for the security categories 2, 3, and 5. Sizes increase with each step:

Source: IETF draft-ietf-lamps-pq-composite-sigs serialization table (2025), consistent with FIPS 204.

Policy can make the decision for you. The NSA-authored CNSA 2.0 IPsec profile states that this profile REQUIRES the use of digital signature ML-DSA-87 [FIPS204]. If the relying party receives a message signed with any authentication method other than ML-DSA-87, it MUST return an AUTHENTICATION_FAILED Notify payload. Operators outside US National Security Systems are not bound by that profile, but suppliers to defence or federal bodies often adopt it.

A pattern that works well: sign root CAs with ML-DSA-87 (or SLH-DSA from FIPS 205, which relies only on hash function security), and issue gateway end-entity certificates with ML-DSA-65. The cost of the larger root signature is paid only when the chain is validated, while the per-session signature stays moderate.

Should ML-DSA run in hedged or deterministic mode for IKEv2 authentication?

Use hedged mode unless you have a specific reason not to. Both modes are safe in IKEv2 because every session signs unique data, but hedged mode adds fresh randomness, which helps against some side-channel attacks on gateways that may be physically reachable.

The draft authors (T. Reddy, V. Smyslov and S. Fluhrer) put the choice plainly: “PQC signatures may be generated in either deterministic or hedged modes.” They explain that the hedged mode provides some resistance against this risk by including precomputed randomness in the signer’s private key and incorporating fresh randomness generated at signing time. This foils some side channel attack approaches, while adding no additional strength against others.

The reason deterministic mode is not dangerous here is specific to IKEv2. The earlier individual draft observed that the data used for signature creation includes session-specific information such as nonces, cryptographic parameters, and identifiers. Therefore, if ML-DSA is used as an authentication method within the IKEv2 protocol, the deterministic version of ML-DSA can be utilized. A later working group revision went further and stated a preference for using the hedged mode.

Does ML-DSA authentication in IKEv2 need to happen before 2030 or only after ML-KEM key exchange is in place?

Deploy ML-KEM key exchange first, because recorded traffic can be decrypted later. Authentication only has to be quantum-safe before a cryptographically relevant quantum computer exists. Even so, the PKI work behind ML-DSA takes years, so it should start now and finish ahead of NIST’s 2030 milestone.

The two halves face different threats. Key exchange protects confidentiality, and an adversary can record encrypted OT telemetry today and try to decrypt it later. A forged signature, by contrast, only helps if it can be produced during a live handshake, so classical authentication stays effective until large quantum computers are real. That is why the first move for many operators is hybrid key exchange (RFC 9370 additional key exchanges with ML-KEM from FIPS 203), with signatures following later.

“Later” still has a deadline:

• NIST IR 8547 (proposed): quantum-vulnerable algorithms at 112-bit security strength - deprecated after 2030, disallowed after 2035 (NIST, 2025). That covers RSA and ECDSA used for IKEv2 authentication.
• NSM-10: as quoted in NIST IR 8547, US policy aims at the transition with the goal of mitigating as much of the quantum risk as is feasible by 2035.

For OT the timing is tighter than those dates suggest. Gateways in substations, treatment plants and pipelines often stay in service for ten years or longer, and replacing a CA hierarchy means touching every peer. A gateway bought in 2026 without a path to ML-DSA certificates may still be running when classical signatures become disallowed.

How should OT and critical infrastructure operators sequence the migration?

Start with an inventory of every tunnel, its peers and the remaining service life of each device, then rank tunnels by how long their traffic needs to stay confidential. Fix confidentiality first and authentication second, and budget for CA work, not just gateway firmware.

1. Inventory crypto agility: record which gateways can take firmware with ML-KEM and ML-DSA support and which never will. Devices that cannot be upgraded need a compensating plan, such as an inline gateway in front of them.
2. Protect key exchange: some operators add a dedicated Layer 3 gateway rather than upgrading every router. Quantum Network’s QPN, for example, combines a classical and an ML-KEM (FIPS 203) key agreement into one session key and sits alongside existing firewalls and routers.
3. Stand up a post-quantum CA: issue RFC 9881 certificates in a test hierarchy and measure IKE_AUTH sizes across your real WAN and satellite links.
4. Enable RFC 9593 announcements: run dual credentials (ECDSA plus ML-DSA) so new and old peers can still find a common method during cut-over.
5. Cut over by tunnel class: move the longest-lived, highest-consequence tunnels first once the IETF draft is final and your implementations interoperate on its code points.