What Are the Best Solutions to Prevent Harvest Now, Decrypt Later Attacks on Fiber Networks?
Harvest now, decrypt later (HNDL) attacks record encrypted traffic from wide area network (WAN) fiber today and decrypt it once its key exchange can be broken. MACsec, IPsec, and optical Layer 1 encryption make intercepted traffic unreadable, but a fiber tap still records the full ciphertext. Post-quantum cryptography and quantum key distribution protect the key exchange, and the encrypted payload stays recordable under both. Photonic Layer Security, the approach behind our Carmel platform, breaks down the transmitted optical signal so a tap captures nothing it can decrypt later.
The best protection against HNDL attacks on fiber networks pairs post-quantum cryptography for the key exchange with a physical-layer control that stops the transmitted signal from being harvested. Encryption makes intercepted traffic unreadable today, and post-quantum key exchange makes it harder to open later. Neither stops an attacker from harvesting a copy.
The HNDL attack
An HNDL attack captures traffic now and breaks the key exchange later. The attacker records the encrypted payload plus the handshake where both ends agreed on a session key, usually through RSA or elliptic-curve Diffie-Hellman (ECDH). A future quantum computer is expected to break that handshake and recover the key. This broken handshake matters because the attacker has been able to extract a copy.
That copy has been exfiltrated from WAN fiber, the long-haul links between sites that run over infrastructure an organization does not fully control. Attackers bend these cables past a radius of roughly 6.5 to 7.5 centimeters so light leaks into a clip-on coupler, with no outage and no alert..
Can Fiber Optic Cables Be Tapped, and How Do Enterprises Detect It? Learn where standard tap detection falls short.
Five defences, layer by layer
MACsec and IPsec come built into most routers and switches, encrypting traffic at Layer 2 and the IP layer. They stop anyone from reading any exfiltrated data in real time. The output is still ciphertext, and a tap copies it bit for bit.
Optical Layer 1 encryption moves that protection down to the wavelength. The encryptor sits at the transponder and encrypts all traffic on the wavelength at once, whatever the protocol, with very little added latency. The keys behind that encryption are still set up through a key exchange, so the handshake weakness remains until that exchange moves to PQC or QKD. Either way, the signal leaving the transponder is still an encrypted waveform a tap can record.
Post-quantum cryptography (PQC) replaces RSA and ECDH with quantum-resistant algorithms, led by ML-KEM, published by NIST as FIPS 203 in August 2024. Rolled out through software updates, it closes the key-exchange weakness for subsequent sessions. However, the payload those sessions send stay as recordable as before.
Quantum key distribution (QKD) uses single photons to share keys, so an eavesdropper on the key channel can be detected. The NSA does not recommend QKD for national security systems, citing its special-purpose equipment and trusted relay stations. Data encrypted with a QKD key still crosses the fiber as ordinary ciphertext.
Photonic Layer Security (PLS) is a category of Layer 1 protection that secures the transmitted optical signal itself. A PLS system spreads the signal across a wide spectral band, applies a continuously changing optical key, and submerges it below the fiber's background noise, transforming the data into optical noise. An attempted tap captures no identifiable signal, so a future key-exchange break has nothing to open.
What each defence leaves exposed
A PQC migration is necessary, but the traffic sent while it is underway, remains open to exposure. Executive Order 14412 sets December 31, 2030 for post-quantum key establishment on high-value US federal systems and covered contractors, leaving four more years of traffic under retiring algorithms. The Global Risk Institute's 2025 Quantum Threat Timeline Report puts the odds of a quantum computer able to break today's key exchange within ten years at 28 to 49 percent. Anything harvested before the migration ends remains vulnerable to exposure.
Algorithm strength is also not a fixed target once data is captured. Shor's algorithm is the clear precedent: a handshake that held for decades becomes breakable once the right quantum technique matures, which is exactly why the PQC migration exists in the first place. Classical cryptanalysis keeps advancing too, with AI-assisted research now part of that progress. Although no published result has been shown to successfully break the widely commercially used AES-256, attempts that have broken reduced-round versions of AES-128 are expected to weaken the full AES-256.
Read to find out how a post-quantum rollout for data in transit works.
Carmel against other HNDL defences
We built Carmel as a PLS platform that installs as a matched pair of units, one at each end of a link, alongside existing DWDM (dense wavelength division multiplexing) equipment. It reaches 100 kilometers unamplified and works with standard EDFA and Raman amplifiers to reach distances beyond that.
| Defense | What it protects | Can a tap record ciphertext? | Deployment | Why it matters for HNDL |
|---|---|---|---|---|
| MACsec / IPsec | Payload at Layer 2 or IP layer | Yes | Built into routers and switches | Stops live reading; copy stays a target |
| Optical Layer 1 encryption | Full wavelength | Yes | Encryption-capable transponders | High capacity; recorded waveform stays a target |
| PQC (e.g. ML-KEM) | Key exchange | Yes | Software; multi-year migration | Mandated for US federal systems by EO 14412; cannot protect past recordings |
| QKD | Key distribution | Yes | Dedicated hardware and fiber | Detects key eavesdropping; payload stays recordable |
| PLS (Carmel) | Transmitted optical signal | No; a tap captures optical noise | Matched pair of units; about four weeks | Removes the recording HNDL depends on; complements PQC |
Matching the defence to the data's lifespan
The right combination depends on how long the data on each WAN link must stay confidential. Short-lived traffic is well served by MACsec or Layer 1 encryption plus a PQC migration on schedule. Intellectual property, government contracts, and medical records, whose data sensitivity outlives the migration window, need protection against advancing quantum decryption capabilities. On those links, we run Carmel on the same fiber as the payload. With no downtime required, critical traffic can be sent over the cable, after its security validation is demonstrated.
Have WAN links carrying data that must stay confidential for a decade? Visit CyberRidge to see how Carmel fits alongside your post-quantum migration.
FAQs
Q: Does post-quantum cryptography stop harvest now, decrypt later attacks?
A: Only partly. PQC protects the key exchange for future sessions, but it does not stop a fiber tap from recording the encrypted payload, and traffic recorded before a migration finishes stays exposed. Carmel adds protection at the optical layer so the payload cannot be recorded in the first place.
Q: Is Layer 1 optical encryption enough to protect fiber from HNDL?
A: No. Layer 1 encryptors apply AES-256 to the digital payload riding on the wavelength, but the result is still ciphertext that a tap can copy and store. Carmel buries the signal below the fiber's noise, so a tap has no usable waveform that it can record.
Q: How is Carmel different from quantum key distribution?
A: QKD protects how keys are shared, and Carmel protects the transmitted signal itself. QKD needs dedicated hardware and fiber and reaches around 100 kilometers in practice. Carmel works alongside existing DWDM equipment, supports up to 100 kilometers unamplified, and extends further with standard EDFA and Raman amplifiers.
Q: Does Carmel replace PQC or MACsec?
A: No. Carmel works beneath the cryptography a network already runs. PQC still handles the key exchange, signatures, and authentication, and MACsec or IPsec can keep running over a Carmel-protected link.
Q: How long does it take to deploy Carmel on an existing fiber network?
A: Our standard rollout takes about four weeks in phases. Carmel first runs in parallel with existing traffic with no downtime, then carries non-critical traffic during validation, and finally carries all critical traffic on the protected links.
Q: Can Carmel protect long-haul fiber that uses optical amplifiers?
A: Yes. Carmel supports up to 100 kilometers without amplification and is compatible with EDFA and Raman amplification for longer spans. It also shares the fiber with other wavelengths, so the whole link does not need to carry Carmel traffic.
Q: Does Carmel protect LAN or Wi-Fi traffic?
A: No. Carmel protects data in transit on WAN fiber, the long-haul carrier fiber between sites, cities, and data centers. Traffic inside a building or between personal devices does not cross the exposed fiber spans where it would be vulnerable to HNDL attacks.