You Cannot Detect Harvest Now, Decrypt Later (HNDL)

Introduction

After I published Is Harvest Now, Decrypt Later Real?, the responses split into two camps. One group said the article had given them the answer they needed for their board. The other group said their board wanted something more: proof that their organization was being targeted.

Several told me their security teams had been instructed to deploy controls that could detect HNDL. One mentioned a consultant who had proposed an “HNDL detection capability.” Another forwarded a vendor white paper claiming that network flow telemetry could catch HNDL operations “while they are happening.”

I understand the impulse. Executives trained on conventional cyber risk want a detection-and-response story. A threat exists, therefore we should be able to see it, measure it, and build a dashboard around it. That model works for most of the adversary behavior a security team encounters. It does not work here, and the reasons are not about tooling gaps or budget. They are about physics.

Harvest Now, Decrypt Later in its most concerning form is passive collection: copying encrypted traffic from a fiber, a radio link, or a satellite downlink without transmitting anything, without touching the victim’s systems, and without altering the traffic in any way. A passive collector generates no event inside your observable boundary. There is no packet to inspect, no connection to log, no anomaly to alert on, and no behavioral signature to train a model against. Your IDS, your EDR, your SIEM, your NDR, and your ML pipeline all operate inside a boundary the collection never crosses.

The defense against HNDL is not detection. It is encryption, and specifically migration to post-quantum key establishment that ensures the ciphertext an adversary copies today remains unreadable regardless of what machines exist in 2035.

Anyone selling you a technical control to detect passive HNDL collection is selling something that cannot exist. This article explains why, carefully, so you can explain it to your board.

What HNDL Detection Would Actually Require

To detect that your organization is the target of an HNDL operation, you would need to confirm two things: that your encrypted traffic has been copied somewhere outside your control, and that the entity holding the copy intends to decrypt it with a future quantum computer.

Neither is technically achievable, for separate reasons.

The first fails because passive collection produces no observable event at the victim. The second fails because intent is invisible to any technical control. Even if you somehow knew a copy existed, no instrument can tell you why the adversary is keeping it. The storage array does not broadcast its owner’s strategic plan.

Break these apart, because they represent different kinds of impossibility, and conflating them is how vendors slip a product into the gap.

Passive Collection Produces No Signal Inside Your Network

Most people, including many security professionals, still picture data collection as something that requires interaction with the victim’s systems. An attacker breaks in, plants malware, exfiltrates files through a command-and-control channel, and the security team catches the outbound anomaly.

That mental model is correct for conventional breaches and active exfiltration. It has nothing to do with how the most concerning form of HNDL collection works.

How Your Data Actually Travels

Consider what happens when an employee sends an email, connects to a cloud application, or joins a video call. The data leaves the organization’s network as encrypted packets. Those packets cross infrastructure the organization does not own, cannot monitor, and in most cases cannot even identify: carrier backbone fiber, internet exchange points, submarine cables, satellite links, cloud provider internal networks, and content delivery nodes.

At every one of those transit points, the organization’s security tools have zero visibility. No firewall inspects the carrier’s fiber. No EDR agent runs on the internet exchange. No SIEM collects logs from the submarine cable landing station. The organization’s entire detection capability ends at its own network boundary.

A Copy of the Light

Now consider what an adversary does at one of those transit points. On fiber, a passive optical splitter or an evanescent bend coupler diverts a fraction of the light signal to a second path. The splitter is a physical-layer device. It does not generate packets, inject traffic, or modify the original signal in any protocol-visible way. The copied light travels to the adversary’s equipment; the original continues to its destination unchanged. Both endpoints complete the session normally. Neither knows a copy was made.

On radio (WiFi, cellular, satellite), the situation is even simpler. A receive-only antenna captures the electromagnetic signal that is already propagating through space. It emits nothing. A WiFi adapter in monitor mode captures 802.11 frames without associating with the access point and without transmitting. A passive cellular receiver captures the tower’s downlink without impersonating a cell and without the carrier or the target knowing. A satellite dish pointed at a geostationary transponder receives the same signal the transponder broadcasts to its entire footprint.

