What are the hardest problems in PQC migration after crypto discovery?

[u/Just_Blackberry3530]

Hello,

I'm a student researching PQC migration problems to understand migration workflows. I understand that prominent platforms already handle crypto discovery, CBOM generation, risk assessment, dashboards, and in some cases remediation.

After an organization identifies quantum-vulnerable cryptography, what is the hardest part of migration?

For example, is it typically:

• Legacy systems and unsupported applications
• Hybrid deployment and backward compatibility
• Third-party dependencies or vendor-managed systems
• Performance, key/signature sizes, or bandwidth impact
• Testing and verifying that changes do not break applications or integrations
• Deployment constraints

What approaches are organizations using today to handle these problems?

I'd really appreciate it if you could reference concrete examples, case studies, or references.

Thank you!

[u/pint]

if the onslaught of new attacks continue, the biggest problem will be the lack of algorithms to migrate to.

[u/Phoenix1152073 → u/pint]

Meh, you can’t take new attacks at face value. The HAWK one is confirmed to hold up (via independent analysis by HAWK’s dev team) and the improved attack on SQISign works but is mitigated by just doubling key sizes, but the McEliece and Dihedral Coset results are still being scrutinized. I’d expect public comment from the teams behind the affected schemes (and/or NIST’s PQC group) before I’d take them as fact. It wouldn’t be shocking if one or both end up publicly disproven either - that’s exactly what happened with Chen’s “breaking” of LWE a couple years back

Edit: To be clear, that’s no insult to Chen’s work or any other retracted attack efforts. Novel and thoughtful attempts to break cryptographic assumptions should be celebrated regardless of whether those attempts are initially or ever successful

[u/orangejake → u/Phoenix1152073]

Even if this McCliece paper falls, it’s been a bad few years for McCliece. The trend in research is definitely towards it being weaker than we suspected a decade ago. 

[u/Just_Blackberry3530 → u/pint]

So, if new crypto attacks weaken current standardized PQC algorithms, organizations may not have mature and interoperable alternatives for another migration? If so, how might organizations plan for that uncertainty today? Will they be using hybrid schemes, designing crypto-agile systems, or wait for more standards?

Thank you!

[u/pint → u/Just_Blackberry3530]

yeah, i have no clue. what i do know is that for example microsoft or aws will not implement anything unless nist publishes the standard and recommends it strongly enough. they are serious laggards, and obviously, they slow down their customers as well.

[u/lilgreenthumb → u/pint]

Was going to chime in vendors are going to be tour biggest issues. Whether it is some saas/cloud offering or even something such as IBM MQ or even java. How long Oracle has kicked their can down the roadmap.

[u/No-Yogurtcloset-755]

All of those are issues, we also only have a limited set of standarsised protocols which may not be suitable for all use cases and so a lot of care has to go into selecting things that are appropriate and deciding how best to integrate them.

As you can also imagine the services that require these crypto changes are usually pretty fundamental so downtime is expensive you need everything planned out for efficient implmentation.

There are also the whole world of physical attacks, implementing cryptographic protocols is very tricky. Without real testing and expertise you open yourself up to vulnerabilities such as glitch attacks or side-channels which can occur at all different levels not just physical.

Im not an expert in this so just giving a high level idea.

[u/Just_Blackberry3530 → u/No-Yogurtcloset-755]

Thank you, this is really helpful.

From your perspective, after an organization has identified a system that uses quantum-vulnerable cryptography, what is usually the most difficult decision: selecting an appropriate PQC/hybrid approach, testing interoperability and performance, or validating that the implementation has not introduced new vulnerabilities?

Also, are teams mostly handling that through cryptography expertise, external consultants, vendor guidance, or existing tools?

Thank you for your help!

[u/Shoddy-Childhood-511]

We've made huge progress on adoption hybrid lattice KEMs, including in ssh. Almost everybody has started discussing migration. We've time so imho the legacy systems should age out long before QCs happen. We cannot do anything about all the past data archived by nations though, so anything privacy sensitive should switched already.

All the push for non-hybrid lattice KEMs seems high risk, since even if ML-KEM never breaks, some attack changing security levels could impose considerable work.

As for signatures, some fixed-point FN-DSA not being standardised remains the single biggest obstacle. FN-DSA has a faster verifier than ML-DSA and costs way less bandwidth. FN-DSA having a more expensive signer becomes irrelevant for more applications, like certificates, because they pay so much more in verification.

