When people talk about the quantum threat to encryption, they usually frame it as a future problem. A quantum computer does not exist yet. Therefore the threat is not here yet. That framing is wrong. One of the most significant quantum security risks is already active, already being exploited, and cannot be fixed retroactively. It is called harvest now, decrypt later, and if your organisation handles sensitive data with a long shelf life, it is worth understanding carefully.
The mechanics are simple. An adversary, in practice a nation-state intelligence agency, intercepts encrypted network traffic and stores it. They cannot read it today. The traffic is protected by TLS, the underlying keys are ephemeral, there is no practical way to break the encryption with classical computers. But they keep it anyway. Because they are not planning to decrypt it today.
They are planning to decrypt it in ten years, when a quantum computer capable of running Shor’s algorithm becomes available. At that point, the stored traffic becomes readable. The encrypted communications of today become an open book in the future.
This is not a hypothetical. US intelligence officials have publicly confirmed that nation-state actors are conducting this kind of collection. The NSA cited harvest now, decrypt later as one of the primary drivers of urgency behind its CNSA 2.0 migration mandates, which require US government-adjacent systems to complete post-quantum migration by 2030 to 2033.
Why the usual logic does not apply here
With most security threats, the risk is in the future tense. A vulnerability has not yet been exploited. An attacker has not yet gained access. You have time to patch. With HNDL, the attack surface is the past. Every TLS connection your organisation made in the last five years, every encrypted email, every VPN session, if any of it was intercepted and stored by a sophisticated adversary, it is sitting in a database somewhere waiting for a quantum computer to be built.
You cannot un-encrypt it. You cannot retroactively protect it. The only thing you can do is stop the problem from getting worse, by deploying post-quantum key exchange now so that future traffic is not vulnerable even if it is collected.
Which data is actually at risk
Not all encrypted traffic has equal value to an HNDL attacker. The risk is highest when two conditions overlap: the data was transmitted over a network that could have been intercepted, and it would still be sensitive in a decade or more.
The categories that fit both criteria are mostly predictable. Diplomatic and government communications. Military and intelligence data. Long-term financial records and strategy. Pharmaceutical research and clinical trial data. Genomic and health information. Intellectual property in competitive industries. Legal documents and privileged communications.
If your organisation operates in any of these areas, the HNDL threat is not abstract. It is a direct operational risk.
What you can do
The answer is post-quantum key exchange in TLS. Specifically, deploying hybrid X25519 + ML-KEM in your TLS 1.3 configuration. This protects new traffic from HNDL collection even if a quantum computer eventually exists. The hybrid approach means you get post-quantum protection without abandoning classical security. If ML-KEM is somehow broken in the future, X25519 still protects you.
Google Chrome, Cloudflare, and AWS have all deployed hybrid post-quantum TLS already. OpenSSL 3.x supports it. The tooling exists today. The question is whether your organisation has deployed it.
The data already collected cannot be protected. But every day you delay post-quantum TLS deployment is another day of traffic being added to that collection. The window to stop the bleeding is now.