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]. So the primitives are settled. Deployment capability? Virtually absent.

The cryptography is, frankly, the easy part. Organisations that cannot inventory their own key material will not swap algorithms on schedule; elegance of the replacement primitives is irrelevant when you lack a reliable asset register. The theoretical foundations article covered the mathematical underpinnings. This article asks the harder question: can engineering capacity, educational infrastructure, and institutional willingness converge before Mosca’s inequality closes the window? History suggests probably not without deliberate intervention.

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

NIST selected HQC for standardisation in March 2025, adding a code-based KEM to the portfolio alongside the lattice-based ML-KEM. Draft standardisation work is ongoing. BIKE was not selected. The HQC addition provides 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 Landscape 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()). Every single one needs finding, understanding, and replacing. At enterprise scale, manual migration measures in years, not sprints. Mosca’s inequality tells us migration time (T) is the one variable organisations can actually compress; ccPASTpqc targets exactly that bottleneck.

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 resembles correct code. Does it compile? Does it pass tests? Does it preserve the security properties of the original? Unknown. The translated GitHub code was never execution-tested [5]. Anyone who has spent time debugging LLM-generated code recognises the chasm between “syntactically plausible” and “silently violates an invariant that a human developer would catch by instinct.” Production migration demands execution testing and security auditing of every translated function. Full stop.

Let me push this further than the paper does. BLEU is the wrong instrument here. It measures n-gram overlap: how closely output text resembles a reference. Consider a translated function that calls the correct APIs in the wrong order, initialises a nonce deterministically instead of randomly, or quietly omits a key-derivation step. That function could score 0.9+ on BLEU while producing code that is functionally broken and cryptographically dangerous. What cryptographic migration tooling actually needs is semantic equivalence testing: does the output produce the same ciphertexts for the same inputs? Surface similarity metrics cannot answer that question. The fact that ccPASTpqc was evaluated without a single execution test is not merely a limitation. It is a methodological gap that undermines the central claim.

Practical gap: Most production cryptographic code lives in C, C++, Java, and Go. ccPASTpqc covers Python only. Proof of concept, not a deployable migration tool. You cannot hand this 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

TLS 1.3’s extensible design 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 arrive at the same uncomfortable finding. Different countries. Different target audiences. Same conclusion: 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. Still, consistency of direction across uncoordinated efforts warrants attention.

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.

One observation from watching how organisations actually handle cryptographic transitions: the workforce gap is not primarily a knowledge gap. Most security engineers can learn Kyber’s API in an afternoon. The real gap is operational confidence. Teams that have never rotated a production cryptographic primitive have no institutional memory of what goes wrong during the process: the certificate chains that silently downgrade, the legacy clients that negotiate away PQC, the monitoring blind spots where a hybrid handshake fails and nobody notices until the audit. That kind of operational muscle memory cannot be built from slide decks. It requires rehearsal on staging infrastructure, with deliberate failure injection, before anyone touches production.

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. Good. Now 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, zero longitudinal outcome data.

Automated migration tooling shows promise but carries a dangerous gap. ccPASTpqc achieves 0.925 BLEU on Python conversions, encouraging for draft generation, meaningless for functional correctness. No execution testing validates the output. Production languages (C, C++, Java, Go, Rust) lack equivalent tooling entirely. Treat the output as raw material for human review. Not a substitute.

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 PQC’s genuine practical advantages: 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