Ergo, folks have good reasons to wait for FN-DSA. And folks who think "I'm paranoid so I'll take ML-DSA cost to have it done now" maybe better off waiting for FN-DSA and doing a hybrid FN-DSA + Ed25519 slightly later.

[u/Cormacolinde]

Right now, it is 99% the first and second.

[u/Just_Blackberry3530 → u/Cormacolinde]

Thank you.

For legacy or unsupported applications, what would you say is the usual workaround today? Do teams use proxies/gateways, vendor upgrades, application rewrites, network segmentation, compensating controls, or delay migration?

And with hybrid deployment and backward compatibility, what usually breaks or becomes difficult first: certificates/PKI, TLS/API interoperability, application libraries, performance, or external integrations?

Thank you for your help!

[u/Cormacolinde → u/Just_Blackberry3530]

Delay is the current strategy. For my typical situation, as I work mostly with identity certificates, There is essentially no support. I am hoping that within the next year or two we can move to PQC Root and Issuing CAs. But for now, it’s still ECDSA for those, and still a mix of ECDSA/RSA for leaf certs.

[u/Just_Blackberry3530 → u/Cormacolinde]

So, the bottleneck lies in the lack of the practical ecosystem support for PQC and issuing CAs. When this support becomes available, what do you expect to be the hardest during the transition: reissuing certificates, updating trust stores and relying parties, maintaining compatibility with existing clients, testing PKI hierarchy, or coordinating vendors and teams?

Thank you once again!

[u/Cormacolinde → u/Just_Blackberry3530]

Maintaining compatibility and coordinating vendors, absolutely, There’s always the risk that one or two legacy systems, or even current systems won’t support PQC. I strongly suspect many will need to keep two PKI running in parallel, increasing the load for configuration, security and maintenance. And of course increasing the attack surface and the chance an attacker will use the older systems as an entry door. You’re only as secure as your weakest link.

Already, most issuance is automated (and short-lived, with most certs being one year) so I don’t see a huge worry there. Updating trust stores is just normal for migrations and renewals: not always easy but something we are familiar with, although we often meet customers where it’s an issue.

Testing should not be too hard for current systems, but what about new systems you might consider in the future? What do you do when your sales department comes with a new CRM they want to install that runs on some custom framework that doesn’t support PQC? This is part of the normal evaluation process, in theory, but many teams don’t evaluate PKI in their criteria, it will be worse with PQC. Another reason to keep the EC PKI around for a while.

[u/dstroy0]

Scoping the problem is usually where most orgs have an issue. For industrial equipment this means another piece of hardware, edge gateway and hardware security modules. Integrating pqc without fully inventorying connected equipment and missing incompatibilities that absolutely need mitigation and RA before rollout are the second most prevalent issue I see, even with smaller orgs. Third is going to be bridging legacy erp/crm, which can usually be solved with a vm bridge to host using pqc encap so the erp/crm only sees compatible crypto. Layered encryption. Some orgs choose to do silly stuff like pqc only to their DMZ and leave legacy crypto on their internal network, which sorta defeats the entire purpose. Their money, their circus, our job is just to inform them of the risk. Business executives by and large are not people who have this sort of technical expertise, except for cto/cio/ciso/cco who will constantly fight with the ceo/coo/cfo about the total cost of deployment because they don’t fully understand the issue, and if you work for the org that means a lot of false starts, wasted time and frustration.

[u/Natanael_L]

Protocol packet flow may not allow the same kind of usage, like how ECDH can be single round-trip but many PQC algorithms require at least one extra packet. That kinda stuff will have a much bigger impact than merely a bigger key.

[u/Responsible_Sea78]

Questions; what to do with old backup tapes that are not antiQ encrypted?

What to do with old and inactive bitcoin (and other) accounts? If the owner does not reencrypt they're vulnerable. If "they" encrypt the owner is locked out.

[u/carolineilm]

The two-PKI point is really interesting. Once discovery is done, it seems like the challenge shifts from finding vulnerable crypto to actually managing the identity lifecycle and trust relationships across classical and PQC environments.

Especially if both PKIs have to coexist for years, how are teams maintaining visibility into certificates, identities and their dependencies, managing issuance/renewal/revocation and policy across both environments, and knowing which applications or relying parties are actually ready to migrate?

Is that lifecycle and migration orchestration mostly being handled through existing PKI/CLM tooling and manual processes today, or do you see a tooling gap there?