In the Don’t Look Up study published at ACM CCS 2025, researchers at UC San Diego and the University of Maryland intercepted traffic from 39 geostationary satellites using roughly $800 of consumer equipment on a rooftop. They captured cellular backhaul, corporate communications, military traffic, and law enforcement data. The victims had no idea until the researchers notified them. The collection was receive-only and left no trace.

Why Your Security Stack Cannot See It

The pattern should be clear now. The adversary’s collection point is outside the victim organization’s network. The collection method is passive. The collection leaves no protocol-level artifact at either endpoint. The security stack operates inside a boundary the collection never enters.

Every row in that table has the same answer, for the same reason: the collection event does not occur inside the organization’s observable boundary. There is nothing to detect because there is nothing happening on your side.

The Detection Boundary Problem

Even at the physical layer, where detection is theoretically possible, the entity that could detect a tap is the infrastructure owner, not the data owner.

A carrier or facility operator monitoring its own fiber with Optical Time-Domain Reflectometry (OTDR) or distributed acoustic sensing could, in principle, notice the insertion loss from a splitter or the physical disturbance of installing one. Commercial products for this exist (Network Integrity Systems, VIAVI, Fiber SenSys), designed for classified or high-security environments under standards like the U.S. government’s CNSSI 7003 for alarmed carrier and protected distribution systems.

But even this is harder than it sounds. A competent tap does not use a 50/50 splitter that introduces an obvious 3 dB loss. An evanescent or bend coupler can leak a readable signal while adding very little insertion loss. U.S. Patent 4,802,723 documents approximately 0.002 dB per tap in one experimental configuration; Patent Application US20060291795A1 cites losses of 0.004 to 0.04 dB for an evanescent-coupling method and argues that steady-state optical power monitoring cannot reliably distinguish them from background variation. Those figures are below the noise floor of standard OTDR and power-monitoring equipment and are indistinguishable from connector aging, temperature drift, or routine handling.

And here is the part that matters for the HNDL discussion: even if the carrier could detect a tap on its own fiber, the enterprise whose data rides that fiber cannot. The enterprise has no OTDR on the carrier’s backbone. It has no distributed acoustic sensors on the submarine cable. It has no physical-layer monitoring capability over any part of the transit path it does not own.

For the organization asking “can we detect whether our traffic is being harvested for HNDL?”, the answer does not depend on whether fiber tap detection is theoretically possible somewhere in the world. It depends on whether the organization has any visibility into the physical layer of the infrastructure its traffic traverses. It does not.

What the “HNDL Detection” Products Actually Detect

With that physics in mind, look at what vendors claiming “HNDL detection” are actually selling.

A vendor blog post titled “Detecting Harvest Now, Decrypt Later Threats with NetFlow” lays out its case clearly enough. The product monitors NetFlow telemetry (source, destination, protocol, byte count, duration) and flags anomalies: sustained bulk outbound transfers, off-hours exfiltration patterns, new or anomalous egress destinations, encrypted tunnels to unexpected endpoints, and low-and-slow incremental data movement.

That is a perfectly respectable description of network-based exfiltration detection. Security teams have been doing variants of it for 20 years. It catches an adversary who has breached your network, compromised an endpoint, and is copying data outbound through your infrastructure. It catches Salt Typhoon-style intrusions, insider threats, and malware with a data-theft component. Good NDR and DLP programs should already be doing this.

What it does not and cannot do is detect passive external collection. Every indicator the product monitors (outbound volume, destination IP, timing, flow metadata) describes activity originating inside the organization’s network. A passive fiber tap or RF receiver does not generate any of those indicators. The product is looking in the right direction for exfiltration and in the wrong direction entirely for HNDL.

Calling this “HNDL detection” is a category error. It is exfiltration detection rebranded with a quantum label.

