Topic starter
23/06/2026 6:59 pm
TL;DR: 9958 shows how post-quantum cryptography can run into protocol limits, with DigiCert’s case work pointing to handshake failures, fragmentation, and brittle middleboxes. Cryptographic change will need careful sequencing and rollback on real network paths, not just algorithm selection.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “RFC 9958: A field guide to post-quantum cryptography migration”.
Key questions
Q: Why does post-quantum cryptography create operational risk for mobile and distributed systems?
A: Post-quantum cryptography can increase key sizes, processing demands, and protocol overhead, which affects network traffic, hardware compatibility, and battery life.
Q: Where do PQC migrations usually fail in practice?
A: They often fail in brittle paths such as older stacks, MTU-sensitive links, UDP-heavy protocols, deep proxy chains, and systems with hard-coded size limits.
Q: What should teams do first when planning PQC migration?
A: Start by inventorying every place public-key cryptography is used, including TLS, service-to-service identity, code signing, device enrollment, and signature-based authentication.
Practitioner guidance
- Inventory public-key dependencies Map every place public-key cryptography appears, including TLS termination, service-to-service identity, code signing, device enrollment, and signature-based authentication flows.
- Test brittle paths first Prioritise MTU-sensitive links, UDP-heavy protocols, older stacks, deep proxy chains, and systems with hard-coded handshake or message-size limits.
- Define hybrid use cases explicitly Document where hybrid cryptography is a temporary bridge, where it is necessary for compatibility, and where it adds cost without enough risk reduction.
Bottom line: PQC migration exposes a systems risk, not just a cryptographic selection problem, because protocol limits and operational dependencies can break before the new algorithms do.
Glossary terms: Quantum Cryptography Migration, Hybrid Cryptography, Crypto-Agility, Protocol Bloat
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 22 hours ago by NHI Mgmt Group
25/06/2026 2:44 am
Crypto migration is now an identity infrastructure problem, not a library upgrade. The article makes clear that the failure surface spans certificates, service authentication, code signing, and long-lived data protections, which is exactly where IAM and PKI programmes already carry operational risk. When public-key assumptions change, the governance question becomes whether the environment can absorb that change without breaking trust paths. Practitioners should treat PQC readiness as part of identity lifecycle management, not a separate cryptography project.
A question worth separating out:
Q: How should security teams plan a hybrid cryptography migration for quantum-safe certificates?
A: Security teams should plan hybrid cryptography as a migration bridge, not a permanent end state. The practical goal is to support both PQC-capable and non-PQC-capable endpoints while preserving trust during transition. That usually means defining which systems can accept backward-compatible hybrid certificates, which require parallel PKI paths, and when a hard cutoff becomes safe. Governance and endpoint inventory drive the sequence.
👉 Read our full editorial: PQC migration is really a cryptographic systems problem