Why migrate post-quantum key exchange before signatures?

Migrating post-quantum key exchange before signatures means changing the way VPN and gateway peers agree on session keys, using ML-KEM from FIPS 203, before changing how the peers prove who they are. Recorded encrypted traffic is exposed to future decryption. A signature that was checked during a live handshake does not carry that same delayed risk.

For organizations that run operational technology (OT) and critical infrastructure, this order matters a great deal. Site-to-site links, edge-to-cloud paths and remote access sessions often carry process data, engineering changes and credentials that stay sensitive for years. The plant equipment behind those links is replaced only slowly. This article explains why the sequence makes sense, which US federal deadlines apply, and what will have to change once authentication moves to ML-DSA.

Why should post-quantum key exchange be migrated before post-quantum authentication?

The two halves face different threats. Key exchange protects confidentiality, and traffic recorded today can be decrypted later. Authentication only has to hold during the moment it is checked.

The IETF’s guidance for applications describes the difference clearly. It notes that while data confidentiality faces the immediate and pressing threat of “Harvest Now, Decrypt Later” attacks, requiring urgent quantum-safe adoption, data authentication poses a longer-term risk that still necessitates careful planning. It also points out that client/server authentication based on certificates cannot be retroactively compromised.

Applied to a VPN, the logic works like this. Suppose an adversary records an IKEv2 or TLS-based tunnel between a substation and a control centre today. Once a cryptographically relevant quantum computer exists, they could recover the classical Diffie-Hellman secret and decrypt every packet they stored. A forged RSA or ECDSA signature, by contrast, is useful only to someone who can forge it during a live handshake. That capability does not exist yet.

Deployment progress follows the same split. The IETF reports that post-quantum key establishment has moved from standards into deployment. The Internet Architecture Board (IAB), which is organizing a dedicated workshop on the topic, describes authentication as follows: “Post-quantum authentication is the harder half, and it lags.”

What are the US federal deadlines under EO 14412 and OMB M-26-15?

Executive Order 14412 sets different dates for the two halves. Key establishment for high-value and high-impact federal systems must be post-quantum by the end of 2030, and digital signatures by the end of 2031. OMB Memorandum M-26-15 is the guidance agencies use to carry out that schedule.

Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, was signed on June 22, 2026. It was followed by OMB Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography (June 24, 2026). NIST’s NCCoE summarises that the order mandates an accelerated, government-wide migration to PQC for federal systems, establishing binding deadlines for high-value assets and directing the Federal Acquisition Regulatory Council to require contractor compliance with NIST PQC standards.

An analysis published in an IETF Internet-Draft states that the order directs the issue of guidance requiring federal agencies to transition high-value assets and high-impact systems to post-quantum key establishment by 31 December 2030 and to post-quantum digital signatures by 31 December 2031. The same draft observes that the federal timeline places signatures a full year after key establishment. That ordering is not arbitrary: it encodes the conventional judgment that signature migration is the less urgent half.

NIST IR 8547 sets the outer limit for the algorithms themselves. Its draft proposes 112-bit algorithms deprecated after 2030, and all quantum-vulnerable public key algorithms, including RSA-3072, P-256, and P-384, disallowed after 2035. Outside the US, the European Commission states that the protection of high-risk use cases should be transitioned to PQC as soon as possible, no later than by the end of 2030.

Can a VPN tunnel use ML-KEM key exchange while still authenticating with RSA or ECDSA certificates?

Yes. Key agreement and peer authentication are separate steps in IKEv2 and in TLS 1.3, so a tunnel can derive its keys from a hybrid classical plus ML-KEM exchange while the peers still sign with existing RSA or ECDSA certificates.

In IPsec, RFC 9370 (Multiple Key Exchanges in IKEv2) lets peers run additional key exchanges, such as ML-KEM, alongside the classical Diffie-Hellman exchange. All of the results feed into the keys for the IKE and Child security associations. The IKE_AUTH step, where the certificate signature is checked, does not change. As a result, operators can upgrade confidentiality without reissuing a single certificate.

This only works if three conditions hold:

• The derivation is truly hybrid. The session key must depend on both the classical and the ML-KEM secret, so that breaking one of them is not enough to recover the key.
• Rekeying uses the same hybrid exchange. If a Child SA rekey falls back to classical Diffie-Hellman only, traffic after that rekey is exposed again. Check CREATE_CHILD_SA settings as well as the first handshake.
• Classical-only fallback is disabled. If a peer quietly negotiates down to a classical group, the protection is gone without anyone noticing.

