Getting ahead of ‘harvest-now-decrypt-later’: Post

Quantum threats may be years away, but your data could already be at risk, making now the time to start your cryptography migration. I’ve sat in enough boardroom conversations about quantum computing to notice a pattern. Someone raises it, someone else says “that’s ten years out,” and the topic gets tabled until next year’s budget cycle. The clock that matters isn’t the one measuring when a quantum computer arrives. It started running the moment your organization first sent sensitive data over a channel an adversary could capture and store. A nation-state or well-resourced criminal group doesn’t need a working quantum computer today to threaten you. It needs storage capacity and your ciphertext, both of which it likely already has. It can sit on that data for years and decrypt it retroactively the day a cryptographically relevant quantum computer exists. Data that only needed to stay private for a few months isn’t at risk under this model. A patient record, a source code repository, a decade-long trade secret or classified government material is a different story. For many organizations, that story is already unfolding. Ashish Mishra Why the deadlines keep moving closer NIST’s transition plan, published as NIST IR 8547, gives you actual dates to plan around: RSA-2048 and ECC P-256 get deprecated by 2030, and they’re gone from NIST standards entirely by 2035. That timeline isn’t theoretical anymore. NIST spent eight years getting here, and in August 2024 it finally landed three finalized FIPS standards. ML-KEM handles key encapsulation. ML-DSA and SLH-DSA cover digital signatures, using two different mathematical approaches so you’re not betting everything on one scheme holding up. A fourth standard, FN-DSA (built on the FALCON algorithm and designated FIPS 206), is due out later this year. Organizations in national security or defense-adjacent environments are working against a tighter window. The NSA requires national security systems to adopt quantum-resistant cryptography for new acquisitions starting in 2027. The UK has set its own pace on a similar structure — the NCSC’s guidance splits the transition into three phases: identifying cryptographic services and building a migration plan through 2028, executing high-priority upgrades from 2028 to 2031, then completing migration across all systems, services and products between 2031 and 2035. None of this belongs in the “future planning” bucket anymore. A 2030 deprecation deadline sounds distant until you map it against how long your organization takes to touch every system running cryptography. I’ve run cryptographic discovery projects that stretched past a year just to produce an accurate inventory, for a client who thought they had a clear picture of their own environment going in. Let the math set your timeline, not the headlines Mosca’s theorem is worth learning even if you never see the formula written out. It weighs three numbers against each other: how long migration will take you (X), how long your data needs to stay confidential (Y) and how soon a cryptographically relevant quantum computer is likely to exist (Z). When X plus Y outpaces Z, you’re already exposed, whether the exposure has been noticed yet. Run that comparison against your own data instead of against an industry average. A retail transaction log with a two-year retention window carries a different risk profile than genomic data, merger documentation or infrastructure design specs that need to stay confidential for thirty years. For a good number of organizations, that confidentiality window runs well into the 2030s and beyond — healthcare records, financial data and classified information can need protection for fifty years or more. If any of your data fits that description, “quantum computers are a decade away” stops being a reason to wait and starts being the reason you’re already behind. What migration requires Treating this like a patch cycle is the mistake I see most often — swap an algorithm, ship an update, move on. That framing misses the scale of what’s involved. Migrating to post-quantum cryptography means locating every algorithm in every protocol, on every device, across every product in your supply chain and replacing each one without breaking interoperability with everyone else going through the same transition on their own timeline. Start with discovery, because it’s the piece every client underestimates going in. You need a real inventory of where RSA, ECC and other quantum-vulnerable algorithms are running — in TLS configurations, code signing processes, VPN tunnels, embedded firmware and third-party libraries you didn’t write and may not fully control. Almost every discovery project I’ve been part of has turned up cryptography the client had forgotten existed. From there, the architectural goal is crypto-agility rather than a one-time fix. Migrating once and hoping the next transition goes smoother isn’t a strategy, since there will be a next transition. Building systems where swapping an algorithm doesn’t require rebuilding the surrounding infrastructure means abstracting cryptographic operations behind interfaces that don’t hard-code a specific algorithm and standing up key management that can run classical and post-quantum algorithms side by side during the overlap period. Prioritization should track data sensitivity and exposure time, not convenience or ease of implementation. Systems holding data with long confidentiality windows need to move first. Public-facing TLS endpoints carrying traffic vulnerable to harvest-now-decrypt-later deserve early attention too, since that’s the traffic most likely already sitting in someone else’s storage. Vendor coordination is where I’ve watched migrations lose months. Your own readiness only goes as far as the readiness of every vendor whose cryptography your systems depend on. Asking vendors for their PQC roadmaps now costs you nothing, and waiting until your migration hits a dependency you don’t control costs you a quarter you didn’t budget for. Ashish Mishra Where to start this quarter You don’t need a board mandate to justify the first step here. CISA, NSA and NIST have jointly published a six-step migration playbook, and cryptographic discovery — the first step in it — is something you can start on your own budget and your own schedule, without waiting on a vendor or a committee decision. In my experience, the organizations struggling in 2030 won’t be the ones running the most complicated environments. They’ll be the ones who spent 2026 waiting for someone else to move first, even though the standards were already finalized and the guidance was already public.