They're Already Copying Your Encrypted Data

The dangerous part of the quantum threat is not the quantum computer. It is the hard drive filling up right now with your encrypted traffic, waiting for one.

Every conversation about post-quantum cryptography that starts with “when a cryptographically relevant quantum computer arrives” has already lost the plot. It frames the risk as a future event you can plan around, a deadline on someone else’s calendar. That framing is comfortable and it is wrong. The attack is not scheduled for the day the hardware ships. The attack is happening tonight, on the wire, against ciphertext an adversary cannot read yet and fully intends to. The decryption is deferred. The collection is not.

The threat is collection, not decryption

The name for this is harvest now, decrypt later, and it inverts every instinct you have about how a crypto break plays out. The usual mental model is a race: the defenders rotate to stronger algorithms, the attackers try to catch up, and whoever is faster on the day of the break wins. Harvest now, decrypt later removes the race entirely. The attacker does not need to break anything today. They need to copy your TLS session today and store it. The break happens later, on their schedule, against a static file that cannot rotate its keys after the fact because the session is over and the bytes are frozen.

That single property is what makes this a present-tense problem for a specific kind of data. If your traffic is only sensitive for the next ninety days, harvest now, decrypt later is a shrug. Nobody is warehousing petabytes of ciphertext to read your lunch order in fifteen years. But financial records, account relationships, transaction histories, the personally identifiable data behind them, and the long-lived credentials and non-human identities that authenticate systems to each other carry a sensitivity horizon measured in decades, not quarters. A mortgage originated today is on the books for thirty years. A customer’s identity data is sensitive for their lifetime. For a regulated institution, “how long must this stay confidential” is frequently answered in retention schedules that outlast the hardware timeline everyone keeps waving away. Overlap those two curves, the retention horizon and the decryption horizon, and the intersection is the exposure. If your data must stay secret longer than the time it takes quantum hardware to mature, it is already at risk. The traffic is being collected against that intersection whether or not you have modeled it.

Why quantum breaks the asymmetric half

The physics matters here because it tells you exactly what breaks and what survives, and the split is not intuitive.

A classical computer attacks RSA by trying to factor a very large number, and the honest reason RSA has held up is that factoring is slow enough to take longer than the universe has existed. Peter Shor broke that assumption on paper in 1994. Shor’s algorithm does not factor faster by brute force. It reframes factoring as a period-finding problem and uses quantum interference to make the correct answer reinforce itself while the wrong answers cancel out, collapsing a problem of cosmic runtime into one that finishes in hours or minutes on hardware with enough logical qubits. The same machinery dismantles the discrete logarithm problem, which means it is not just RSA. Elliptic curve cryptography, ECDSA, ECDH, Diffie-Hellman key exchange, the entire asymmetric layer that negotiates the session keys protecting your traffic, all of it rests on problems Shor’s algorithm is purpose-built to solve.

The symmetric half is fine. AES is not threatened in any practical sense. The best quantum attack on symmetric ciphers is Grover’s algorithm, published by Lov Grover in 1996, and it only delivers a quadratic speedup, which effectively halves the key length. AES-256 drops to something like 128 bits of security against a quantum adversary, which is still astronomically far from breakable. Hash functions land in the same forgiving place, so SHA-256 gets treated as roughly SHA-128 equivalent and keeps working. The clean way to hold this in your head: the symmetric keys are safe, but the asymmetric handshake that delivers those keys is the soft target, and breaking the handshake unlocks everything the session protected. An adversary who harvests the handshake harvests the session.

The standards are finalized. This is not research anymore.

The most expensive misconception left in this space is that post-quantum cryptography is still a laboratory topic waiting on academic consensus. It is not. The consensus arrived, the horse race ended, and the replacement algorithms are published federal standards.

In August 2024, NIST finalized the first three post-quantum cryptography standards, converting years of open competition into normative documents you can build against today:

• FIPS 203, ML-KEM, the module-lattice key-encapsulation mechanism derived from CRYSTALS-Kyber. This is the one that replaces your quantum-vulnerable key exchange, and it is the priority, because key exchange is exactly what harvest now, decrypt later attacks.
• FIPS 204, ML-DSA, the module-lattice digital signature algorithm from CRYSTALS-Dilithium, the general-purpose signing standard.
• FIPS 205, SLH-DSA, a stateless hash-based signature scheme from SPHINCS+, deliberately built on different mathematical foundations as a hedge in case the lattice-based schemes ever weaken.

