Where are harvest now decrypt later interception points?

Harvest now decrypt later interception points are the places in a network where someone can copy encrypted traffic in bulk today, store it, and try to decrypt it once a cryptographically relevant quantum computer exists. For OT and critical infrastructure operators, most of these points lie outside the perimeter: carrier backbones, internet transit, cloud on-ramps and remote-access paths.

The threat model is simple. NIST describes it as one in which adversaries collect encrypted data now with the goal of decrypting it once quantum technology matures. Collection needs no cryptanalysis at all. It only needs a position on the path and storage. This article maps where that position is easiest to get, what you can and cannot detect, and which links in a typical utility, water, energy or manufacturing network to fix first.

Where do attackers capture encrypted traffic for harvest now, decrypt later attacks?

Mostly on infrastructure you do not operate: provider routers, internet exchange and transit paths, and cloud networking layers. Your own switches and firewalls are a second, smaller category.

Carrier and provider equipment

Every packet on a WAN passes through provider edge and core routers. A compromised or coerced router can mirror traffic without touching the endpoints. CISA’s joint advisory AA25-239A, which maps activity to both MITRE ATT&CK for Enterprise and MITRE ATT&CK for ICS, lists configuring PCAP capabilities to collect network traffic on network devices among the techniques it describes. For an operator, the point is structural: the carrier’s equipment is an interception point you cannot harden yourself.

Internet transit and routing

Site-to-site VPNs over the public internet cross several autonomous systems. Anyone who can influence routing can pull traffic through a network where it is easy to copy (covered in the BGP section below).

Cloud virtual networks

Edge-to-cloud links end in virtual networks that have built-in copy functions. MITRE ATT&CK T1040 (Network Sniffing) notes that in cloud-based environments, adversaries may still be able to use traffic mirroring services to sniff network traffic from virtual machines. A stolen cloud administrator credential is therefore enough to create a capture point, with no physical access at all.

Inside your own network

T1040 also covers local capture: an adversary may place a network interface into promiscuous mode to passively access data in transit over the network, or use span ports to capture a larger amount of data. ATT&CK for ICS has a matching Network Sniffing technique for control environments. Inside the plant, capture usually aims at cleartext industrial protocols. For harvest now, decrypt later, the internal concern is the encrypted tunnels that start or end there.

Do BGP hijacks and carrier network compromises enable harvest now, decrypt later?

Yes. Both give an adversary a copy of your encrypted packets, and that is all harvest now, decrypt later needs. Neither has to break the encryption for the collection to have value later.

CISA warns that an adversary may deliberately falsify BGP reachability information to redirect traffic, and state-level actors have been suspected over the years of exploiting BGP’s vulnerability to hijacking. NIST SP 1800-14 lists among the effects of route hijacks the ability to detour internet traffic to permit eavesdropping and to facilitate on-path attacks on endpoints. A short, well-timed detour can capture a VPN handshake plus the session that follows, then forward the packets onward so connectivity never visibly breaks.

Carrier compromise is the quieter version of the same problem. No routing anomaly shows up in public data because the traffic never leaves its normal path; it is simply copied along the way. The mitigations in AA25-239A, such as strict prefix filtering and session protection (TCP-AO where supported, otherwise MD5) on eBGP, are carrier-side controls. As a customer you can ask for them in contracts, but you cannot verify them continuously.

Which links in a critical infrastructure network are most exposed to bulk traffic capture?

The links with the most exposure combine three things: they cross third-party infrastructure, they carry data that stays sensitive for years, and they use classical key exchange. In most OT estates, that means control-centre WAN links, vendor remote access and cloud interconnects.

The data-lifetime question decides priority. A pressure reading is stale in seconds. A substation’s IP plan, firewall rules or relay settings may stay valid for a decade, because OT assets stay in service far longer than IT assets. NIST’s migration guidance notes that some components are expected to remain in place for a decade or more (e.g., components in electricity generation and distribution systems).

Does encrypting traffic over private MPLS or leased lines protect it from harvest now, decrypt later?

Only if the key exchange is quantum-resistant. MPLS on its own provides separation, not encryption, and classical IPsec over MPLS gives an adversary exactly the recorded handshake that a future quantum computer could unlock.

Two misconceptions are common in OT networks:

• “MPLS is private, so it is not interceptable.” MPLS labels keep customers’ traffic apart logically on shared provider equipment. The packets still pass through the carrier’s routers unencrypted unless you encrypt them yourself. Leased lines and dedicated wavelengths run through exchanges, cross-connects and amplifier sites operated by others.
• “We already run IPsec over MPLS, so we are covered.” The symmetric cipher protecting the payload is not the weak point. The vulnerable part is the public-key exchange (RSA or elliptic-curve Diffie-Hellman) that creates the session key. NIST says it expects to prioritize the migration to quantum-resistant key-establishment schemes within these updates to protect against “harvest now, decrypt later” attacks, particularly in interactive protocols like TLS and IKE.

So the useful question for any private circuit is not whether it is private, but what the key exchange on top of it is.

Can you detect if your encrypted VPN traffic is being collected for later decryption?

Mostly not. Passive copying leaves no trace at the endpoints, so detection is limited to indirect signals and to capture capabilities on equipment you control.

What you can realistically monitor:

• Routing anomalies: unexpected origin changes or more-specific announcements for your prefixes in public route collectors, and sudden changes in traceroute paths or latency between sites. These can point to a detour, though many have harmless causes.
• Capture configuration on your own devices: new span or mirror sessions, packet-capture features turned on, or configuration changes on routers and firewalls from unexpected management sources. These map directly to T1040.
• Cloud control-plane activity: creation of traffic-mirroring sessions or new mirror targets in your cloud audit logs.
• Remote-access anomalies: sessions from unusual locations or devices, which may mean credentials taken from earlier captured traffic are being reused.

What you cannot see: an optical tap at a carrier facility, mirroring on a provider core router, or a copy made at a transit network that forwards traffic normally. That limit is why CISA, NSA and NIST frame the response as preparation rather than detection, warning that cyber threat actors could be targeting data today that would still require protection in the future.

How do you protect site, cloud and remote-access links against harvest now, decrypt later?

Inventory the links that leave your premises, rank them by how long their data stays sensitive, and move the highest-ranked ones to hybrid post-quantum key exchange without waiting for every endpoint to support it.

Know the deadlines regulators are working to

• NIST IR 8547 (initial public draft, November 2024): quantum-vulnerable algorithms at 112-bit security are deprecated after 2030, disallowed after 2035.
• EU Coordinated Implementation Roadmap (June 2025): All Member States should start transitioning to PQC by the end of 2026. At the same time, the protection of high-risk use cases should be transitioned to PQC as soon as possible, no later than by the end of 2030.
• UK NCSC: its migration timeline sets milestones at 2028, 2031, and 2035.
• Quantum timeline uncertainty (NIST NCCoE): some believe that CRQCs may emerge by 2030, while many anticipate they could become feasible within 15 to 20 years.

For harvest now, decrypt later, the deadline that counts is earlier than any of these dates. Data recorded today stays exposed for as long as it remains sensitive.

Use hybrid key exchange built on the published standards

The algorithms now exist: in August 2024, NIST released three PQC standards (as Federal Information Processing Standards, or FIPS), including ML-KEM in FIPS 203 for key establishment. The UK NCSC only endorses NIST standards and suggests the use of hybrid schemes for additional security and retro-compatibility during migration, while noting that systems should be able to move to standalone post-quantum cryptography later. In practice, that means combining a classical and a post-quantum exchange and keeping the ability to swap algorithms.

Protect the path when the endpoints cannot change

Many PLCs, RTUs and HMIs will never get post-quantum cryptography in firmware. The workable alternative is to encrypt at the network boundary of each site so that the exposed carrier, internet or cloud segment only ever carries quantum-resistant tunnels. Quantum Network’s QPN is one example of this pattern: a gateway at each end of a link combines a classical and an ML-KEM key agreement into one session key and encrypts at Layer 3, so no software has to be installed on the equipment behind it. Gateways like this protect data in transit only. They do not replace the central firewall or protect the devices themselves.

Prioritise in this order

1. Links that carry engineering, configuration and credential traffic across carrier WANs.
2. Vendor and staff remote access into OT zones.
3. Internet-based site-to-site VPNs.
4. Edge-to-cloud flows carrying historian data and asset inventories.

This order follows the CISA, NSA and NIST advice to begin preparing now by creating quantum-readiness roadmaps, conducting inventories, applying risk assessments and analysis, and engaging vendors. The inventory of interception points described above is the most concrete input that roadmap can have.