Seeking Insights on Post-Quantum Cryptography Migration Challenges

[ghost]

Hello,

My name is Aastha Tammara. I am a rising high school senior researching post-quantum cryptography and crypto-agility.

I am interested in learning the real-world challenges organizations encounter during PQC migration. While I'm still learning about the field, I hope to gain insights from practitioners and experts.

I'd love to hear your perspective regarding the following queries:

1. What are the biggest challenges organizations face when preparing for PQC?
2. Which aspects of the transition are difficult/time-consuming?
3. Are there any specific pain points in cryptographic discovery, inventory, migration, compliance, or reporting?
4. If you could improve one aspect of the current PQC transition process, what would it be?

Thank you for your time. I appreciate any insights you are willing to share.

[Kxrma47]

The hardest part of PQC migration is usually not selecting ML-KEM or ML-DSA; it is finding every place where cryptography is used and changing it without breaking protocols, devices, certificates, compliance controls, or long-lived data.

The recurring practical challenges are:

• Incomplete inventory. Cryptography is hidden in TLS termination, service meshes, VPNs, SSH, databases, backups, mobile apps, firmware, HSMs, third-party SaaS, libraries, and proprietary protocols. Asset inventories often record products but not algorithms, key sizes, certificate chains, or data-retention requirements.
• Dependency and vendor readiness. An application may be ready while its load balancer, HSM, client SDK, certificate authority, browser, or embedded device is not. Migration therefore follows the slowest interoperability dependency.
• Larger artifacts. PQ keys, ciphertexts, and signatures can increase handshake, certificate, firmware, and message sizes. This exposes MTU/fragmentation assumptions, fixed database fields, protocol limits, smart-card memory limits, and latency-sensitive links.
• Crypto agility gaps. Algorithm names and lengths are frequently hard-coded. Formats lack versioning, protocols cannot negotiate new combinations, and old encrypted data has no documented re-wrapping path.
• Hybrid complexity. During transition, many systems need classical plus PQ protection. Hybrid combiners, downgrade handling, certificate representation, monitoring, and failure behavior must be specified rather than improvised.
• Assurance and compliance lag. Organizations need approved implementations, FIPS-validation plans, SBOM/provenance, test vectors, key-management procedures, and evidence that auditors can reproduce.

Discovery is particularly difficult because network scans see only externally negotiated cryptography. A useful inventory combines configuration/code scanning, runtime observations, certificate/key inventories, dependency/SBOM data, HSM/KMS records, and owner interviews. Every finding should map to an application owner, data lifetime, exposure (“harvest now, decrypt later”), replacement dependency, and target date.

If I could improve one part, it would be a living cryptographic bill of materials tied to the normal asset and dependency lifecycle. A one-time spreadsheet becomes obsolete immediately. The inventory should be continuously generated where possible and should record algorithm, protocol, implementation/version, key location, purpose, data lifetime, external dependency, and migration status.

A practical sequence is:

1. prioritize long-confidentiality data and externally exposed key establishment;
2. establish inventory and ownership;
3. remove hard-coded algorithms and introduce versioned formats/interfaces;
4. test standardized hybrid deployments in representative networks;
5. capture performance, size, interoperability, rollback, and downgrade evidence;
6. migrate in stages while retaining an emergency rollback that does not silently weaken policy.

Authoritative resources include NIST's PQC migration project and finalized standards, plus OQS's prototype integrations:

• https://csrc.nist.gov/projects/post-quantum-cryptography
• https://csrc.nist.gov/projects/crypto-agility
• https://github.com/open-quantum-safe/liboqs
• https://github.com/open-quantum-safe/oqs-provider

For research, interviewing practitioners around one concrete workflow (for example TLS termination, firmware signing, or archive encryption) will produce more actionable findings than asking about “PQC migration” as a single organization-wide task.

[Johnbjoseph-cybersec]

Great topic. The earlier reply in this thread has the headline right: choosing ML-KEM or ML-DSA is the easy part. Here is how your four questions tend to play out in practice.

1. Biggest challenge: you cannot migrate crypto you cannot see. Cryptography is rarely in one place. It lives in TLS stacks, transitive libraries, firmware, HSMs, long-lived certificates and roots of trust, signed update channels, and SaaS and vendor products you do not control. Picking an algorithm is a decision; finding every use is an archaeology project.

2. Why it is urgent despite far-off deadlines: two clocks. The migration clock follows guidance like NIST IR 8547, which proposes deprecating RSA/ECC around 2030 and disallowing them after 2035. But the "harvest now, decrypt later" clock already runs: anything with a long confidentiality lifetime is being recorded today to decrypt once a quantum computer exists. So long-lived data and secrets often must move first.

3. Hardest, most time-consuming parts, by phase:

• Discovery: no single source of truth; crypto hides in code, config, certs, protocols and binaries, each needing a different tool.
• Inventory: it goes stale the next deploy, so it has to be regenerated continuously, not kept in a spreadsheet.
• Migration: the new primitives are much larger (ML-DSA signatures are kilobytes, not ECDSA's ~64 bytes), which breaks packets, fields and hardware that assumed small keys; hybrid adds interop complexity; and the long tail is whatever you do not own.
• Compliance/reporting: the real gap is evidence: regulators will ask "prove you are PQC-ready," and most orgs cannot.

4. What I would change: treat cryptography as a managed, inventoried asset, not a one-off. Keep a machine-readable Cryptography Bill of Materials (CBOM; CycloneDX added crypto-asset support in spec 1.6) and regenerate it in CI so the inventory stays current. That turns "are we ready?" into a report, and makes crypto-agility real, since you will migrate again after ML-DSA.

A concrete starting point: take ONE workflow end to end, say firmware/code signing or TLS termination, and map the full key lifecycle, generation, storage, use, rotation, retirement, marking every point where an algorithm or key size is assumed. That one exercise teaches the whole problem, and the pain points you hit are the ones organizations report. FIPS 203/204/205 were finalized in August 2024, so the primitives are settled; the migration is now a discovery and agility problem.

— John B Joseph, Co-founder & CPTO, Purplecop Security