Harvest now decrypt later VPN credentials: are they at risk?

Harvest now, decrypt later (HNDL) against VPN credentials means recording encrypted remote access or site-to-site traffic today and decrypting it once a cryptanalytically relevant quantum computer (CRQC) can break the classical key exchange. Anything inside those tunnels then becomes readable: passwords, password hashes, session tokens and OT configuration data. For operators of industrial control systems, the question is not only what leaks, but which of those secrets will still work years from now.

This article looks at what actually travels inside OT tunnels and how long each secret stays useful. It then covers how rotation and MFA change the risk, and which connections should move to hybrid ML-KEM key exchange first.

Can decrypting recorded VPN traffic later reveal passwords and session tokens?

Yes. If the tunnel’s session keys were set up with classical RSA or (EC)Diffie-Hellman, someone who recorded the handshake and the encrypted payload can recover the session keys with a CRQC and read everything the tunnel carried, credentials included.

The mechanics are simple. In IKEv2 and TLS-based VPNs, both peers derive symmetric keys from a public-key exchange. The symmetric cipher (AES or ChaCha20) is not the weak point. The key exchange is. NIST IR 8547 lists RSA, (EC) Diffie-Hellman, MQV, ECDSA and EdDSA as quantum-vulnerable, and ML-KEM, ML-DSA, SLH-DSA, LMS and XMSS as post-quantum standards. Solve the recorded Diffie-Hellman exchange and the rest of the key schedule follows.

Perfect forward secrecy does not help here. It limits damage when a long-term key is stolen, but a CRQC can attack each ephemeral exchange separately. Every recorded session is its own target.

What becomes readable depends on what ran inside the tunnel:

• Cleartext inner protocols: Telnet, FTP, HTTP management pages on older HMIs, SNMPv1/v2c community strings and Modbus/TCP. Credentials appear directly.
• Challenge-response protocols: NTLM exchanges and EAP-MSCHAPv2 inside IKEv2 expose material that can be cracked offline to recover the underlying password.
• Session artefacts: cookies, bearer tokens and Kerberos tickets. These are readable, but they usually expire long before decryption is possible.
• Nested encryption: RDP or SSH inside the VPN adds a layer. If that inner layer also uses classical key exchange, it can be attacked the same way, so nesting delays exposure rather than preventing it.

Which OT credentials and configuration data travel inside remote access and site-to-site tunnels?

OT tunnels carry an unusually dense mix of long-lived secrets: engineering workstation logins, PLC and safety controller passwords, service accounts for historians and SCADA servers, and complete device configurations. Much of this traffic uses legacy protocols with weak or no session-level encryption of its own.

A typical engineering session over remote access might include a domain login to a jump host, a vendor engineering tool connecting to a controller with a project password, and a download of the controller program. Site-to-site links between a control centre and substations or pumping stations often carry SCADA polling, Active Directory replication, historian synchronisation and configuration backups.

The CISA Post-Quantum Considerations for Operational Technology paper describes this exposure directly. OT may be vulnerable due to connectivity or association with IT platforms as well as direct or indirect dependencies on public-key cryptographic features including encryption and decryption, signing and validation schemas, and identity and access management mechanisms.

Does harvest now, decrypt later only threaten confidentiality, or also future access to OT systems?

It threatens both. HNDL is usually framed as a confidentiality problem, but in OT the decrypted content often includes credentials and architecture details that can still grant access when decryption becomes possible.

CISA’s OT paper states that cyber intrusions and compromises leveraging future quantum computing capabilities may threaten data confidentiality and integrity or undermine important access controls dependent on public-key cryptography. The President’s NSTAC goes further and warns that CRQCs could jeopardize civilian and military communications, undermine supervisory and control systems for critical infrastructure.

Long asset lifecycles make the access risk worse. A controller commissioned today may still run with the same project password and network addressing well into the 2040s. A recording made this year therefore does not just describe the past. It may also hold a working key to equipment that is still in service.

The CISA, NSA and NIST factsheet on quantum readiness asks organizations to build cryptographic inventories that inform future analysis by identifying what data may be targeted now and decrypted when a CRQC is available. For OT, that inventory should list the credentials each tunnel carries, not only the algorithms it uses.

How do credential rotation and MFA limit the damage from retroactively decrypted sessions?

Short-lived tokens and one-time MFA codes lose their value long before a recording can be decrypted, so MFA effectively protects the login step. Rotation protects the static secrets that MFA does not cover, but only if it reaches the OT accounts and device passwords that usually never change.

What MFA does and does not cover

A TOTP code or push approval captured in 2026 is useless in 2035. MFA on the VPN gateway and the jump host therefore removes the most obvious way to reuse harvested credentials: logging in again through the same front door. There are three gaps:

• The static password still leaks, which turns MFA into single-factor protection if the second factor is ever weakened or bypassed by an exception.
• Credentials used after the MFA step, such as engineering tool passwords, controller passwords and local admin accounts on HMIs, are rarely MFA-protected at all.
• MFA enrollment secrets (the seed behind a QR code) can travel through the tunnel during onboarding. Re-enrolling periodically limits this.

Making rotation fit OT reality

Rotation only helps if it reaches the accounts with the longest shelf life. IEC 62443-3-3 already frames the relevant requirements: human user identification and authentication (SR 1.1), authenticator management (SR 1.5), access via untrusted networks (SR 1.13) and communication confidentiality (SR 4.1). In practice, this means:

• Prioritise shared vendor accounts, service accounts for historians and SCADA, and device passwords that were set at commissioning.
• Rotate PLC and safety controller passwords during planned outages, and record that rotation in the change process so it actually happens.
• Replace SNMPv1/v2c with SNMPv3 where devices support it, and remove cleartext management protocols from remote access paths.
• Assume any credential that has crossed a classical tunnel is “pre-exposed”. Rotate it before it outlives the expected CRQC window.

Rotation and MFA reduce the value of what has already been recorded. They do nothing to stop new recordings. That requires changing the key exchange.

How much time do OT operators have before harvested traffic becomes readable?

Nobody knows exactly. Public estimates put a CRQC somewhere between the late 2020s and the early 2040s, and US federal policy targets 2035 for completing the migration. Because OT assets and credentials outlive those dates, traffic recorded now falls inside the window.

2026 to 2041: estimates for a CRQC large enough to decrypt currently encrypted information range from 2026 to 2041, with 2030 to 2035 being estimated as an inflection point (CISA, Compendium of CISA Technology Investigations, December 2023).

2035: NSM-10, issued on 4 May 2022, directs the United States to prioritise the transition “with the goal of mitigating as much of the quantum risk as is feasible by 2035.”

2030 and 2035: under NIST IR 8547, quantum-vulnerable algorithms at 112-bit security strength are deprecated after 2030, disallowed after 2035 (initial public draft, November 2024). NIST adds that high-risk systems should transition much earlier than 2035.

August 2024: FIPS 203 was published on August 13, 2024, and specifies three parameter sets for ML-KEM: ML-KEM-512, ML-KEM-768, and ML-KEM-1024.

Mona Harrington, then acting Assistant Director of CISA’s National Risk Management Center, put it plainly: “Critical infrastructure and government leaders must be proactive and begin preparing for the transition to post-quantum cryptography now.”

Which remote access connections should move to hybrid ML-KEM first to protect credentials?

Start with connections that cross untrusted networks and carry privileged, long-lived OT credentials: third-party vendor access, internal engineering remote access, and site-to-site links over the public internet that carry control traffic or directory replication. Hybrid key exchange keeps classical security in place while adding ML-KEM.

Why hybrid rather than pure post-quantum

In a hybrid scheme, a classical exchange and ML-KEM each contribute to one session key. The result is intended to be secure as long as at least one of the component algorithms is secure, and NIST IR 8547 states that such hybrid approaches may be used in the initial transition to PQC. For OT owners who are wary of new algorithms on operational paths, hybrid removes the “what if ML-KEM has a flaw” objection without leaving recorded traffic exposed.

A practical priority order

Two selection criteria matter more than bandwidth: the shelf life of the credentials on the path, and whether the path crosses infrastructure you do not control. A low-bandwidth vendor session that carries a safety controller password ranks above a busy telemetry link.

Deployment considerations for OT paths

The CISA OT paper recommends minimizing OT exposure to quantum threats via strong OT network segmentation, using quantum-resistant algorithms where appropriate, ensuring crypto-agility in applications and protocols. For tunnels, that translates into a few practical checks:

• Layer and placement: encryption at Layer 3 covers every protocol above it, including legacy industrial protocols that cannot be upgraded. Decide whether existing firewalls must still inspect the traffic, because that determines whether the quantum-safe gateway sits in front of the firewall or behind it.
• No silent downgrade: the tunnel should never fall back to unencrypted or classical-only operation after a link failure.
• Key renewal: frequent rekeying limits how much traffic any single session key protects.
• Algorithm agility: make sure the post-quantum algorithm can be replaced without redesigning the network.
• Endpoint footprint: avoid installing software on controllers, HMIs or other assets behind the tunnel.

As one example of how this looks in practice, Quantum Network’s Quantum Gateway encrypts at Layer 3 and combines a classical and an ML-KEM exchange into one session key, with both handshakes renewed every two minutes. It never falls back to unencrypted traffic, and its Windows and macOS remote access client needs no incoming firewall ports. A gateway like this protects data in transit. It does not replace segmentation, a central firewall, or the credential hygiene described above.