Quantum-Safe Cryptography: When Should You Start the Migration?

Quantum-safe cryptography has been the topic of conference keynotes for a decade, and through most of that decade the practical advice for CISOs was to follow the standards development and not act. That stance was correct at the time. The standards were not ready. The threat was theoretical. The migration cost was high without a clear payoff. As of 2026 the calculus has shifted enough that the boilerplate advice is starting to look like a deferred problem rather than a deferred decision, and the question of when to actually start is now a real one for security leaders to answer.

This is a working assessment of where quantum-safe cryptography stands, what the credible threat timeline looks like, and how to think about migration without either ignoring the question or overreacting to it.

The standards finally landed

The single biggest change in the quantum-safe story is that the standards arrived. NIST finalized the first batch of post-quantum cryptographic algorithms in 2024, covering key encapsulation and digital signatures. The chosen algorithms have been through years of academic scrutiny. They have implementation libraries that work. The major TLS implementations have added support, and the cloud providers have begun rolling out post-quantum options in their managed key services.

The arrival of stable standards changes the migration math. Until the standards landed, any cryptographic migration would have risked being stranded on an algorithm that lost the standards competition. That risk is now resolved for the core algorithms. There will be additional standards work in subsequent rounds, and certain niches – particularly stateful hash-based signatures for very long-lived signing keys – are in their own track. For the bulk of common cryptographic use, the algorithm choice is no longer the bottleneck.

The threat timeline is still unclear, but is closer than the historical posture assumed

The threat model that motivates quantum-safe cryptography is straightforward to state. A sufficiently capable quantum computer running Shor’s algorithm can break the asymmetric cryptography that secures most of the modern internet – RSA, the various flavors of elliptic curve cryptography, the key exchange protocols that underpin TLS. The capability needed is enormous. The largest publicly known quantum computers today are not close to the capability required. The question is how close they will be in five, ten, or fifteen years.

Forecasts vary widely. Conservative academic estimates put the time-to-cryptographically-relevant quantum computer at fifteen to twenty-five years. Aggressive forecasts from industry players with quantum hardware roadmaps put it closer to a decade. Defense intelligence assessments published over the last few years generally fall between these. The honest answer is that the timeline is uncertain enough that any specific number deserves skepticism, and the prudent posture is to plan for a range.

The harder version of this question is the harvest-now, decrypt-later threat. Adversaries with the capability to intercept encrypted traffic today can store it and decrypt it once the necessary quantum capability exists. For data with a long sensitivity window – classified information, certain commercial trade secrets, personal health records, financial information that remains sensitive for decades – the threat is effectively here today, because the data being collected today will be decrypted within the data’s sensitivity window even on the more conservative quantum timelines.

For data with a short sensitivity window – session tokens, ephemeral negotiations, most operational data – the threat is fifteen years away or more, and the migration urgency is correspondingly lower.

What credible migration timelines look like

A few timelines have emerged from the organizations that have started migration work seriously, and they are sobering in scale.

The discovery phase – cataloging where cryptography is used inside the organization – is itself a multi-year project for any organization of meaningful size. Cryptography is everywhere. TLS terminators, VPN concentrators, database encryption, document signing, code signing, secure boot in hardware, embedded device keys, every API client doing its own thing. A complete inventory takes one to two years of dedicated effort to build and another year of effort to keep current.

The dependency assessment phase – identifying which cryptographic primitives are exposed to the quantum threat, which can be replaced, which require coordination with external parties, and which are baked into hardware that cannot be updated without replacement – is shorter than the discovery phase but still takes a year of work after the inventory is in place.

The actual migration phase varies wildly by component. Software that uses standard cryptographic libraries through clean abstractions can be migrated relatively quickly once the libraries themselves support post-quantum algorithms. Software with hard-coded cryptography, custom implementations, or tight coupling to specific algorithms needs significant rework. Hardware that cannot be updated needs replacement on whatever the hardware replacement cycle is, which can be five to ten years or longer for some industrial and infrastructure systems.

The protocol coordination phase is the longest. Most cryptography lives inside protocols, and protocols depend on multiple parties supporting the same algorithms. TLS migration is well underway because the standards bodies have moved together. Email signing, code signing infrastructure, certificate authorities, and the long tail of less-prominent protocols are at varying stages, and the migration for each is constrained by the slowest participant.

Where to actually start