The Machine-Learning Variant

A similar pattern appears in academic work proposing ML frameworks for “detecting HNDL adversary behaviour” through encrypted traffic behavioral analysis. One such paper, listed on ResearchGate with an August 2026 date, proposes training on flow metadata to identify anomalous traffic selection patterns. (As of this writing, the manuscript is not publicly accessible and has no independent DOI or peer-reviewed publication record, so its methodology cannot be fully assessed.) The models in this category train on traffic metadata (flow duration, packet sizes, inter-arrival times, session patterns) and look for anomalous behavior that might indicate an adversary is selecting and copying traffic.

The fundamental problem is unchanged. If the adversary is selecting and copying traffic from inside your network (an endpoint compromise, a rogue process, a supply-chain implant), the ML model is detecting exfiltration. That is useful, but it is not new and it is not HNDL-specific. If the adversary is collecting passively from outside your network, the model sees nothing, because the organization’s traffic patterns are identical whether or not a copy is being made at a point the model cannot observe.

The problem is not a shortage of training data or a need for better architecture. The victim-side feature vector is the same whether or not an off-path copy was made. A researcher could label sessions in a controlled experiment by operating a tap and recording which sessions were copied, but a classifier restricted to endpoint or flow features would receive identical inputs in both cases. There is no discriminating feature in the data available to the model. That is a measurement problem, and no amount of ML sophistication will produce a signal that the physics does not generate.

The Intent Gap: Even Breaches Cannot Confirm HNDL

Suppose your security team detects a genuine breach. An adversary compromised a server, exfiltrated 50 terabytes of encrypted backups and archived email, and your incident response team caught it. That is a data theft. Your existing controls worked, at least partially.

Can you now confirm that the adversary intends to store that data for future quantum decryption?

No.

The adversary’s intent is invisible to your security controls. The exfiltrated data sits on the adversary’s infrastructure, which you cannot observe. The adversary’s decision to retain it for 10 years rather than process it immediately is an operational choice made outside your reach. No network telemetry, no endpoint forensics, and no behavioral model deployed in your environment can tell you whether the stolen data will be processed next week with classical tools or stored for a decade and decrypted with a quantum computer.

Your board might ask: “Have we confirmed we are an HNDL target?” The honest answer, even after a confirmed breach, is: “We have confirmed a data theft. We cannot confirm the adversary’s timeline for exploiting it. We should assume the worst for data with long confidentiality requirements, because we have no way to confirm anything better.”

This is unsatisfying to executives who want binary answers. It is also the truth, and pretending otherwise creates a false sense of either alarm or comfort.

The Historical Record: No Passive Tap Has Ever Been Caught by Technical Means

The claim that passive collection is undetectable is not a theoretical position. The historical record offers a direct test: in every major documented case of passive communications interception, the operation was exposed by human beings, never by technical detection.

Operation Ivy Bells placed an induction tap on a Soviet undersea cable in the Sea of Okhotsk in the early 1970s. The Soviet Union guarded those waters as territorial and monitored the seabed with acoustic sensors. The tap ran for roughly a decade. It was exposed in 1980 when NSA analyst Ronald Pelton sold the program to the KGB. A human traitor, not a cable fault or a network alarm, revealed the collection.

Room 641A, the NSA’s passive optical splitter on AT&T’s San Francisco backbone, was exposed in 2006 when technician Mark Klein went public with schematics and photographs. In this case the carrier was not oblivious; AT&T personnel with NSA clearances installed and maintained the equipment. The infrastructure owner was cooperating. The organizations and individuals whose traffic was being copied had no indication at all. Klein’s disclosure was an act of conscience, not a detection event.

Tempora, GCHQ’s program to buffer traffic from transatlantic fiber-optic cables, followed a similar pattern. The Guardian’s reporting described secret cooperation from telecommunications companies. Again, the infrastructure operators were involved. The people and organizations whose communications were being buffered and searched never knew. Snowden’s disclosure in 2013 was another human revelation, not a technical detection.

