Harvest now decrypt later: is OT traffic at risk?

Harvest now decrypt later (HNDL) is a strategy in which an adversary records encrypted network traffic today and stores it until a cryptographically relevant quantum computer (CRQC) can break the public-key cryptography that protected it. The data becomes readable after the fact, so the risk depends on how long it must stay secret, not on the date quantum computers arrive.

For organisations running operational technology (OT) and critical infrastructure, this changes the planning question. The issue is not whether a quantum computer exists today. It is whether the traffic crossing your links between substations, plants, control centres, cloud environments and remote engineers will still matter when one does. CISA, NSA and NIST urge all organizations, especially those that support critical infrastructure, to begin early planning for migration to post-quantum cryptographic (PQC) standards.

What is a harvest now decrypt later attack?

A harvest now decrypt later attack separates collection from decryption: the traffic is captured and archived now, and decrypted years later once quantum hardware can break the key exchange. Because the capture is passive, the organisation that owns the data usually has no way of knowing it happened.

The joint US factsheet describes the motive directly: cyber threat actors could be targeting data today that would still require protection in the future (or in other words, has a long secrecy lifetime), using a catch now, break later or harvest now, decrypt later operation.

Why the key exchange is the weak point

Most encrypted tunnels work in two steps. A public-key handshake (RSA or elliptic-curve Diffie-Hellman) agrees on a session key, and a symmetric cipher then encrypts the payload with that key. Someone who records the whole session, including the handshake, only has to break the handshake later to get the session key, and with it every packet in the session. That is why HNDL is mainly a key-exchange problem, not a bulk-cipher problem.

Which encryption algorithms are vulnerable to quantum computing?

All widely deployed public-key algorithms based on factoring or discrete logarithms are vulnerable to Shor’s algorithm. Symmetric ciphers and hash functions are only weakened by Grover’s algorithm, and adequate key sizes compensate for that.

NIST’s teaching material puts the two algorithms side by side: Shor’s algorithm (1994) gives an exponential speed-up over classical computers for factoring large integers and finding discrete logarithms, while with Grover’s algorithm (1996) symmetric-key crypto such as AES and SHA would also be affected, but less dramatically. In its transition plan, NIST identifies as vulnerable RSA, (EC) Diffie-Hellman, MQV, ECDSA and EdDSA, and as post-quantum ML-KEM, ML-DSA, SLH-DSA, LMS and XMSS.

On symmetric cryptography, NIST states that NIST-approved symmetric primitives providing at least 128 bits of classical security continue to be approved. For public-key algorithms, NIST IR 8547 proposes a fixed timeline:

• NIST IR 8547 (November 2024): quantum-vulnerable algorithms at 112-bit security strength are deprecated after 2030, disallowed after 2035.

Hybrid schemes give a practical way through the transition. According to an IETF draft summarising the NIST guidance, 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.

When will quantum computers break RSA encryption?

Nobody can give a date, but the estimated hardware needed to break RSA-2048 has fallen sharply, and expert surveys put a meaningful probability on it happening within 15 years. The honest answer is a range of probabilities, and that range is what risk planning should use.

Published resource estimates show the trend:

• 2019 to 2021 (Gidney and Ekerå): RSA-2048 could be factored in about 8 hours using 20 million noisy qubits.
• 2025 (Gidney): the expected number of qubits needed to break RSA2048 was reduced from 20 million to 1 million.
• 2024 expert survey (Mosca and Piani, via the OECD): approximately two-thirds estimated a 50% or greater likelihood of the arrival of a cryptographically relevant quantum computer within the next 15 years, out of 32 experts surveyed.

Gidney himself does not claim that a CRQC is imminent. He backs NIST’s 2030 and 2035 dates for a different reason: “I prefer security to not be contingent on progress being slow.” For infrastructure operators, that is the useful framing. A plan that only works if quantum hardware progresses slowly is a gamble, not a plan.

Government deadlines follow the same reasoning. NSM-10 aims to mitigate as much quantum risk as feasible by 2035, and NSA expects the transition to QR algorithms for NSS to be complete by 2035 in line with NSM-10. In Europe and the UK, the European Union’s roadmap sets end-2030 for high-risk use cases and end-2035 for the remainder so far as practicable, and the United Kingdom NCSC sets milestones at 2028, 2031, and 2035.

