TL;DR: The math changed. Two papers published in March 2026 showed that breaking elliptic curve encryption now requires far fewer qubits than previously thought, close enough to be a near-term engineering problem, not a distant physics one. Post-quantum standards are finalized and ready to deploy. If you store or transmit sensitive data protected by asymmetric cryptography, your migration plan should already exist. If you had a breach and encrypted data was taken, that data may be on a future decryption queue. Move off AES-128. Check your HSMs. Start now.
Last year I wrote a post titled Understanding Quantum Cryptography: Separating Fact from Fiction. The thesis was straightforward: the hype around quantum computers breaking modern cryptography was outpacing reality. Powerful quantum computers were far off. PQC standards were still being finalized. The advice was: stay informed, don’t panic, and wait for the standards to solidify before making large infrastructure bets.
That was the right call at the time.
I’m writing this because the calculus has shifted. If you’re responsible for your organization’s cryptographic posture, you need to know why.
What Changed
The two major drivers are technical, not political.
Qubit requirements dropped. When I wrote the original post, breaking 256-bit elliptic curve cryptography required an implausibly large, error-corrected quantum computer: millions of physical qubits by most estimates. On March 31, 2026, Ryan Babbush and Hartmut Neven at Google published research 1 showing Shor’s algorithm against P-256 now requires fewer than 1,200 logical qubits and 90 million Toffoli gates. That is a 20-fold reduction in physical qubit count. Days later, Cain et al. showed that with neutral-atom architectures and non-local connectivity, the P-256 discrete logarithm problem could be solved in a few days on a system with roughly 26,000 physical qubits 2. That is a number that starts to look like near-term engineering, not speculative physics.
The credible expert consensus shifted. Filippo Valsorda, a cryptography engineer whose judgment I respect, publicly reversed his position on CRQC timelines. His new estimate points to a meaningful probability of a cryptographically relevant quantum computer (CRQC) by 2029. He’s explicit that the burden now falls on skeptics to prove near-zero probability, not on the urgency camp to prove certainty.
PQC is now deployed, not just standardized. NIST finalized FIPS 203, 204, and 205 in August 2024 (ML-KEM, ML-DSA, and SLH-DSA). But the shift I’m pointing to is what happened after. Chrome shipped ML-KEM in TLS by default in mid-2024. OpenSSL and BoringSSL followed. By 2025, hybrid PQ key exchange was available in the production stacks most organizations already run. The argument I made in the original post — wait for standards to solidify before making infrastructure bets — no longer applies. The standards are done, the libraries are shipping, and the deployment gap has closed. There is no technical blocker left.
The Threat That Doesn’t Need 2029 to Start
IR practitioners have a specific exposure here.
Nation-state adversaries (and some well-resourced criminal groups) don’t need a quantum computer today to benefit from one in 2029. They need the data to still be valuable when the compute arrives. That’s the “Harvest Now, Decrypt Later” model: collect encrypted traffic now, store it, decrypt it when a CRQC becomes available.
If your organization has experienced a breach (a compromised perimeter, a supply chain incident, a nation-state intrusion), there’s a reasonable probability that encrypted data was exfiltrated alongside plaintext. Your TLS session keys, VPN handshakes, encrypted email archives, code-signing operations: all of it may be sitting in cold storage on someone else’s infrastructure, waiting.
IR is typically framed around what attackers can do today. This threat reframes the question: what can the data they already have do to you in three years?
Symmetric Crypto and HSMs
Grover’s algorithm halves the effective key length under quantum attack: AES-256 becomes roughly AES-128-equivalent. AES-128 itself drops to a 64-bit security level, which is not a comfortable margin. Our recommendation is to move off AES-128 entirely and standardize on AES-256 where you have the choice. Don’t conflate this with the asymmetric threat. The urgency is lower and the fix is simpler, but it’s worth doing now while you’re auditing anyway.
The risk is concentrated in asymmetric cryptography: key exchange (ECDH, RSA), digital signatures (ECDSA, RSA-PSS), and anything built on the hardness of discrete logarithms or integer factorization. These are the algorithms Shor’s algorithm breaks efficiently.
One specific hardware consideration: if your organization uses HSMs (hardware security modules) for key storage, code signing, or CA operations, check whether the firmware and algorithm support covers ML-KEM and ML-DSA. Many HSMs in production today do not. Vendor upgrade cycles for HSMs are long and sometimes require physical replacement. If a CRQC arrives before your HSM supports post-quantum algorithms, your key protection layer becomes the bottleneck. Add HSM roadmap review to your crypto inventory.
What to Do Now
This is a planning problem, not a panic problem. But it has to start now, because the migration timeline for asymmetric crypto is long.
1. Crypto inventory
You cannot migrate what you cannot see. Map where asymmetric cryptography is in use: TLS termination points, VPN endpoints, code-signing pipelines, hardware attestation roots, API authentication tokens, certificate authorities. Most organizations discover they have significantly more exposure than expected once they look.
2. Prioritize key exchange
ML-KEM is available, standardized, and deployable in TLS 1.3 via hybrid modes today. Key exchange migration is the highest priority because it directly neutralizes the Harvest Now, Decrypt Later threat for forward-looking traffic. Traffic protected with ML-KEM today is safe even if a CRQC arrives in 2029.
3. Plan for signature migration
ML-DSA is the replacement for ECDSA and RSA-PSS. Certificate lifecycles mean this takes longer: factor in CA upgrades, hardware security module support, and client compatibility. Start the planning cycle now so the execution isn’t forced.
4. Deprecate classical roots
Hardware attestation systems and long-lived certificate roots are the hardest to rotate. These need the longest lead time and the most organizational buy-in. Put them on the roadmap today.
The IR Angle
If you’ve had a confirmed intrusion (particularly one with suspected nation-state involvement), the scope of that breach may be larger than the point-in-time assessment suggested. Encrypted data exfiltrated in 2023, 2024, or 2025 is now in scope for future quantum decryption. This doesn’t change the remediation you completed, but it does change the long-term risk calculation for sensitive data that was exposed.
Breach response has always included assessing what data was taken. Going forward, it also needs to include: what was the cryptographic protection on that data, and how long does that protection hold?
Our Recommendation
If you are running TLS, VPN, or any PKI infrastructure today, start a PQC migration assessment. Not a pilot. Not a proof of concept. An inventory and a prioritized roadmap with a delivery date. The NIST standards are finalized. Major TLS libraries support ML-KEM hybrid modes. The 2029 CRQC window is close enough that certificate infrastructure migration timelines are already inside the risk horizon.
If you have experienced a breach in the last three years and encrypted data was exfiltrated, include quantum decryption risk in your long-term residual risk assessment. This is not theoretical. The threat model is operational for any adversary with the patience and storage to wait.
Profero can help scope the exposure, prioritize the migration path, and (if you have had an incident) reassess what the exfiltrated data means under a post-CRQC threat model. Contact us if you want to start that conversation.
The Bottom Line
A year ago, “don’t panic” was the right advice. The standards weren’t ready and the compute wasn’t there.
That’s changed. The standards landed in August 2024. The qubit barrier dropped twice in 18 months. The window for low-urgency planning is closing.
Start the crypto inventory. Prioritize ML-KEM for key exchange. Put signature migration on the roadmap. And if you’ve had a breach involving encrypted data exfiltration, factor quantum into your long-term risk model. Your adversaries already are.