These three cases span undersea cables, internet backbone fiber, and transatlantic links, across three decades and two different intelligence services. In every case, the operation was revealed by a person with insider access. In none was the collection discovered by the data owners, by their security tools, or by independent technical monitoring. The pattern tells you something about where the observability boundary sits.

What an Adversary Would Actually Need to Do to Be Caught

The distinction that matters is between active and passive collection, because active collection does generate detectable events:

Active IMSI catchers (cell-site simulators or Stingrays) transmit. They impersonate a cell tower, broadcast a stronger signal, and force phones to connect. That transmission is detectable through signal analysis, anomalous cell behavior, and tools like SnoopSnitch and the EFF’s Crocodile Hunter. DHS confirmed in 2018 that it had detected activity consistent with such devices around Washington. Active IMSI catchers can be caught because they emit energy. Passive cellular receivers, which only listen to the tower’s downlink, cannot. The EFF states plainly that “it is impossible for anyone to know if their phone’s signals have been accessed by a passive IMSI catcher.”

Network intrusions (like Salt Typhoon) are detectable because they involve unauthorized access to systems. The adversary logs in, moves laterally, accesses data, and maintains persistence. These activities generate log entries, authentication events, and behavioral anomalies. Investigators identified the Salt Typhoon compromises through evidence inside victim networks, which is categorically different from a receive-only collector operating outside the monitored environment.

Endpoint exfiltration (malware copying data outbound, insider threats, rogue processes) is detectable by DLP, EDR, and network monitoring because the exfiltration generates traffic from inside the organization’s boundary.

All of these are real threats. All of them are worth detecting. None of them is the passive external collection that defines the most concerning HNDL scenario. Confusing the detectable threats with the undetectable one is where the vendor pitch breaks down.

The One Genuine Edge Case: Local Oscillator Leakage

In the interest of technical completeness, there is one physical phenomenon where a “passive” receiver is not perfectly silent: local oscillator leakage.

A superheterodyne or direct-conversion receiver uses an internal oscillator to mix incoming signals down to a processable frequency. That oscillator can leak a tiny amount of RF energy back through the antenna. In the 1960s and 1970s, the UK used television detector vans that exploited this phenomenon to find unlicensed TV sets.

Researchers have demonstrated detection of receiver LO leakage in laboratory conditions. The University of Cantabria measured leakage from software-defined radios at roughly -96 dBm and detected it at distances of 10 to 50 centimeters. The Ghostbuster project (MobiCom 2018, UIUC) pushed the reliable detection range to about 5 meters using sophisticated MIMO cancellation techniques, with best-case maximum distances of 7 to 14 meters depending on the receiver type.

Those are laboratory distances. For backbone fiber taps (no RF involved at all), for satellite interception (kilometers of standoff), or for any collection position more than a few meters from a specialized detector, LO leakage is irrelevant. Modern software-defined radios can also be configured to suppress or whiten their oscillator signature, as demonstrated in the “Phantom Eavesdropping” paper (Shao et al., 2020). The old TV detector vans, whose later effectiveness was widely regarded as more deterrent than detection, were working against consumer receivers designed with no concern for emission security.

LO leakage is real physics. It is not a practical detection vector for any HNDL collection scenario worth worrying about.

What Your Board Actually Needs to Hear

If your board is asking “can we detect whether we are an HNDL target?”, the answer is:

No. There is no technical control that can detect passive collection of your traffic from infrastructure you do not own. There is no product that can confirm whether an adversary intends to store stolen data for future quantum decryption. Anyone claiming otherwise is either confused about the threat model or selling you something.

What your board should ask instead is a different question: “Does our organization handle information that must remain confidential for a decade or more? And if so, is that information still protected by key establishment that a future quantum computer could break?”

That question is answerable. It requires a cryptographic inventory, a data-lifetime assessment, and a migration plan, not a detection product. As I wrote in the previous article, the decision equation is:

Data confidentiality lifetime + migration lead time > plausible remaining lifetime of the current cryptography

If the answer is yes, you have work to do regardless of whether you can prove a specific adversary is targeting you. If the answer is no, HNDL is not your most pressing problem.

The defense against HNDL is not finding the collection. It is making the collection useless. Deploy ML-KEM (FIPS 203) or standards-conformant hybrid key establishment on your long-lived confidentiality flows. ML-KEM is believed to resist both classical and quantum attacks, and properly integrated post-quantum key establishment removes the known Shor-algorithm exposure that makes today’s RSA and elliptic-curve key exchanges retrospectively breakable. No cryptographic standard can guarantee absolute security against every future advance, but it closes the specific vulnerability that HNDL exploits.

That is a concrete, measurable, achievable security program. The PQC Migration Framework provides a structured approach, and Practical Steps to Quantum Readiness covers the immediate work. These are available today, and they solve the actual problem.

A detection dashboard for an undetectable threat is not a security program. It is expensive comfort.

The Legitimate Role for Network Monitoring

To be clear about what I am and am not saying: network monitoring, flow analysis, and behavioral analytics are valuable security controls. They detect breaches, exfiltration, lateral movement, command-and-control activity, and insider threats. Every organization should invest in them. The tools that vendors sell for these purposes are often good at what they claim to do.

What those tools cannot do is detect passive external collection, and they should not be marketed as though they can. Calling exfiltration detection “HNDL detection” does not protect the customer. It gives a board a false sense that the HNDL problem has been addressed when only the conventional exfiltration problem (which was always detectable and always worth detecting) has been covered.

The distinction is important for budget and priority. If a board believes HNDL has been “detected and covered” because a vendor sold them a rebadged NDR tool, they may deprioritize the actual defense: migrating long-lived confidentiality flows to post-quantum key establishment. That deprioritization is the real cost of the marketing claim. The snake oil does not just waste money. It redirects attention from the control that works.

The Only Ways to Confirm HNDL Targeting

If the passive harvest cannot be detected by technical means, how has any passive collection program ever been discovered? The historical answer is consistent: through human sources.

Pelton sold Ivy Bells to the KGB. Klein went public with Room 641A. Snowden disclosed Tempora. In each case, a person with insider access to the collection program revealed it. Signals intelligence agencies occasionally disclose that a capability exists (as when allied agencies issued warnings about Salt Typhoon), but even those disclosures typically describe capability and access rather than a specific archive of stored ciphertext.

The implication for your board: confirmation that your organization is a specific HNDL target would require intelligence reporting (from your own government’s intelligence services or from a partner), a defector or insider from the adversary’s program, leaked operational documents, or a law enforcement or counterintelligence investigation that penetrates the adversary’s collection infrastructure.

None of those is a technical control your security team can deploy. None is a product a vendor can sell you. They are intelligence outcomes, produced by intelligence agencies, and they are rare.

The Risk-Management Case Does Not Require Detection

After everything above, the conclusion is not that organizations should do nothing. It is that they should stop trying to detect the undetectable and start protecting what matters.

The previous article made the risk-management case: states have demonstrated passive collection at scale, the storage economics are trivial, governments treat retrospective decryption as a current planning risk, and regulators have set migration deadlines that will reach your organization regardless of what you believe about HNDL.

You do not need to prove you are being targeted to justify protecting your long-lived secrets. A pharmaceutical company does not need to prove a specific competitor is trying to steal a specific formula. It protects the formula because the formula is valuable, the threat is plausible, and the cost of protection is proportionate.

The same logic applies here. Identify the data whose confidentiality lifetime exceeds the plausible remaining life of your current key establishment. Migrate those flows to post-quantum cryptography. Do it because the data matters and the migration takes years, not because a product told you someone is watching.

That is the board-level answer. It does not require a detection dashboard. It requires a decision about which secrets need to outlive the cryptography protecting them, and the will to start replacing it before the question becomes urgent.