Challenges in PQC Adoption

What makes PQC adoption difficult

PQC adoption changes cryptographic algorithms, but the consequences reach protocols, APIs, certificates, key management, hardware, firmware, applications, and operating procedures. The transition is unusually broad because existing systems rely on public-key cryptography for encryption, key exchange, authentication, signatures, and trust infrastructure. Applications may need code refactoring, extensive testing, protocol changes, and user-interface changes to accommodate new key sizes and performance characteristics. The appropriate scope and sequence depend on the system, its data, and its dependencies.12

It is useful to separate three risk categories. Algorithm risk concerns the security assumptions and maturity of the selected scheme. Implementation risk concerns incorrect, incomplete, or insecure realization of an otherwise suitable algorithm, including weaknesses not detected by conformance tests. Migration risk concerns broken interoperability, unavailable vendors, incompatible protocols, operational error, or failure to update every dependent component. A standard or validated component addresses only part of this risk: NIST states that conformance of an implementation and use of a product do not guarantee security of the overall system.4536

Discovery: finding cryptography and its hidden dependencies

The first challenge is knowing where migration is required. Cryptography can be embedded in applications, databases, communication tools, cloud services, enterprise software, software libraries, firmware, hardware, PKI, certification authorities, registration authorities, key-management systems, directories, and personal or specialized devices. A simple search for an algorithm name is unlikely to reveal all uses because cryptographic operations may be cited indirectly through libraries, services, protocols, or hardware modules.21

Discovery must therefore record not only the algorithm but also its purpose, data sensitivity, confidentiality lifetime, certificate and trust relationships, protocol version, endpoint population, hardware dependencies, supplier, validation status, and replacement path. Hidden dependencies commonly appear when a certificate authority, trust anchor, HSM, smart card, reader, firmware image, or embedded client cannot process the proposed format. The inventory should identify systems that cannot be upgraded in place and systems whose suppliers or regulators control the schedule.21

A practical mitigation is to build a cryptographic inventory and prioritize it by exposure and consequence. Give earlier attention to long-lived sensitive information and critical infrastructure, including data vulnerable to harvest-now-decrypt-later attacks. Use pilots to verify the inventory against real traffic and deployment behavior. This does not require replacing every component at once; it creates evidence for deciding which systems need immediate action, which can be tested next, and which have lower risk or stronger legacy constraints.2178

Protocol, format, and interoperability constraints

PQC schemes can require changes to protocol messages, negotiation, certificate formats, key management, and application interfaces. A protocol may impose fixed message limits, assumptions about packet size, or a restricted number of exchanges. ETSI identifies IKEv2 initial-exchange size limits and the risk that many post-quantum public keys will not fit without fragmentation. Hybrid approaches can preserve compatibility with clients that do not yet support PQC, but different hybrid constructions can provide different security guarantees, efficiency, and complexity.35

Interoperability is not automatic merely because both endpoints support a named algorithm. Teams must agree on encoding, negotiation, transcript handling, component selection, key derivation, key reuse rules, failure behavior, certificate processing, and downgrade resistance. A hybrid scheme also has a defined purpose: confidentiality, authentication, interoperability, or implementation protection may require different properties. RFC 9794 notes that one hybrid scheme cannot achieve every possible property, so requirements should be stated before selecting a construction.35

Mitigate these risks with standards-based profiles, explicit test vectors, negative testing, downgrade testing, cross-vendor interoperability trials, and staged rollout. Preserve traditional components only where the security objective, compatibility requirement, protocol constraint, or validation condition justifies them. Do not assume that adding components automatically improves security; document the intended hybrid property, manage each component’s keys correctly, and define how the system will retire the transitional mode.531

Larger artifacts, performance, and constrained environments

Many PQC deployments have a measurable data-plane and control-plane cost. PQC keys, ciphertexts, and signatures can be substantially larger than traditional public-key artifacts; the cited engineering material describes sizes ranging from hundreds of bytes to more than one hundred kilobytes. Larger messages can increase handshake latency, bandwidth consumption, energy use, storage requirements, and fragmentation complexity. Hybrid protocols can add further data and, in some designs, additional round trips.913

Performance is not a single property of an algorithm. It varies with the selected parameter set, platform, implementation, workload, network, and whether a traditional component is used alongside PQC. Constrained devices and low-rate networks are especially sensitive, while high-throughput services may encounter CPU, memory, queueing, or certificate-processing effects. The right question is not whether PQC is universally fast or slow, but whether the complete protocol and workload meet the system’s service and energy objectives.913

