Home/ Blog/ Harvest Now, Decrypt Later: Getting...
Article

Harvest Now, Decrypt Later: Getting Ahead of the Post-Quantum Threat

PublishedAug 11, 2026 AuthorRarefied Read time4 minutes
post-quantumcryptographyencryptionnetwork securityemerging threatspentesting

Encryption buys you time, not permanence. That distinction rarely matters, because most stolen data loses its value long before the cryptography protecting it weakens. But some data does not expire. Patient health records, source code, government communications, biometric templates, long-term contracts, and the private keys underpinning your own infrastructure all retain value for years or decades. An adversary who captures that traffic today and stores it does not need to break your encryption now. They need to break it eventually. That is the entire premise of "harvest now, decrypt later," and it is the rare emerging threat where the attacker's work is already done and yours has not started.

What HNDL Actually Claims

The argument is simple enough to state in three steps. Capturing encrypted traffic is cheap and largely undetectable — a well-positioned adversary at a network chokepoint, a cloud provider boundary, or a compromised transit path can archive sessions indefinitely. Storage is cheap. And current public-key cryptography rests on mathematical problems that a sufficiently capable quantum computer is expected to solve efficiently.

Nobody serious claims that machine exists today. The point is that the decision to record traffic is being made now, and it costs an adversary almost nothing to be wrong. If they are right in fifteen years, they hold plaintext for every session they saved. Your risk is a function of one question: how long does your data need to stay confidential?

Which Cryptography Is Actually at Risk

The threat is uneven, and treating it as uniform leads to wasted effort.

  • Public-key algorithms: RSA and elliptic curve cryptography, used for key exchange and digital signatures, are the exposed surface. Their security rests on integer factorization and discrete logarithms — precisely the problems quantum algorithms are expected to make tractable.
  • Key exchange versus signatures: Both are affected, but the urgency differs. A recorded key exchange can be broken later to decrypt archived traffic, which makes it an HNDL problem today. Signature forgery requires a capable machine at the time of the attack, so it is a future problem rather than a retroactive one.
  • Symmetric encryption: AES and modern hashing hold up far better. The best known quantum attacks weaken them, but not catastrophically, and larger key sizes address it. Your bulk data encryption is not where the fire is.
  • The real dependency: Most systems use public-key crypto to establish a symmetric session key. Breaking the key exchange yields the session key, which yields everything encrypted with it. Strong symmetric ciphers do not save you if the handshake that delivered the key is broken.

Crypto Agility Beats Prediction

The industry is converging on standardized post-quantum algorithms, and hybrid modes — classical and post-quantum key exchange combined — are appearing in mainstream TLS implementations and browsers. The migration will take years, and it will not be the last one. Algorithms get deprecated. Implementations get flaws. Guidance changes.

This is why crypto agility matters more than any specific algorithm choice. The organizations that will handle this migration cleanly are the ones that can answer basic questions today: where is cryptography implemented, is it centralized behind libraries you control or scattered across dozens of services, are algorithms configurable or hardcoded, and how long does it take to change a cipher suite fleet-wide? If the answer to the last question is measured in quarters, the algorithm you pick matters less than your inability to replace it.

What to Do Before Any of This Is Urgent

The useful work is inventory and hygiene, and all of it pays off regardless of when quantum computing matures.

  • Find the long-lived data: Classify what genuinely needs confidentiality beyond a decade. It is usually a much smaller set than people assume, and it tells you where to prioritize.
  • Map your cryptography: Know which protocols, algorithms, and key sizes are in use across internal services, third-party integrations, VPNs, and legacy systems that nobody has touched in years.
  • Kill the legacy surface: Deprecated TLS versions, weak cipher suites, undersized keys, and unencrypted internal traffic are exploitable now, not in fifteen years. HNDL is a good reason to fix them; it is not the main one.

Where Testing Fits

Post-quantum readiness is not a separate exercise. It falls out of work you should already be doing. A thorough network penetration test surfaces the outdated protocols, weak crypto configurations, unencrypted internal channels, and exposed sensitive data that make harvesting easy in the first place. An adversary recording your traffic has a far easier time when a service still negotiates an obsolete TLS version, or when internal service-to-service calls are plaintext because they sit "inside the perimeter."

Our methodology treats cryptographic posture as part of the assessment rather than a checkbox, which means telling you where your crypto is weak today and where it will be hard to change tomorrow. The second finding is often the more valuable one. Practically speaking, an organization that knows its cryptographic inventory and can rotate algorithms without a rewrite has already solved the hard part of post-quantum migration.

Next Steps

If you want to know where your weak crypto and legacy protocols actually live, get in touch. Start with the inventory — the migration is straightforward once you can see what you have.

This post represents the view of the individual author and not necessarily that of Rarefied Inc.
Get in touch

Interested in professional security testing?

Tell us what you’d like tested and we’ll get back to you shortly.

Contact Rarefied