Why Post-Quantum Migration Isn't Optional, Even Without a Working Quantum Computer Yet

The most common objection to urgent post-quantum migration is also the most reasonable-sounding: no quantum computer today can break RSA-2048 or a production elliptic-curve key. That's true. It's also the wrong question.

The question that actually matters

The right question isn't "can a quantum computer break my cryptography today." It's: "how long does my data need to stay confidential, and is that longer than the time until a quantum computer can break it?"

This is the "harvest now, decrypt later" threat model, and it changes the math entirely. An adversary who wants to read your data in 2035 doesn't need a quantum computer in 2026. They need a hard drive in 2026, and a quantum computer in 2035. Encrypted traffic, stored backups, and archived communications captured today remain exactly as vulnerable in the future as they are today. Encryption doesn't expire, but the computational difficulty of breaking it does.

Who this actually affects

Most data genuinely doesn't matter here. A session token, a one-time password, or a page load over HTTPS for a news article all have confidentiality windows measured in minutes or days, far shorter than any realistic quantum timeline. Migrating these systems first would be a prioritization mistake.

The data that matters is data with a confidentiality lifetime longer than your quantum risk horizon. That includes:

• Government classification periods, often 25-50 years
• Genomic and health records, which are sensitive for a patient's lifetime and often beyond
• Trade secrets, unpublished patents, and long-horizon IP
• Long-term financial and legal records subject to extended regulatory retention

If your organization holds any of these categories, the "no quantum computer exists yet" objection doesn't apply to you. Your exposure started the day you encrypted the data with an algorithm quantum computers will eventually break, not the day a quantum computer arrives.

Why migration takes longer than people expect

Even organizations that accept the threat model often underestimate the migration timeline, for three structural reasons:

1. Cryptography is invisible infrastructure. Most organizations cannot produce an accurate list of where RSA or ECC is used across their systems without dedicated discovery work. This is exactly the gap a cryptographic bill of materials (CBOM) is built to close.
2. Supply chain dependency. You can decide to migrate tomorrow; your TLS library, your HSM vendor, your certificate authority, and your customers' clients all need to support the new algorithms too. Migration speed is bounded by the slowest dependency in the chain, not by your own intent.
3. Protocol and key-management redesign. PQC signatures and keys are often significantly larger than their classical equivalents. Systems designed around classical key/signature sizes, including embedded devices, constrained protocols, and legacy PKI hierarchies, may need real re-architecture, not a drop-in algorithm swap.

What the realistic timeline looks like

Every major national framework converges on a similar multi-phase structure, even though specific dates differ by jurisdiction (see our country-by-country tracker):

1. Discovery: build a cryptographic inventory (a CBOM). This alone can take months for a mid-sized organization with any technical debt.
2. Prioritization: rank systems by data confidentiality lifetime and migration difficulty.
3. Hybrid deployment: adopt hybrid classical+PQC schemes for key exchange first, since this is the lowest-risk, most broadly supported step today.
4. Full migration: complete transition for signatures, certificates, and any remaining classical-only dependencies.

Organizations that start discovery now are working toward a 2030s completion timeline most national guidance already assumes. Organizations that wait for "a working quantum computer" as the trigger event are not being cautious. They're skipping the step where caution would have actually helped.