Post-quantum client certificate remote access VPN: needed?

A post-quantum client certificate for a remote access VPN is an X.509 user or device certificate signed with, and holding a public key for, a quantum-resistant signature algorithm such as ML-DSA from FIPS 204. Its job is to prove who the remote user is. Protecting the confidentiality of the session itself is a separate task, handled by the key exchange.

Operators of OT and critical infrastructure usually depend on remote access for engineers, on-call staff and outside contractors. For them, the useful question is not whether to migrate. It is what to migrate first, and how certificates fit into EAP-TLS and IKEv2 (RFC 7296). This article covers those points, the NIST IR 8547 deadlines and the practical steps for Windows and macOS fleets.

Do remote access VPN client certificates need to be replaced with post-quantum certificates?

Yes, eventually. RSA and ECDSA user certificates will have to be replaced with ML-DSA (or hybrid) certificates, but on a later schedule than the key exchange. The urgency depends on what the certificate protects. It does not depend on how widely it is deployed.

A client certificate is used in a live handshake. To abuse it, an adversary must forge a signature while the session is being set up. A recording made today cannot be turned into a valid login later. Confidentiality is different: traffic captured now can be decrypted once a cryptographically relevant quantum computer exists. That asymmetry is why most migration plans put hybrid key exchange first and authentication second.

Replacement is still unavoidable. Signature algorithms also have a hard end date, and replacing a user PKI takes years. You need new CA hierarchies, new trust anchors on every endpoint, new enrollment profiles and gateways that can verify the new signatures. FIPS 204 defines ML-DSA, and RFC 9881 defines how ML-DSA keys and signatures are encoded in X.509 certificates and CRLs. The standards to build on already exist.

Is quantum-safe key exchange enough for remote users if login still uses RSA or ECDSA certificates?

For now it covers the most urgent risk, which is decryption of recorded sessions. It does not finish the migration. RSA or ECDSA login stays acceptable only while no quantum computer can forge those signatures, and only until the NIST IR 8547 dates apply.

There is a practical benefit. Under RFC 7296, EAP messages travel inside encrypted IKE_AUTH payloads. If the IKE SA uses a hybrid ML-KEM key exchange, the user’s certificate, identity and the inner EAP-TLS handshake are shielded from collection and later decryption, even while the signature itself is still RSA or ECDSA. Your remaining exposure is then limited to forgery, which cannot be done retroactively.

How does EAP-TLS in IKEv2 remote access work with post-quantum algorithms?

In IKEv2 remote access, the gateway usually authenticates with its own certificate. The user is authenticated by an EAP method, often EAP-TLS, carried inside IKE_AUTH. Making this post-quantum means changing three things: the IKE key exchange, the signatures in the inner TLS 1.3 handshake, and the certificates on both sides.

Where the keys and signatures sit

RFC 9190 (EAP-TLS 1.3) runs a full TLS 1.3 handshake inside EAP. In that handshake the client signs with the private key behind its certificate, and the gateway or RADIUS server verifies the signature. The handshake produces keying material (the MSK), which IKEv2 uses in its AUTH calculation to bind the EAP result to the IKE SA. Each layer therefore has its own algorithms:

• Outer IKE SA: hybrid key exchange, typically classical ECDH plus ML-KEM, using the additional key exchange mechanism of RFC 9370 together with the IKE_INTERMEDIATE exchange.
• Inner TLS 1.3: ML-DSA signature schemes for CertificateVerify. The IETF TLS working group draft on ML-DSA defines the code points.
• Certificates: ML-DSA public keys and CA signatures encoded according to RFC 9881.

The IETF EMU working group is writing this down for EAP specifically. Its draft covers EAP-TLS, EAP-TTLS, PEAP and TEAP, and sets out post-quantum key agreement and authentication requirements along with a mechanism to reduce handshake size. It is still an Internet-Draft, so check what your gateway and RADIUS infrastructure actually implement.

Why certificate size is the real engineering problem

ML-DSA keys and signatures are much larger than their elliptic curve equivalents. In EAP that matters, because EAP runs over a lossy, round-trip-limited transport:

A single ML-DSA-65 end-entity certificate already carries a public key and a CA signature that together exceed one EAP fragment. Add an intermediate CA and the client’s CertificateVerify, and the exchange spans many round trips. RFC 9191 records that large chains can push EAP sessions past round-trip limits. The IETF EMU working group puts it plainly: “PQC certificates and certificate chains tend to be significantly larger than their traditional counterparts.”

Practical mitigations:

• Keep user chains short: one issuing CA, no cross-certificates sent in the handshake.
• Strip unnecessary extensions from user certificates.
• Enable IKEv2 fragmentation (RFC 7383) for the outer exchange.
• Raise the RADIUS server’s EAP round-trip limit where the platform allows it.
• Test over the worst links your users actually have, such as cellular, hotel Wi-Fi and satellite at remote substations.

When do RSA and ECDSA user certificates for remote access have to be migrated under NIST IR 8547?

The NIST IR 8547 initial public draft (12 November 2024) deprecates 112-bit RSA and ECDSA after 2030 and disallows all quantum-vulnerable signature algorithms after 2035. Which date applies to you depends on the key size in your current user certificates.

Work back from those dates. User certificates are often valid for one to three years, and CA certificates for much longer. An issuing CA created in 2027 with an RSA key would outlive the 2030 deprecation. In practice, any new remote access CA you stand up from now on should be ML-DSA-capable, or at least run in parallel with an ML-DSA hierarchy.

NIST’s position on timing is clear. When FIPS 203 and FIPS 204 were released, Dustin Moody, who heads NIST’s PQC standardization project, said: “We encourage system administrators to start integrating them into their systems immediately, because full integration will take time.” The NIST PQC project page says of ML-DSA, SLH-DSA and ML-KEM: “They can and should be put into use now.”

How do you roll out ML-DSA client certificates to Windows and macOS laptops?

Run it as a parallel PKI migration. Build an ML-DSA CA, distribute its trust anchor, enroll a second certificate next to the existing one, then switch the VPN profile, all through your device management channel. The hard parts are endpoint key storage and support across the full chain, not the enrollment itself.

1. Confirm support end to end

Before you issue anything, check that each component can handle ML-DSA: the operating system certificate store and crypto API on each Windows and macOS version in your fleet, the VPN client, the IKEv2 gateway, and the RADIUS or EAP server. If one component cannot parse an RFC 9881 certificate, authentication fails. Record minimum OS builds as a hard prerequisite.

2. Decide where private keys live

Today, client keys are often held in a TPM on Windows or the Secure Enclave on Mac hardware. Those components were built for RSA and elliptic curve keys. Find out whether your hardware generation supports ML-DSA keys. If it does not, choose deliberately between software-protected keys for an interim period and waiting for hardware support. Write that decision into your risk register.

3. Choose a certificate strategy

• Dual certificates: each device holds an ECDSA certificate and an ML-DSA certificate, and the VPN profile picks one. This is the simplest option and easy to roll back.
• Composite certificates: one certificate carries an ECDSA key and an ML-DSA key. It is attractive during transition, but it is still defined in IETF LAMPS drafts.
• Pure ML-DSA: the end state, once every relying party supports it.

4. Enroll through device management

Push the new root and issuing CA certificates first and give them time to reach every device. Then deploy the enrollment profile (SCEP or EST) with ML-DSA key generation. Laptops that connect rarely, such as an engineer’s machine kept in a control room cabinet, need a longer overlap window.

5. Pilot, measure, switch

Pilot with a small group on varied networks. Track EAP round trips, handshake time and failure rates. Then move VPN profiles to the ML-DSA certificate in waves, and keep the classical profile available until failure rates are stable.

What does this mean for remote access into OT and critical infrastructure?

Split the work into two tracks: move remote access key exchange to hybrid ML-KEM now, and treat user-certificate migration as a PKI programme that runs to 2030. In OT the two tracks often belong to different teams, so assign owners explicitly.

Many OT remote access paths end at jump hosts or engineering workstations. Their sessions carry things like setpoints, network diagrams and credentials, which stay sensitive for years, so the key exchange track deserves priority. One option is a Layer 3 encryption gateway. Quantum Network’s QPN, for example, uses a hybrid key agreement that combines a classical part and ML-KEM into one session key, and offers a software client for current Windows and macOS. That covers the confidentiality layer. Your organisation’s user certificates and PKI lifecycle remain a separate workstream with their own NIST IR 8547 deadlines.