The Quantum Gateway from Quantum Network follows this hybrid pattern. It combines a classical part and an ML-KEM part into one session key, and both handshakes renew every two minutes. Short renewal intervals limit how much traffic any single session key protects.

NIST guidance also supports a hybrid approach over the long term. As summarised in IETF work, the NIST IR 8547 note on hybrid modes states that the disallowment of quantum-vulnerable algorithms after 2035 was not intended to apply to hybrid modes that incorporate an approved PQC algorithm alongside a quantum-vulnerable algorithm.

How long is it safe to keep classical signatures on site-to-site and remote access connections?

For live tunnel authentication, classical signatures stay safe until someone can forge them in real time. For planning purposes, though, the useful limits are the policy dates: 2031 for US federal high-value systems, deprecation of 112-bit keys after 2030, and disallowance of all classical algorithms after 2035.

The useful question is not “when will quantum computers arrive?” but “how long does our signature migration take?” NIST’s earlier analysis warned that in the best case, 5 to 15 or more years following the publication of cryptographic standards will elapse before a full implementation of those standards is completed. FIPS 204 was published in August 2024, which leaves little room before 2035.

Several factors shorten the safe period for OT operators in particular:

• Key sizes in use. RSA-2048 and P-224 provide 112-bit security and become deprecated after 2030. RSA-3072 and P-256 remain acceptable until the 2035 disallowance.
• Long-lived trust anchors. A root CA created now with RSA may still be trusted in the 2040s. In remote access, every client trust store has to be updated before the root can be replaced.
• Equipment lifetimes. One public comment on NIST IR 8547 noted that SCADA systems often stay in use for greater than 15 years. Any gateway or embedded VPN endpoint bought today must be able to receive ML-DSA later.
• Industry readiness. The IAB cites a 2025 survey of more than a thousand security leaders in which only 5% had deployed any quantum-safe encryption [PQREADY], and authentication lags even that.

What has to change in a VPN or gateway when authentication moves to ML-DSA?

Moving to ML-DSA affects the whole trust chain, not one setting. Certificates, CAs, key storage, handshake message sizes and client trust stores all change, so the work has to be planned as a PKI project.

The IAB points to message size as the main engineering problem: the signatures and public keys are large, several kilobytes for ML-DSA [FIPS204] and SLH-DSA [FIPS205] signatures larger still, whereas the elliptic-curve mechanisms in use today take a few dozen bytes. For a VPN or gateway, that has these consequences:

Sequencing the authentication change

A low-risk order is to build the ML-DSA CA hierarchy first and distribute its roots to every peer and client. The next step is to enable dual or composite certificates on hub gateways, then move spoke sites one at a time and remove classical-only acceptance only when the last peer has migrated. OT sites with maintenance windows of a year or more should be scheduled first, not last.

Why crypto agility decides the cost

Gateways that can change algorithms through a software update avoid a hardware refresh at each site. This matters when one signature change has to reach dozens of substations, pumping stations or remote plants. In procurement, ask vendors directly how ML-DSA certificates will be supported on the hardware being bought, and whether that support depends on an active update subscription.

How should OT operators plan the two-phase migration?

Treat key exchange as a project to finish now and authentication as a project to start now. Both begin with an inventory of every tunnel, its endpoints and its certificate chain.

CISA emphasizes buying equipment that can make the move. Acting Director Madhu Gottumukkala said: “To stay ahead of these emerging risks, organizations must prioritize the procurement of PQC-capable technologies.” NIST gives the same direction: cybersecurity products, services and protocols will need updates, and organizations must identify where vulnerable algorithms are used and plan to replace or update them.

For a typical OT estate, a workable plan looks like this:

1. Inventory. List every site-to-site, edge-to-cloud and remote access path, including the key exchange group, rekey settings, certificate algorithm, key size and CA expiry for each.
2. Rank by data lifetime. Paths that carry engineering files, safety system data or long-lived credentials get hybrid ML-KEM first.
3. Turn on hybrid key exchange. Enable ML-KEM on the initial handshake and on every rekey, and disable classical-only fallback.
4. Upgrade 112-bit keys. Replace RSA-2048 certificates with RSA-3072 or P-256 as an interim step before 2030.
5. Pilot ML-DSA. Test fragmentation and handshake timing on the most constrained links, such as cellular or satellite backhaul, where large handshakes are most likely to cause trouble.

Done in this order, the confidentiality exposure is closed first, and the harder authentication work proceeds on a schedule set by the deadlines rather than by an emergency.