How long does critical infrastructure data need to stay confidential?

Often longer than the time left before a CRQC might exist. Mosca’s theorem turns that comparison into a test you can apply link by link. If the years your data must stay secret plus the years your migration will take add up to more than the years until a CRQC, that data is already exposed to harvesting.

The IETF describes the model plainly: “x” denotes the time that our systems and data need to remain secure, “y” the number of years to fully migrate to a PQC infrastructure and “z” the time until a CRQC that can break current cryptography is available. The y term is the one organisations tend to underestimate. NIST notes that past cryptographic migrations have taken over a decade, and this more complex migration will likely take at least that long.

• Migration duration (NIST IR 8547, 2024): past cryptographic migrations took more than a decade.
• Migration cost (CRA Quadrennial Paper, 2025): the authors cite the U.S. government’s estimated $7.1 billion transition cost for non-National Security Systems alone.

In OT, x is driven less by records-retention rules and more by how long the information stays useful to an adversary. That usually tracks the service life of the physical plant, which explains why the US Department of Energy, commenting on NIST guidance, flagged its ability to protect long-lived assets such as SCADA/ICS, generation plants, and nuclear material archives.

Is OT network traffic at risk from quantum computers?

Yes, wherever OT traffic leaves a trusted segment inside a tunnel protected by quantum-vulnerable key exchange. Plaintext industrial protocols are already readable without any quantum computer. The HNDL exposure sits in the encrypted conduits that carry OT data across public or shared networks.

Three paths deserve attention first:

• Site to site: links between control centres, substations, pumping stations or plants, often over carrier networks or the public internet.
• Edge to cloud: historian replication, analytics and backups sent to a data centre or cloud environment.
• Remote access: engineers and vendors connecting from laptops, a session that may carry credentials and configuration changes.

OT adds constraints that general IT migration advice tends to skip. You usually cannot install new cryptographic software on PLCs, RTUs or protection relays. Equipment lifecycles are long, so field devices that support ML-KEM natively may not show up for years. Control traffic is sensitive to latency, and change windows are rare. That makes the network layer the practical place to protect traffic in transit: you upgrade the cryptography at the ends of each conduit and leave the field devices alone.

What should OT and critical infrastructure operators do now?

Inventory your conduits, rank them by secrecy lifetime, and move key exchange on the highest-ranked links to hybrid post-quantum cryptography, keeping crypto agility for later algorithm changes. CISA, NSA, and NIST urge organizations to begin preparing now by creating quantum-readiness roadmaps, conducting inventories, applying risk assessments and analysis, and engaging vendors.

Inventory links, not just devices

A full cryptographic inventory of every OT asset is slow. For HNDL, the faster win is a list of every path where OT data crosses an untrusted network: the tunnel endpoints, the key-exchange algorithm in use, and the data categories carried. That list covers most of the exposure.

Score each link with Mosca’s theorem

Give each link an x value based on the data table above, and a y value based on realistic change windows and procurement cycles. Links where x plus y clearly exceeds plausible values of z go first, whatever their bandwidth.

Use hybrid key exchange and plan for agility

Combining a classical exchange with ML-KEM protects you if either component turns out to be weaker than expected. Make sure the algorithm can be changed later without new hardware, because NIST selected the Falcon digital signature algorithm and HQC key encapsulation mechanism for ongoing standardization, and recommendations will keep changing. As one example of this pattern at the network layer, Quantum Network’s QPN gateway sits at each end of a link, combines a classical and an ML-KEM key agreement into one session key, renews both handshakes every two minutes, and needs no software on the equipment behind it.

Keep inspection where you need it

Decide per path whether the existing firewall still has to inspect traffic. If it does, the quantum-safe encryption must end before traffic reaches the firewall, not after it. Test latency on control paths before cutover, and confirm that a link failure never falls back to unencrypted transmission.

CISA’s then-Director Jen Easterly summed up the urgency when the factsheet was released: “It is imperative for all organizations, especially critical infrastructure, to begin preparing now for migration to post-quantum cryptography”. For OT operators, the first step that produces results is to protect the links whose data will still matter in 2035 and beyond.