Are VPN certificates vulnerable to quantum computers?

Yes, VPN certificates are vulnerable to quantum computers when they use RSA or ECDSA. In an IPsec or TLS tunnel, the certificate signature proves that each gateway is who it claims to be. A cryptographically relevant quantum computer running Shor’s algorithm could recover the private key from the public key, and with that key someone could forge a gateway’s identity. The problem is separate from encryption, and it needs its own migration plan.

This article explains why authentication risk works differently from the better-known “harvest now, decrypt later” problem, what NIST’s timelines mean in practice, and how long-lived operational technology (OT) assets change the calculation for sites, cloud links and remote users in critical infrastructure.

Are RSA and ECDSA certificates in VPNs vulnerable to quantum computers?

Yes. Every signature algorithm in FIPS 186-5 that VPNs commonly use, including RSA, ECDSA and EdDSA, is classed by NIST as quantum-vulnerable. Increasing the key size does not fix this.

In IKEv2, the protocol behind most IPsec VPNs, peers authenticate in the AUTH payload, usually by signing with a certificate’s private key. RFC 7427 (Signature Authentication in IKEv2) generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. That flexibility helps now, because the same mechanism can carry post-quantum signatures. NIST’s current list is unambiguous: SP 800-56A (Diffie-Hellman, ECDH), SP 800-56B (RSA encryption) and FIPS 186 (RSA, DSA and ECDSA signatures) are all vulnerable to attacks from a large-scale quantum computer.

The weak point is not only the gateway certificate. The whole chain is exposed: root CA, intermediate CAs, gateway and client certificates, plus any certificate revocation infrastructure signed with the same algorithms. A root CA’s public key is published by design. Once quantum attacks become practical, that public key is all an adversary needs to work out the signing key.

Why is quantum authentication risk different from harvest now, decrypt later?

Harvest now, decrypt later threatens confidentiality in retrospect. Authentication risk only applies after a quantum computer exists, but whatever trust anchors are deployed at that point are exposed at once.

The authors of RFC 8784 summed up the confidentiality problem in 2020: “someone storing VPN communications today could decrypt them at a later time when a quantum computer is available.” Traffic recorded today is already at risk, so the fix (post-quantum key exchange) has a deadline in the past.

Authentication works the other way. A signature only has to hold at the moment of the handshake. Breaking an RSA signature from 2025 in 2035 does nothing to a session that has already ended. So there is no retroactive harm, and this is why many organizations sensibly put key exchange first.

The catch is lead time. On the day a quantum computer appears, every RSA or ECDSA certificate still trusted becomes a forgery risk at the same moment, along with every CA key that can issue new ones. Replacing a PKI is slow. NIST’s crypto-agility guidance notes that all certificates signed using that algorithm or hash function would need to be replaced when support for a signature algorithm ends. The authentication deadline is therefore set by how long the migration takes, not by how long the data must stay secret.

Is quantum-safe key exchange enough if authentication still uses RSA?

For now, mostly yes: hybrid post-quantum key exchange stops recorded traffic from being decrypted later. In the long run, no. Once RSA can be forged, an active man-in-the-middle could take part in a perfectly quantum-safe key exchange while posing as the legitimate peer.

Post-quantum key agreement ensures that only the two endpoints of a handshake can derive the session key. It cannot ensure that the other endpoint is the right one. Authentication binds the key to an identity, and if that binding uses RSA or ECDSA, the binding is the weak link once quantum attacks become practical.

This sets a sensible order of work: protect confidentiality first, because that exposure is already happening, then move authentication well before quantum computers arrive. When you evaluate a tunnel product, ask two separate questions: which algorithms protect the key exchange, and which protect peer authentication. Quantum Network’s QPN gateway, for example, documents a hybrid key agreement that combines a classical and an ML-KEM (FIPS 203) part into one session key, with both handshakes renewed every two minutes, and its post-quantum algorithm can be changed if necessary. Even so, the authentication question should be raised separately for any gateway.

Where RFC 8784 fits

RFC 8784 (Post-quantum Preshared Keys for IKEv2) was the IETF’s first answer for IPsec. It mixes a post-quantum preshared key (PPK) into the IKEv2 key derivation, ensuring the derived keying material depends on the PPK as well as the (EC)DH/PQC contributions. Entropy matters here:

• Statistic (IETF RFC 8784, June 2020): any post-quantum preshared key containing at least 256 bits of entropy will provide 128 bits of post-quantum security.

PPKs work well for a small number of fixed site-to-site links. With hundreds of field sites or remote users, distributing and rotating them becomes the same key management burden that PKI was meant to remove.

When will NIST deprecate ECDSA and RSA signatures?

Under NIST IR 8547, RSA and ECDSA signatures at 112 bits of security strength are deprecated after 2030 and disallowed after 2035. Stronger parameter sets are disallowed after 2035.

“Deprecated” means the algorithm and key length/strength may be used, but there is some security risk. “Disallowed” means it may no longer be used to apply cryptographic protection. NIST’s own summary is direct: “NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier.”

How long do certificates on OT devices stay in service, and why does that matter for quantum risk?

OT assets such as RTUs, PLC gateways, substation routers and field VPN appliances often run for decades, and their certificates and trust anchors frequently stay in place for the life of the device. Equipment bought now with only RSA or ECDSA support may still be authenticating tunnels after 2035.

CISA has flagged this structural issue for years. Its 2022 insight on critical infrastructure described the long replacement life cycle of ICS hardware and wide geographic distribution of equipment as an area of concentrated vulnerability. Its 2024 OT guidance expects post-quantum migration in OT to be a significant and enduring challenge for owners and operators of U.S. critical infrastructure, and explicitly lists managing virtual private network (VPN) or over-the-internet remote connectivity among OT uses of asymmetric cryptography.

Three OT realities make authentication harder than in IT:

• Long certificate validity. Device certificates are often issued for the expected life of the asset, because re-enrolling a device at a remote site means a maintenance window or a site visit.
• Embedded trust anchors. Root CA certificates baked into firmware cannot be swapped without a firmware update, and many safety-certified devices are rarely updated.
• Constrained hardware. Larger post-quantum keys and signatures can exceed what older devices can store or process.

The practical consequence is that the quantum deadline for an OT certificate depends on the replacement date of the asset that holds it, not on its notAfter field. A root CA created in 2026 to last 20 years runs straight past every NIST date.

When should ML-DSA replace RSA and ECDSA for tunnel authentication?

Start now with new trust anchors and new purchases, and aim to have ML-DSA authentication running on long-lived links before 2030. The standard is final; the remaining work is protocol integration and operations.

FIPS 204 specifies ML-DSA, the lattice-based signature scheme selected from a field of candidates in NIST’s public competition.

• Statistic (NIST FIPS 204, 13 August 2024): a total of 82 candidate algorithms were submitted to NIST for consideration in the post-quantum standardization process.
• Statistic (NIST, 13 August 2024): FIPS 204 was published and took effect on 13 August 2024.

NIST states that ML-DSA can be used in place of other digital signature schemes specified in NIST FIPS and Special Publications (e.g., FIPS 186-5). For IKEv2, the IETF is standardizing this on top of RFC 7427: the working draft specifies that both the initiator and responder MUST send the SIGNATURE_HASH_ALGORITHMS notify payload in the IKE_SA_INIT exchange to signal their supported algorithms.

Plan for larger handshakes

• Statistic (NIST FIPS 204, Table 2, 2024): an ML-DSA-44 public key is 1312 bytes and a signature 2420 bytes. An ML-DSA-87 signature is 4627 bytes.

A certificate chain carrying these sizes can push IKE_AUTH messages past typical path MTUs, so make sure IKEv2 fragmentation works across your WAN, cellular and satellite links before you migrate. OT networks with small MTUs or strict firewall rules on UDP fragments deserve particular attention.

A practical sequence

1. Inventory the trust chain. List every CA, certificate profile and validity period used for tunnels between sites, to the cloud and for remote users, and note which devices hold fixed trust anchors.
2. Fix confidentiality first. Deploy hybrid ML-KEM key exchange, or RFC 8784 PPKs where peers cannot yet do that.
3. Stand up a post-quantum CA in parallel. Issue ML-DSA (or hybrid) certificates alongside the existing RSA/ECDSA hierarchy rather than replacing it outright.
4. Make procurement criteria explicit. Any device expected to run past 2030 should support ML-DSA authentication or be field-upgradable to it. This follows CISA’s advice on ensuring crypto-agility in applications and protocols.
5. Shorten classical certificate validity. Until migration is complete, avoid issuing RSA or ECDSA certificates that run past the NIST deprecation date.