A fourth signature scheme, FN-DSA based on FALCON, is still moving toward publication as FIPS 206 for the cases that need smaller signatures. The point of the set is not any single algorithm. It is that these schemes rest on mathematical problems, lattice problems and hash preimages, that neither classical nor quantum computers know how to solve efficiently. Post-quantum cryptography does not fight the quantum computer. It changes the lock to one the quantum tools have no key for, and it runs on the classical hardware you already own. There is nothing to wait for. The standardization phase you were told to watch for is over. What remains is an implementation project, and implementation projects are the ones that die from being scheduled instead of started.

Migration is an inventory problem before it is a crypto problem

The instinct is to treat this as swapping one algorithm for another, a library upgrade you drop in when there is a free sprint. The reality is closer to a supply-chain audit, and the first phase has nothing to do with quantum anything.

You cannot migrate cryptography you cannot see. The migration path that the standards bodies actually recommend starts with a discovery pass: catalog every place asymmetric cryptography lives across the estate, which is a longer list than anyone’s first guess. TLS certificates are the obvious ones. Then code-signing keys, VPN tunnels, SSH keys, the certificate authorities and secrets managers underneath them, the mutual TLS between internal services, the embedded certificates baked into appliances and firmware that nobody has touched in years. Every one of those is an asymmetric dependency, and every one is a place Shor’s algorithm eventually reaches. This is the same visibility gap I keep circling in Who Scans Whom and the non-human identity problem: the machine-to-machine credentials outnumber the human ones by orders of magnitude, they authenticate with exactly the asymmetric primitives quantum breaks, and most institutions have no complete inventory of them. You cannot rotate what you have never enumerated.

Once you can see the estate, you prioritize by the intersection from the top of this piece: the data with the longest confidentiality horizon migrates first, because it is the data already sitting in someone’s harvest. Then you deploy in hybrid mode, running a classical algorithm and a post-quantum one together so the session is protected if either one holds. That gives you a safe transition without betting the whole estate on brand-new schemes overnight, and the major cloud and platform providers have published roadmaps built around exactly this hybrid path. Private networking, incidentally, does not get you out of any of this. Keeping traffic off the public internet reduces how much an adversary can capture, but it does not change the underlying math on the traffic they do capture. The vulnerability is in the cryptography, not the network topology.

Crypto-agility is the actual architectural requirement

Here is the reframe that makes the rest of this durable instead of a one-time fire drill. The deliverable is not “we deployed ML-KEM.” The deliverable is an architecture that can swap cryptographic primitives without re-plumbing the systems that depend on them.

Most systems in production today fail this test badly. The algorithm is welded in, hardcoded into the handshake, assumed by the protocol, wired into certificate formats and key sizes that were never meant to move. That rigidity is precisely why the current migration is so expensive: the last time anyone changed the default was a generational event, so nobody designed for the next one. Crypto-agility is the discipline of building that seam on purpose, abstracting the algorithm behind an interface so the primitive becomes a configuration decision rather than a rebuild. Treat it as a first-class architectural requirement, the same way you treat authentication or logging, and the post-quantum migration stops being a singular crisis and becomes the first exercise of a capability you were always going to need again.

That is the mindset shift a regulated institution should take from this whole episode. The lattice schemes are strong today. If a weakness ever surfaces, and the reason FIPS 205 exists on a different mathematical base is that NIST takes that possibility seriously, you want to swap the primitive on a change ticket, not a multi-year program. The threat that forced this conversation was quantum. The capability it should leave behind is the ability to change your mind about any algorithm, ever, without tearing the building down. Build the seam once and every future crypto transition rides it.

None of this depends on knowing the exact year the hardware arrives, and that uncertainty is not your reprieve. It is the adversary’s business model. They do not need to predict the date either. They only need to keep copying, keep storing, and wait. The migration clock is not counting down to the quantum computer. It started the day your long-lived data first crossed a wire someone was recording, and that day is behind you.

---

The comfortable version of this story is a countdown to a future event. The accurate version is a collection that already happened, against data you are still generating. Plan for the second one.

I write about enterprise architecture, regulated-industry security, and the gap between how risks are framed and how they actually operate. Find me on X @orestesgarcia or LinkedIn /in/setsero.