Post-Quantum Cryptography: Standards, Migration Pathways, and Workforce Readiness

The Migration Problem

The algorithms exist. NIST published its first post-quantum cryptographic standards in 2024: ML-KEM (CRYSTALS-Kyber) for key encapsulation, ML-DSA (CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (SPHINCS+) for hash-based signatures [7]. Standards exist. What does not exist, at any meaningful scale, is the organisational capability to deploy them.

This has stopped being a cryptographic problem. It is a people problem and a software engineering problem that happens to wear a cryptography hat. The companion theoretical review covered the mathematical foundations. This article turns to the harder question: whether the engineering, educational, and organisational infrastructure can be built in time.

NIST Standardisation: What It Settled and What It Left Open

What NIST Resolved

The NIST PQC competition (2016-2024) resolved the primary algorithm selection question through an open, multi-round evaluation process:

What Remains Open

Code-based KEM candidates (HQC, BIKE) remain under fourth-round evaluation. If standardised, they would provide algorithm diversity beyond the lattice family, which matters for systemic risk management [7].

Post-quantum zero-knowledge proofs account for roughly 13% of recent PQC publications [4], but mature constructions ready for standardisation do not yet exist.

Interoperability testing across implementations (liboqs, BouncyCastle, AWS-LC, wolfSSL) is still ad-hoc. No systematic cross-implementation validation programme exists.

Research Mapping

Song and Kim applied LDA topic modelling to 189 PQC papers published in the year following NIST’s 2022 announcement [4]. The distribution reveals where research effort concentrates:

Observation: NIST-related topics (hardware acceleration + candidate analysis) account for 39% of all PQC research activity, confirming that the standardisation process is the dominant organising force for the field.

Automated Code Migration: ccPASTpqc

The most novel contribution in the migration space comes from Wahlang and Vidhani, who apply code language models (CLMs) to automate the translation of quantum-vulnerable Python code to PQC-safe equivalents [5].

The Problem

Enterprise codebases are littered with cryptographic call sites. from Crypto.PublicKey import RSA. nacl.public.PrivateKey(). ec.generate_private_key(ec.SECP256R1()). Each one needs to be found, understood, and replaced. Manual migration at enterprise scale is slow enough to be measured in years rather than sprints, and Mosca’s inequality tells us that migration time (T) is the one variable organisations can actually compress. That is ccPASTpqc’s target.

The Approach

1. Dataset creation: Manual construction of parallel classical → PQC Python program pairs from four libraries (PyCryptodome, PyNaCl, Cryptography, OpenSSL) and their PQC counterparts (pqcrypto, liboqs-python)
2. Data augmentation: 11 variant-generation techniques expanding the training set
3. Model fine-tuning: CodeT5 (Seq2Seq transformer) fine-tuned on the parallel corpus
4. Novel chunking: Pairwise AST-based chunking that preserves semantic alignment between source and target programs, overcoming context-length limitations

Results and Limitations

Critical caveat: A 0.925 BLEU score tells you the output text looks like correct code. It does not tell you whether the code compiles, passes tests, or preserves the security properties of the original implementation. The translated GitHub code was never execution-tested [5]. Anyone who has spent time debugging LLM-generated code knows the gap between “syntactically plausible” and “silently violates an invariant that a human developer would catch by instinct.” For production migration, execution testing and security auditing of every translated function are non-negotiable.

Practical gap: Most production cryptographic code lives in C, C++, Java, and Go. ccPASTpqc covers Python only. This is a proof of concept, not a migration tool you can hand to your engineering team and walk away.

What Practitioners Should Do Now

• Use ccPASTpqc-style tools for initial translation drafts, then review and test manually
• Invest in cryptographic dependency inventories before migration (you cannot migrate what you have not catalogued)
• Prioritise asymmetric key operations (symmetric encryption requires only key-size increases)

Hybrid QKD/PQC Network Architectures

Shim et al. propose a practical network architecture combining quantum key distribution (QKD) with PQC algorithms within TLS 1.3 [6]. The architecture addresses a fundamental limitation of QKD: it requires dedicated quantum hardware on every network segment, which is infeasible for wide-area networks.

Architecture Design

The hybrid approach segments the network into zones:

1. QKD-protected zones: Metropolitan-area links with installed quantum hardware use QKD for key distribution
2. PQC-protected zones: Long-haul and access network segments without quantum hardware use PQC algorithms within TLS 1.3
3. Bridge zones: Quantum Key Management Systems (QKMS) translate between QKD-derived keys and PQC-encapsulated keys

TLS 1.3 PQC Integration

The extensible design of TLS 1.3 supports PQC integration through two mechanisms:

• key_share extension: Carries PQC KEM ciphertexts alongside or instead of classical ECDH shares
• signature_algorithms extension: Advertises support for PQC digital signatures (ML-DSA, SLH-DSA)

This means PQC slots into the existing TLS protocol framework without protocol-level redesign. No new wire format. No renegotiation of the handshake state machine. That is a critical practical advantage over QKD, which demands entirely new physical infrastructure at every hop.

The Workforce Readiness Gap

Three independent studies, from different countries and targeting different audiences, arrive at the same uncomfortable finding: the technical tools for PQC migration exist, but trained practitioners do not. Not at scale. The evidence comes from small programmes, and the confidence we can place in their generalisability is limited, but the consistency of direction across uncoordinated efforts is worth noting.

Evidence from Three Educational Programmes

Key Pedagogical Insights

Bottom-up teaching outperforms top-down. Start with simple worked examples; build toward complex cryptosystems. Borrelli et al. found this more effective than presenting abstract definitions first [1]. One exception: graduate students with mathematical maturity benefited from top-down presentations. The implication is clear: differentiated pedagogy is necessary, not optional.

The name “Post-Quantum Cryptography” actively misleads. Students consistently interpreted it as “cryptography that uses quantum computers” rather than “cryptography that resists quantum computers” [1]. Small nomenclature problem; enormous pedagogical consequences. Borrelli et al. suggest “Quantum-Resistant Cryptography” as a clearer alternative, and having watched students struggle with the term myself, I suspect they are right.

Exposing individual operations matters more than you would expect. Standard tools like GPG and OpenSSL abstract cryptographic operations behind protocol-level interfaces. Learners never see what each step does. Steinfeld et al. built a custom software interface for CRYSTALS-Kyber that exposes key generation, encapsulation, and decapsulation separately [3]. The result: non-programmer cybersecurity professionals could understand operations they had previously treated as black boxes.

Modular embedding is the scalable path forward. Full PQC courses require curriculum approval processes that can take years. The modular approach sidesteps this entirely. Borrelli et al. define two tiers [2]: awareness modules (no prerequisites, suitable for high school onward, covering why current cryptography is vulnerable) and proficiency modules (requiring existing cryptography background, covering algorithm design, implementation, and NIST standard evaluation).

Workforce Strategy Recommendations

The evidence base here is thin. Three programmes at three institutions, with the largest cohort numbering 21 students. Generalisability beyond these specific contexts is unvalidated. That said, the directional findings are consistent enough to inform early planning, with the caveat that these are hypotheses worth testing at scale rather than proven prescriptions:

1. Immediate: Deploy awareness-level PQC training across IT and security teams. This requires no curriculum restructuring and can be run as half-day workshops. The bar is low: staff should understand what the quantum threat changes and what it does not.

2. Short-term: Establish proficiency-level training for cryptographic engineers and security architects, using hands-on tool interaction with individual operations exposed (the PQCIP model). Whether the custom-tool approach from Steinfeld et al. transfers to other institutions and audiences is an open question.

3. Medium-term: Embed PQC modules into existing computer science and cybersecurity degree programmes. The modular approach sidesteps curriculum approval bottlenecks, which is its primary advantage.

4. Ongoing: Maintain crypto-agility as an organisational competency, not just a technical property. When NIST publishes a deprecation notice or a new attack surfaces, the response time should be measured in weeks, not quarters.

Migration Planning Framework

Synthesising the migration-related findings yields a practical framework:

Phase 1: Inventory and Assess

• Catalogue all asymmetric cryptographic operations across the codebase
• Map data sensitivity lifetimes (D) and estimate migration time (T)
• Apply Mosca’s inequality ($D + T > Q$) to prioritise categories
• Identify cryptographic libraries in use and their PQC support status

Phase 2: Pilot and Validate

• Deploy PQC in non-critical internal systems first
• Test hybrid PQ/T certificates for backward compatibility
• Evaluate automated migration tooling (ccPASTpqc for Python; manual review for other languages)
• Benchmark PQC performance impact on latency-sensitive operations

Phase 3: Gradual Rollout

• Enable PQC in TLS 1.3 via key_share and signature_algorithms extensions
• Deploy dual-signature certificates during transition
• Monitor for compatibility issues across client populations
• Maintain classical fallback paths

Phase 4: Completion and Monitoring

• Remove classical-only configurations once client population supports PQC
• Establish ongoing cryptographic monitoring for algorithm deprecation announcements
• Maintain crypto-agility for future algorithm rotations

Takeaways

NIST resolved the algorithm question. The harder problem, organisational readiness, remains largely untouched. Workforce capacity, not algorithm availability, is the binding constraint on migration timelines. Three educational programmes point in a consistent direction (modular, bottom-up, hands-on), but the evidence base is narrow: small cohorts at single institutions, one programming language, no longitudinal outcome data.

Automated migration tooling shows promise. ccPASTpqc achieves 0.925 BLEU on Python conversions, which is encouraging for draft generation but tells us nothing about functional correctness. No execution testing validates the output, and production languages (C, C++, Java, Go, Rust) lack equivalent tooling entirely. Treat it as a starting point for human review, not a substitute for it.

Hybrid QKD/PQC network integration works within the TLS 1.3 extensibility model, which removes the protocol-redesign concern. The remaining work is practical engineering: zone-based deployment, QKMS bridge infrastructure, interoperability testing with existing certificate authorities. None of this has been validated at production scale.

The migration timeline is governed by Mosca’s inequality. Organisations should compute $D + T$ for each data category and treat the result as a deadline, not a planning target.

Practitioner Questions on Migration and Readiness

How long does a typical PQC migration take for an enterprise?

There is no typical case yet. Migration timelines depend on codebase size, cryptographic dependency count, and how deeply classical algorithms are embedded in the architecture. Automated tooling can accelerate the Python fraction, but manual review is still necessary for every converted function. For large enterprises with heterogeneous stacks, expect a multi-year programme. The first step, inventorying cryptographic dependencies, can start immediately and is worth doing regardless of migration timeline.

Can TLS 1.3 support PQC without protocol changes?

Yes. TLS 1.3 was designed with extensibility in mind; the key_share and signature_algorithms extensions can carry PQC KEM ciphertexts and digital signatures within the existing handshake. No protocol redesign is required. This is one of the genuine practical advantages of PQC: the transport layer can evolve without breaking the protocol itself.

What programming languages does automated PQC code migration cover?

As of the papers reviewed here, only Python, through ccPASTpqc. Production cryptographic code in C, C++, Java, Go, and Rust requires manual migration or purpose-built tooling that does not yet exist. Given that most security-critical cryptographic implementations live in C and C++, the tooling gap is substantial.

Is “Post-Quantum Cryptography” the same as “quantum cryptography”?

No, and the confusion is not academic. Borrelli et al. found that students consistently misread “post-quantum” as meaning “cryptography that uses quantum computers” rather than “cryptography that resists quantum computers.” PQC runs on classical hardware with algorithms designed to survive quantum attacks. Quantum cryptography (QKD) uses quantum physics for key distribution. The term “Quantum-Resistant Cryptography” has been suggested as a clearer alternative.

Technical Appendix