Mitigate performance risk through representative benchmarking before broad deployment. Measure handshake size, round trips, CPU, memory, latency, throughput, energy, retransmission, fragmentation, certificate-chain processing, and failure recovery. Test production-like network paths and constrained hardware rather than relying only on laboratory results. Where a hybrid design is used, benchmark the complete combination and assess whether its compatibility benefit justifies its overhead.392

Implementation maturity, side-channel resistance, and validation

A mathematically specified algorithm still has to be implemented securely in software, firmware, hardware, or a combination of these. Implementers must address randomness, memory handling, error behavior, key protection, performance optimizations, and resistance to implementation attacks, including side-channel concerns. The source set does not provide a complete side-channel test methodology, so organizations should not infer that algorithm standardization alone establishes side-channel resistance.453610

Validation is important but bounded. NIST SP 800-227 explains that validation testing checks correct output for only a small number of, often randomly sampled, inputs. It therefore does not guarantee correct functioning on all inputs, and it does not establish the security of the complete module or system. Digital-signature standards likewise provide for conformance testing, while responsibility for secure implementation remains with the implementer and responsible authority.6410

Mitigation should combine conformance testing with independent code review, secure engineering, known-answer and negative tests, fuzzing, fault and error-path testing, key-lifecycle review, side-channel evaluation appropriate to the threat model, and system-level assessment. Track validation status separately from product security claims and from the security of the deployment. For regulated environments, include accreditation, module validation, recertification, and evidence-retention activities in the schedule.6410

Vendor readiness, legacy systems, skills, and governance

Migration depends on more than an organization’s own engineering capacity. Vendors may need time to implement PQC functionality, complete audits and certification, and deliver updated products. Regulators may need to adopt policies, and auditors may need to become familiar with new requirements. Legacy systems may include smart cards and readers, TPMs, trusted execution environments, secure enclaves, cryptographic coprocessors, or devices that cannot receive a software-only update. Replacement, integration, testing, auditing, and recertification can each extend the schedule.

Operational change is equally important. PKI teams must update certificate issuance, distribution, validation, revocation, trust anchors, and key-pair handling. Security and platform teams need skills in new algorithms, protocol behavior, testing, performance analysis, and crypto-agile operation. Governance must assign owners, approve risk thresholds, record exceptions, monitor supplier commitments, and define exit criteria for legacy or hybrid modes. Without these controls, an organization can complete a technical pilot yet fail to complete the migration.21

Mitigate organizational risk by creating a cross-functional migration program with asset owners, security architects, procurement, legal and compliance, operations, application teams, and suppliers. Require vendor road maps and test access for critical dependencies. Develop training and runbooks, rehearse rollback and incident response, and maintain an exception register with expiry dates. Design new interfaces and deployment controls for crypto agility so that future algorithm changes can be managed without replacing every application or infrastructure component.

Why the transition takes years

A long transition is not evidence that action should wait. The migration period includes discovery, design, procurement, integration, testing, auditing, certification, deployment, and the retirement of the final vulnerable device or protocol. The full tail can therefore extend for years, especially where vendors, regulators, auditors, hardware replacement, or long-lived embedded systems are involved. Long-lived confidential data and critical systems may warrant earlier work than lower-risk systems, while legacy constraints can justify a different sequence.21

A practical sequence is: establish governance and inventory; classify data and systems by risk and lifetime; identify dependencies and supplier constraints; select standards-based candidates; prototype key exchange and signatures separately; test interoperability and performance; deploy controlled pilots; expand through prioritized waves; and monitor algorithm, implementation, vendor, and policy developments. NIST’s current project material identifies ML-KEM, ML-DSA, and SLH-DSA as the foundation expected for many deployments, while additional algorithms remain under ongoing standardization. That continuing work is a reason to design for change, not a reason to abandon concrete migration planning.78

Conclusion

PQC adoption is difficult because cryptography is distributed across technical, organizational, and supplier boundaries. The main risks are discoverability, dependency and protocol constraints, larger artifacts, performance, implementation assurance, interoperability, vendor and legacy readiness, and the operational discipline required for a long transition. Organizations can manage these risks by inventorying first, prioritizing long-lived and high-consequence data, testing complete systems, validating implementations without overstating what validation proves, using hybrid approaches deliberately, and investing in crypto agility. A phased plan supports timely action while allowing lower-risk or constrained systems to follow an evidence-based schedule.12