For most organizations, the right starting move is not algorithm replacement. It is crypto-agility. The single most valuable investment an organization can make is to refactor its cryptographic use so that algorithms can be swapped without rewriting the surrounding code. Crypto-agility is useful regardless of quantum threat – it is also valuable when algorithms get deprecated for any other reason – and it produces a cheaper migration path when the algorithm choices change in the future.

The practical work of crypto-agility involves replacing direct calls to specific algorithms with abstraction layers, ensuring that key formats and storage support multiple algorithm types, building in versioning so that the system can recognize and handle keys generated under different algorithms, and updating monitoring and logging to track which algorithms are in use where.

This work is unglamorous. It produces no immediate quantum protection. It is also the foundation that makes the eventual quantum-safe migration tractable rather than a multi-year crisis.

What to migrate first

Once the foundation is in place, the right migration sequence is driven by data sensitivity window rather than by ease of implementation. The components that handle long-lived sensitive data should migrate first, even if they are harder to migrate than components handling ephemeral data.

The high-priority targets typically include any signing infrastructure with long-lived signatures – code signing systems where a signature on a binary may need to remain trustworthy for a decade or longer, document signing for legal records, certificate authorities where the trust chain has long-lived components. Data-at-rest encryption for sensitive long-lived data is high priority, with the caveat that symmetric algorithms are less affected by the quantum threat than asymmetric algorithms, so the relevant work is mostly on key wrapping and key exchange rather than the bulk encryption.

Transit cryptography for currently sensitive data should be considered, but the urgency depends on the threat model. For organizations whose adversaries plausibly include nation-states with collection-and-decrypt capability, transit cryptography for sensitive flows is on the priority list. For organizations whose adversary model is commercial cybercrime, transit cryptography can move later because the threat actor profile does not match the harvest-now, decrypt-later pattern.

The hybrid approach

The migration approach that has emerged as the consensus path is hybrid – running both classical and post-quantum algorithms in parallel during the transition. A hybrid TLS handshake uses both classical and post-quantum key exchange, with the session key derived from both. If either algorithm holds, the session is secure.

The hybrid approach is a transitional safety measure. It provides protection against the case where the post-quantum algorithms turn out to have a flaw that academic review did not catch, while still protecting against quantum attacks on the classical algorithms. The cost is slightly larger handshakes and slightly more compute, both of which are tolerable in modern environments.

Most major cryptographic protocols are moving toward hybrid as the default, and customers should expect to consume hybrid implementations from their vendors over the next few years. Organizations should not roll their own hybrid – the protocol-level coordination is subtle and getting it wrong is easier than it looks. The right move is to consume vendor implementations and to verify they are using the standards-track post-quantum algorithms.

The regulatory pressure

Regulators have started to move on quantum-safe cryptography, though more slowly than some advocates would like. The US federal government has issued direction requiring federal agencies to inventory their cryptographic use and plan migrations. The financial regulators in several jurisdictions have begun signaling that quantum-safe migration will be expected within a defined timeframe. The defense sector has the most stringent requirements.

For organizations not under these specific regulatory regimes, the pressure is indirect. Vendors who serve regulated customers will be implementing quantum-safe options, and the broader ecosystem will follow. The practical effect is that the cost of waiting to start is declining – the tooling, the standards, and the vendor support are increasingly available – while the cost of starting too late is rising.

Honest framing for security leaders

Quantum-safe cryptography is not an emergency for most organizations. It is also no longer a problem that can be deferred indefinitely. The right posture for a security leader in 2026 is somewhere in the middle of those poles.

Start the inventory now. The discovery phase will take longer than expected, and the inventory is valuable regardless of how the quantum threat evolves. Invest in crypto-agility for new systems and for systems undergoing significant updates. Do not retrofit crypto-agility into stable systems just for the sake of it – let the natural update cycle handle it.

Identify the high-priority migration targets based on data sensitivity window. Most organizations have a small number of systems where the migration is genuinely urgent and a much larger number of systems where the migration is appropriate but not yet pressing. Distinguishing the two prevents both panic and complacency.

Track the vendor ecosystem. Many of the components in any organization are vendor-supplied, and the vendor’s quantum-safe roadmap is part of the customer’s planning. Vendors that are not credible on this dimension should be on the watch list for replacement.

And resist the urge to make a big announcement about a quantum migration program. The work that produces good outcomes is unglamorous and sustained, and big announcements tend to produce theater. The teams that quietly run a multi-year crypto-agility program and start migrating the highest-priority components are the ones that will be in good shape when the threat materializes. The teams that announce a quantum task force and then return to their other priorities will not.