Harvest Now, Decrypt Later | Elacity
A dark-web service is selling 153 million driver's license scans. Under harvest now, decrypt later, that stolen data becomes tomorrow's open book. The fix is sealing the asset, not the pipe.
Harvest Now, Decrypt Later: The Data Is Already Copied. Only Sealing It Survives.
You uploaded a photo of your driver's license to verify an account, because a company told you that was the safe way to prove you are you. That image now sits in a dark-web catalog of more than 153 million license scans. And under a strategy called harvest now, decrypt later, a stolen copy that looks safely encrypted today can be read in full years from now.
The service, called Nexus, offered 153 million driver license images for sale starting late August 2026, alongside millions of other identity documents. The FBI's New Orleans field office opened an inquiry after reporter Brian Krebs traced the images to an identity-verification provider.
The platform was pulled offline soon after. That changes nothing. The files were already duplicated, and a copy does not expire. Which raises the question almost no breach coverage asks: how long does an encrypted copy actually stay safe?
What harvest now, decrypt later actually means
Harvest now, decrypt later is a strategy, not a prediction. An attacker copies encrypted data today and waits. When a quantum computer capable of breaking today's public-key cryptography arrives, the entire stored collection unlocks at once, retroactively. Records with a long shelf life, a driver's license, a medical file, a biometric template, a key backup, are worth grabbing now precisely because they still matter in ten years.
The corpus already exists. Researchers this year catalogued a single exposed collection of roughly 24 billion stolen records. Every breach adds to a library that needs only one future advance to read cover to cover.
Most of the migration armors the wrong layer
The response so far is real, and mostly aimed at the pipe. NIST finalized its post-quantum standards, FIPS 203, 204, and 205, and pushed a government-wide migration. Enterprises are moving: DigiCert's 2026 Quantum Readiness survey found 87 percent of organizations planning, testing, or implementing post-quantum cryptography.
Planning is not deployment. The same survey found only 7 percent run more than half their certificates on quantum-safe or hybrid cryptography, barely above the year before. A separate 2026 measurement study reported that while nearly half of surveyed domains now support hybrid post-quantum key exchange, none had adopted hybrid post-quantum certificates.
Read that carefully. Almost all of this work protects data in motion, the session between your browser and a server. It does nothing for data at rest, the file already sitting in a dump. The 153 million licenses were not intercepted on the wire. They were copied from a store.
Where the trust boundary actually sits
Every security architecture draws a line and trusts everything inside it. For decades that line sat around the transport. Encrypt the connection, and the contents are safe in transit. That placement made sense when the threat was someone listening on the wire.
It is the wrong line for the harvest-now era. The thing worth protecting is the asset itself, wherever it comes to rest, and the key that unlocks it. Most systems keep the file encrypted at rest, then keep the key in a database an administrator can reach, which means an attacker who reaches that database can too. The key sits still, and a still key is a harvestable key.
Seal the asset, not the session
Elacity moves the boundary to the asset. Data, a file, a model, a credential, is packaged into an encrypted, programmable good, a Wealth Capsule, sealed with post-quantum-hybrid cryptography today, not on a someday roadmap. A capsule copied into a dump stays sealed, and a future quantum computer inherits ciphertext with no shortcut waiting inside it.
The key is the other half. In Elacity, keys are used, never owned. The secret that decrypts a capsule exists in the clear only for a split second, inside a sealed sandbox, welded to one authorized action, then wiped. It is never written to a database, so there is nothing at rest to harvest. The key itself is split across an owned quorum of independent machines, each of which re-checks your on-chain rights before releasing its share. Content stays encrypted everywhere except that single sealed moment of use.
Be honest about the edge: this is trust-minimised, not trustless. A colluding quorum could in principle reconstruct a key, which is exactly why the shares stay independent and the rights check stays on-chain. The contrast with confidential computing is worth drawing, because confidential computing hides your data during processing but still hands the operator the key. Sealing the asset changes who holds the lock.
None of this makes migrating your certificates optional. The pipe still needs armor, and that unglamorous protocol engineering work is overdue: seal the data, not just the pipe. But armoring the session was never going to protect the license already sitting in someone's archive. For data that must survive a decade, the question is not whether the connection was encrypted. It is whether the asset can still be read once it is copied, and by whom, and when.
The 153 million licenses are already gone. The only variable left is whether the copy is worth anything to whoever holds it in 2036. Seal the asset, keep the key un-harvestable, and the answer is no.
Follow Elacity on X for how we are building the ownership layer beneath it.