Post-Quantum Cryptography Migration: Engineering Guide for 2026

Introduction

Post-quantum cryptography (PQC) migration is no longer a research project. With NIST finalising ML-KEM, ML-DSA, and SLH-DSA as FIPS 203, 204, and 205 in mid-2024 and the US National Security Memorandum 10 setting a 2033 hard deadline for national security systems, the strategic question for CIOs in 2026 is not whether to migrate but how to sequence a multi-year cryptographic transition without breaking existing systems. Indian regulators and operators in payments, telecom, and defence are watching closely and are likely to issue PQ migration guidance through 2026-28.

This guide is for security architects, platform engineers, and CISOs who need a defensible PQC roadmap. We cover the threat model, the standardised algorithms, the migration patterns (hybrid, dual-stack, crypto-agile), the operational pitfalls, and a concrete 24-month plan an Indian enterprise can start on Monday.

Background: The Threat Model

The fundamental assumption underlying RSA, ECDH, ECDSA, and DSA is that certain mathematical problems — integer factorisation and discrete logarithm — are computationally infeasible on classical computers. Shor’s algorithm, published in 1994, demonstrated that a sufficiently large quantum computer running on a stable enough qubit substrate could solve both problems in polynomial time.

As of 2026, the largest demonstrated quantum computers (IBM Condor at 1,121 qubits, IBM Heron at 156 high-fidelity qubits, Google Willow at 105 qubits with error correction) are not capable of running Shor’s algorithm against a real RSA-2048 key. Most credible estimates place the cryptographically-relevant quantum computer (CRQC) somewhere between 2030 and 2040.

Why migrate now, then? Two reasons that operate on different timescales.

Harvest-now, decrypt-later (HNDL). An adversary capable of bulk-capturing encrypted internet traffic today — nation-state SIGINT agencies, certain submarine-cable taps, large-scale ISP-level interception — can store that traffic for decades and decrypt it when CRQC capability arrives. Any data whose confidentiality must survive 10+ years (health records, intellectual property, diplomatic communications, biometrics, customer KYC data) is already at risk if it crossed the public internet under classical key agreement.

Migration takes years. Replacing the cryptographic substrate of a large enterprise is not a software upgrade; it is a multi-year program touching every TLS terminator, every HSM, every signed firmware artefact, every PKI hierarchy, every code-signing pipeline, every JWT issuer, every database column encryption setting. Organisations that start in 2030 will not finish by 2035.

Theory: The NIST PQC Standards

The NIST PQC competition (2016-2024) standardised three primary algorithms and one signature algorithm for stateless hash-based signatures. Each addresses a different cryptographic primitive.

ML-KEM (FIPS 203, formerly Kyber). A key encapsulation mechanism based on Module Learning With Errors (MLWE). Three parameter sets: ML-KEM-512 (~AES-128 security), ML-KEM-768 (~AES-192, the default), ML-KEM-1024 (~AES-256). Ciphertext sizes range from 768 to 1568 bytes — substantially larger than ECDH’s 32-byte exchange, with implications for handshake size, MTU, and CDN edge performance.

ML-DSA (FIPS 204, formerly Dilithium). A digital signature scheme also based on lattices. Three parameter sets at security levels 2, 3, and 5. Signature sizes 2,420 to 4,595 bytes — orders of magnitude larger than the 64-byte ECDSA-P256 signature. This matters for X.509 certificates, JWTs, code-signing artefacts, and DNS responses.

SLH-DSA (FIPS 205, formerly SPHINCS+). A stateless hash-based signature scheme. Slower than ML-DSA but with security based only on hash function preimage resistance, making it the conservative backup if a future cryptanalytic break is found in lattice schemes. Signatures range from 7,856 to 49,856 bytes.

A fourth algorithm, FALCON (NTRU-lattice-based signatures), is expected to be standardised as FIPS 206 in late 2026 for use cases where signature size dominates verifier-side cost.

Theory: The Hybrid Migration Pattern

The dominant deployment pattern for 2026-2028 is hybrid: concatenate a classical key-exchange (typically X25519) with a post-quantum KEM (typically ML-KEM-768). The shared secret is derived from both. The system is secure if either primitive holds.

Hybrid is the right choice during the transition for three reasons. First, the post-quantum standards are new, and cryptographers traditionally want a 5-10 year review window before betting everything on a single primitive. Second, hybrid lets you deploy PQ-capable systems even when the peer is still classical-only — you negotiate down gracefully. Third, hybrid mitigates the risk of a catastrophic cryptanalytic break in either primitive during the transition.

IETF has standardised hybrid TLS 1.3 key exchange (RFC 9764, October 2025) using the X25519MLKEM768 codepoint 0x11EC. As of May 2026, this is supported by:

• OpenSSL 3.5+ (out of the box)
• BoringSSL (Google production since late 2024)
• Cloudflare edge (default-on since March 2026)
• Chrome 124+ (default-on for HTTPS to supporting servers)
• Firefox 135+ (behind preference flag)
• NSS 3.99+ (Mozilla, RHEL)

Anything older — legacy F5 BIG-IP, Citrix NetScaler firmware before 14.1, older IBM WebSphere, most embedded MQTT brokers — will not negotiate the hybrid suite and will silently fall back to classical-only.

Technical Deep Dive: Crypto Agility

The deeper architectural lesson of PQC migration is that crypto agility — the ability to swap algorithms without rewriting application code — was always the right design pattern, and most enterprises do not have it. Three anti-patterns we see repeatedly:

Hardcoded cipher suites. Application code that hardcodes RSA_PKCS1_v1_5 or ECDSA-SHA256 at the call site, rather than asking a policy layer “what is the current signing algorithm for this purpose?” This is the most common pattern in fintech codebases.

