In August 2024, NIST finalized its first set of post-quantum cryptography standards. ML-KEM, ML-DSA, SLH-DSA. Three algorithms meant to replace RSA and elliptic curve cryptography before large-scale quantum computers arrive.

Most people in the industry read about this. Most organizations did nothing.

I understand why. Quantum computers that can break RSA-2048 don’t exist yet. The estimates for when they will exist vary wildly — five years, fifteen years, maybe longer, maybe never at the required scale. And there are more immediate problems. Vulnerabilities to patch, incidents to respond to, audits to pass. Why invest in protecting against a threat that might not materialize until your successor’s successor is running the security team?

Here is why.

Harvest Now, Decrypt Later

This attack has a name. HNDL. Harvest now, decrypt later.

The idea is simple. You don’t need a quantum computer today to benefit from quantum computers eventually. You need to capture encrypted traffic today, store it, and wait. When quantum computing matures enough to break RSA or ECC, the stored ciphertext becomes readable.

This works for any data with long-term value. Government communications. Health records. Financial transactions. Intellectual property. If an adversary with sufficient patience and resources is collecting your encrypted traffic now — and several nation-state actors are doing exactly this, according to multiple intelligence reports — then the future key compromise is already partially complete. The interception already happened.

The migration to post-quantum algorithms protects future traffic. It does nothing for data that has already been captured.

I find this genuinely unsettling. Not in an abstract, theoretical way. In a concrete way that makes me think about what I’d want to protect if I were the target, and what a sophisticated attacker would have prioritized collecting years ago.

What the Standards Actually Say

ML-KEM (formerly CRYSTALS-Kyber) handles key encapsulation — replacing how you’d use RSA or ECDH to establish a shared secret. ML-DSA (formerly CRYSTALS-Dilithium) handles digital signatures. SLH-DSA (SPHINCS+) is a hash-based signature scheme included as a more conservative alternative.

The underlying math is different from classical cryptography. ML-KEM and ML-DSA are based on lattice problems — specifically the Module Learning With Errors problem. The security assumption is that certain computations involving lattices are hard even for quantum computers, which is where classical public key cryptography fails. Shor’s algorithm breaks RSA and ECC efficiently on a sufficiently powerful quantum machine. No equivalent algorithm exists for the lattice problems these schemes rely on.

I’m not a cryptographer. I’ve been working through the NIST documentation and the relevant papers because I think understanding what you’re recommending to others is a baseline requirement for having an opinion about it. The math is dense. The security proofs are long. The important thing to know is that these standards went through years of public cryptanalysis with many smart people trying to break them.

Some candidates did break. SIKE, a promising isogeny-based scheme, was broken in 2022 — not by quantum computers, by classical mathematics. It had passed multiple rounds of evaluation. This is why cryptography relies on public review and takes years.

The ones that survived are the ones NIST standardized.

The Migration Problem

Swapping out cryptographic primitives sounds like a software update. It is not.

Cryptography is embedded in protocols, libraries, hardware, firmware, and configurations. TLS. SSH. Code signing. VPN authentication. PKI infrastructure. Certificate authorities. Hardware security modules. Embedded devices that haven’t received a firmware update since they were installed in 2016.

Large organizations have cryptographic inventory problems. They don’t know all the places where RSA is in use. They don’t know which systems support algorithm agility — the ability to swap cipher suites without a hardware replacement. They don’t know which vendors have post-quantum roadmaps and which don’t.

This is the boring part of the problem. Not the quantum computers. The IT asset inventory.

What This Means From an Offensive Perspective

I think about this from the other direction too.

If I’m a red teamer working against an organization five years from now — or now, with the right access — the interesting question isn’t whether I can break their quantum-resistant algorithms. It’s whether they’ve deployed them everywhere. The gaps in the migration are the attack surface. A single legacy service still using RSA-1024, unpatched and forgotten, is a more attractive target than the algorithm itself.

Migration creates a transitional period. During that period, systems need to support both classical and post-quantum algorithms for backwards compatibility. Hybrid deployments. That complexity introduces configuration errors, untested code paths, and interfaces between systems that weren’t designed to interoperate with post-quantum keys.

Complexity is always the enemy. I expect to see vulnerabilities in post-quantum implementations before the cryptography itself is broken.

Where I Am With This

I’ve been running through the reference implementations. Last week I set up a test environment with liboqs — the Open Quantum Safe library — and tried to get a basic ML-KEM key exchange working alongside a classical TLS handshake. It took longer than I expected. The library is reasonably documented but the tooling around it is still rough, and debugging a handshake failure that could be either a configuration error or a genuine interoperability issue is not a fast process.

That friction is the point. If I’m hitting it in a controlled lab environment with nothing at stake, I can only imagine what it looks like inside an enterprise network touching legacy systems from 2008.

The practical takeaway I keep coming back to: start the inventory now. Not the migration — the inventory. Know what you’re protecting, where it is, and what algorithm it’s using. The migration will take years. You need to know what you’re migrating before you can start.

The threat isn’t arriving with a flag planted in the ground. It arrived quietly, already capturing traffic, already waiting.