PQC Myths That Delay Migration

Quick answer: Five specific PQC myths consistently delay migration programs: “we can wait until a quantum computer actually exists,” “a larger RSA key solves the problem,” “PQC is a drop-in algorithm swap,” “our cloud provider handles this for us automatically,” and “QKD is a viable alternative to PQC.” Each contains a grain of a reasonable-sounding argument and a specific factual error that, corrected, changes the urgency and shape of a migration plan. This guide addresses each directly, without overstating the threat in the other direction.

PQC migration discourse has a genuine alarmism problem in both directions: some content treats quantum computing as an imminent, certain catastrophe, and some treats it as a distant, speculative concern safe to defer indefinitely. Neither framing is accurate, and both produce bad planning decisions. This guide sticks to what’s actually verifiable.

Key Takeaways

• Harvest-now-decrypt-later risk makes “wait until a quantum computer exists” a flawed strategy regardless of when that computer actually arrives, since data captured today is at risk once it does.
• Larger RSA keys do not solve the quantum problem; Shor’s algorithm’s advantage scales with the problem, not linearly, making key-size increases an ineffective mitigation.
• PQC is not a drop-in swap; it requires new certificate hierarchies, HSM validation, and application testing given fundamentally different key and signature sizes.
• Cloud providers migrate their own infrastructure, not customer-configured application-layer cryptography, leaving real work on the customer side regardless of provider.
• QKD is not a general-purpose alternative to PQC; deployability, authentication, and distance limitations make it a narrow, specialized tool at best.

Myth 1: “We Can Wait Until a Quantum Computer Actually Exists”

The reasonable-sounding version of this argument: no cryptographically relevant quantum computer exists today, and estimates for when one might vary widely, so urgency seems premature. The factual gap: harvest-now-decrypt-later risk means an adversary can capture encrypted data today and decrypt it once a capable quantum computer exists, whenever that turns out to be. For any data with a confidentiality period extending past even the earliest credible threat estimate, waiting to migrate means the exposure window has already opened, regardless of how far off the actual computer is. This isn’t a claim that quantum computers are imminent; it’s a claim that “wait and see” doesn’t protect long-lived data even if they aren’t.

Myth 2: “A Larger RSA Key Solves the Problem”

The reasonable-sounding version: doubling a classical key size has historically doubled security against brute-force attacks, so a larger RSA key should offer proportional protection against quantum attacks too. The factual gap: Shor’s algorithm, the quantum algorithm that threatens RSA and ECC, doesn’t face the same exponential difficulty increase from larger keys that classical brute-force attacks do; its advantage scales with the structure of the problem, not linearly with key size in the way that would make key-size increases an effective long-term defense. Larger RSA keys buy some incremental time against classical attacks but do not meaningfully change the quantum threat calculus, which is exactly why NIST standardized entirely new algorithm families rather than recommending larger classical keys.

Myth 3: “PQC Is a Drop-In Algorithm Swap”

The reasonable-sounding version: cryptographic libraries have historically supported algorithm agility, swapping RSA for ECDSA has generally been a configuration change, so PQC should work the same way. The factual gap: PQC keys and signatures run substantially larger than classical ones, ML-DSA-65 signatures at roughly 3,309 bytes versus 64 bytes for ECDSA, which breaks assumptions baked into certificate templates, HSM buffer sizes, network appliances, and application code across the stack, covered in depth in our certificate size and chain bloat guide. Most CA platforms, including AD CS, have no in-place upgrade path at all, requiring a parallel hierarchy instead. This is a genuine, multi-layer engineering project, not a configuration change.

Myth 4: “Our Cloud Provider Handles This for Us Automatically”

The reasonable-sounding version: major cloud providers have published detailed PQC roadmaps and are actively migrating their infrastructure, so customers might reasonably assume coverage is comprehensive. The factual gap: providers migrate their own managed infrastructure, not customer-configured application-layer TLS policies, client libraries, or code running inside customer compute instances, the shared-responsibility distinction covered in our cloud shared responsibility guide. AWS’s own documentation is explicit that applying updated TLS policies to customer-owned resources is a customer action. Real, substantial work remains on the customer side regardless of provider.

Myth 5: “QKD Is a Viable Alternative to PQC”

The reasonable-sounding version: QKD’s security rests on physical principles rather than computational hardness, which sounds like a stronger guarantee. The factual gap: QKD requires dedicated fiber or line-of-sight infrastructure that cannot run as a cloud service, provides key distribution only without native authentication, and is limited to tens of kilometers before requiring trusted intermediate nodes, all covered in our PQC vs QKD comparison. The NSA has stated it does not recommend QKD for National Security Systems. QKD isn’t fraudulent or without merit for narrow use cases; it simply isn’t a general-purpose substitute for the software-based PQC migration every enterprise’s broader infrastructure requires.

What We’d Actually Recommend

Correct these five specific misconceptions in your own organization’s planning conversations, since each one, left unaddressed, leads to a concrete planning error: deferred timelines, ineffective mitigations, underestimated engineering scope, unaddressed customer-side responsibility, or a misdirected QKD investment. Avoid overcorrecting into alarmism in the other direction; the goal is an accurate, evidence-based urgency level, not maximum urgency.

How Encryption Consulting Can Help

Our PQC Advisory Services ground migration planning in verified, current facts rather than either alarmist or dismissive framing, building a roadmap sized to your organization’s actual, evidence-based exposure.

CBOM Secure replaces assumption with data, showing exactly where your classical cryptography lives today rather than leaving urgency as a matter of opinion.

Accuracy Over Both Alarm and Dismissal

Each of these five myths contains a reasonable-sounding intuition and a specific, checkable factual gap, and correcting the gap, not amplifying the fear, is what actually improves planning. PQC migration doesn’t need urgency manufactured through worst-case quantum computing timelines; it needs an accurate accounting of harvest-now-decrypt-later exposure, the real engineering scope of algorithm migration, and where responsibility genuinely sits between customer and provider. Getting those facts right is a better foundation for a migration plan than either panic or complacency.

Frequently Asked Questions

Is it true that quantum computers capable of breaking RSA already exist?

No. No publicly known quantum computer today is capable of breaking current RSA or ECC key sizes in practice. The urgency around PQC migration comes primarily from harvest-now-decrypt-later risk and the multi-year time needed to migrate infrastructure, not from a claim that the threat is already realized.

Does increasing RSA key size to 4096 bits or higher provide meaningful quantum protection?

Not meaningfully against a capable quantum computer. Shor’s algorithm’s advantage against RSA does not require the same exponential resource scaling that makes larger keys effective against classical brute-force attacks, which is why NIST standardized structurally different algorithms rather than recommending larger classical keys.

Why isn’t PQC migration as simple as updating a TLS library version?

Because PQC keys and signatures are substantially larger than classical ones, which affects certificate templates, HSM configuration, network appliance compatibility, and application assumptions across the stack, not just the cryptographic library itself.

If our cloud provider has a PQC roadmap, do we still need our own migration plan?

Yes. Cloud providers migrate their own managed infrastructure; customer-configured application-layer cryptography, client libraries, and code running in customer compute instances remain the customer’s responsibility regardless of the provider’s own progress.

Is QKD completely without merit compared to PQC?

No, but its merit is narrow. QKD may have value for specific, fixed, high-value point-to-point links, but its infrastructure requirements, lack of native authentication, and distance limitations make it unsuitable as a general-purpose substitute for the software-based PQC migration most enterprise infrastructure requires.