Algorithm-coupled storage. Database columns sized exactly for one algorithm (a VARCHAR(64) for ECDSA-P256 signatures) that will not fit ML-DSA’s 2,420-byte output. Schema migrations on production databases at scale are expensive; doing them under cryptographic-emergency time pressure is worse.

Embedded certificates. Firmware images, mobile apps, and IoT devices that ship with an embedded root CA or pinned end-entity certificate using classical signatures. These cannot be updated without a firmware push. Devices shipped in 2024 with hardcoded RSA-2048 will still be in the field in 2034.

A crypto-agile architecture instead has:

from crypto_policy import sign, verify, current_signature_algorithm

# Application code never names an algorithm.
artefact = sign(data, purpose="firmware_release", key_id="firmware-2026-q2")

# Storage is algorithm-agnostic.
db.signatures.insert({
    "artefact_id": artefact_id,
    "alg": current_signature_algorithm("firmware_release"),
    "value": artefact.bytes,           # BYTEA / BLOB
    "key_id": "firmware-2026-q2",
})

# Verification consults the same policy layer at the time of verification.
verify(data, signature_row)

This sounds simple. It is not. Refactoring a 10-year-old Java codebase with 400 signing-and-verifying call sites into a single policy layer is a 6-month project on its own, and is the prerequisite for any sane PQ migration.

Technical Deep Dive: TLS Handshake Performance

The hybrid TLS 1.3 handshake is measurably slower than classical. Cloudflare’s published 2025 telemetry shows:

• X25519 alone: handshake median 1.4 ms server-side CPU, 1,189 bytes exchanged.
• X25519MLKEM768 hybrid: handshake median 2.3 ms server-side CPU, 2,221 bytes exchanged.
• Handshake size increase pushes some clients into TCP fragmentation, adding round-trip latency.

For most workloads this is invisible. For high-frequency trading, ad-tech RTB, and high-volume API gateways, the per-handshake increase is a real CPU and latency cost that must be modelled.

Mitigations include: session resumption (resumed handshakes do not re-perform key exchange), QUIC’s 0-RTT (which has its own replay-attack tradeoffs), and HSM offload for the lattice operations on systems where the HSM has been firmware-upgraded to support ML-KEM.

Practical Implementation: The 24-Month Migration Plan

Here is a defensible sequence for an Indian enterprise starting in Q3 2026:

Phase 1 (Months 1-3): Inventory. Build a Cryptographic Bill of Materials (CBOM) using CycloneDX 1.6’s crypto-asset support. Scan source code for hardcoded algorithm names; scan certificates for issuer-and-subject algorithm OIDs; scan running processes for loaded crypto libraries (OpenSSL, NSS, BoringSSL, BouncyCastle, native Windows CNG). Output: a complete list of every cryptographic dependency, its purpose, its lifetime sensitivity, and its agility status.

Phase 2 (Months 4-6): Crypto-agility refactor. For the top 10 hardcoded call sites by criticality, refactor to a policy layer. Update database schemas to accept larger signature sizes. This is where most of the cost lives.

Phase 3 (Months 7-12): Hybrid TLS rollout. Enable X25519MLKEM768 on edge terminators first (CDN, ALB, API gateway), then internal service mesh (Istio 1.25+ supports it), then internal RPC. Monitor handshake latency; tune session caching.

Phase 4 (Months 13-18): Signing algorithms. Roll out dual-signed code artefacts (classical + ML-DSA). Issue new code-signing certificates with ML-DSA leaves under classical roots. Begin re-signing long-lived firmware images.

Phase 5 (Months 19-24): PKI hierarchy. Stand up a parallel PQC root CA (ML-DSA-87) with cross-signed intermediates back to the classical root. Begin migrating customer-facing certificates as TLS terminators support PQC end-entity certificates.

Enterprise Use Cases

BFSI. The HNDL risk is highest for banking sector data — KYC, transaction history, and biometrics retain commercial and identity value for decades. Once the central payments switch adopts hybrid PQ-TLS, every member bank’s CIO will face a downstream 24-month conversation about internal migration. Bank CIOs should expect a future RBI directive in this direction over 2027-28.

Healthcare. Patient data has multi-decade confidentiality requirements. ABDM-connected providers should plan PQ rollout for FHIR endpoints by 2028.

Government / defence. NCIIPC’s protected-system criteria already include long-term confidentiality requirements. Expect explicit PQ mandates in the next CIPF revision.

Telecom. 5G core authentication uses ECC; 6G standardisation explicitly assumes hybrid PQ. Operators replacing core elements through 2027-28 should require PQ readiness in RFPs.

Common Pitfalls

• “We will wait until quantum is real.” By then your migration window has closed. HNDL is already happening.
• “We will skip hybrid and go straight to pure PQC.” A break in ML-KEM during the transition would leave you with no fallback. Hybrid is the conservative path.
• “Our HSM vendor will handle it.” Check the firmware version. Most HSMs shipped before 2024 cannot do ML-KEM in hardware and will fall back to slow software paths.
• “This is a TLS problem.” TLS is the easy part. Code signing, document signing, JWTs, S/MIME, and embedded device certificates are harder and slower to migrate.

Action Items for Monday Morning

• Run cyclonedx-py crypto or cbomkit against your largest service to produce a draft CBOM.
• Convene a “crypto inventory” working group spanning platform, security, and applications.
• Add a clause to all new vendor contracts requiring PQ readiness disclosure.
• Brief your board on the 24-month transition and the funding implication.
• Subscribe to the NIST PQC mailing list and the IETF TLS WG to track the standard evolving in real time.

PQC is the single largest cryptographic transition since the deprecation of SHA-1. Organisations that treat it as a 2030 problem will find themselves under-resourced in 2028. The CIOs who win the next decade are the ones who start the inventory this quarter.