Post-Quantum Cryptography Migration: Where to Start in 2026

Cybersecurity

NIST finalised the post-quantum standards in 2024. The migration window is closing — quantum-capable adversaries are years away, but harvest-now-decrypt-later traffic is being recorded today. The pragmatic 2026 starter plan.

By Arjun Raghavan, Security & Systems Lead, BIPI · April 29, 2026 · 9 min read

NIST finalised the first three post-quantum cryptography standards in August 2024 — ML-KEM (Kyber) for key encapsulation, ML-DSA (Dilithium) and SLH-DSA (SPHINCS+) for digital signatures. By 2025 the major TLS implementations had hybrid PQ key exchange in the stack. By 2026 we expect the first regulatory deadlines (US federal systems must migrate by 2030; financial sector following close behind).

The migration is not 'turn on the new algorithms'. It is the largest cryptographic discontinuity since SHA-1 deprecation, with deeper protocol implications. Teams that wait until 2029 will be sprinting. Teams that started in 2025 are managing it as a multi-year program. Here is the 2026 plan we are running with clients now.

Threat model: harvest-now, decrypt-later

Quantum-capable adversaries are not yet here. The threat is still real because adversaries are recording encrypted traffic today and will decrypt it the moment a sufficient quantum computer exists. Anything you transmit today that retains value for 10 to 20 years (medical records, government secrets, financial settlement data, certain IP) is potentially compromised by harvest-now-decrypt-later.

The harvest threat does not apply to short-lived secrets. A session cookie expiring in an hour is not interesting to a quantum adversary in 2035. A diplomatic cable encrypted in 2026 might still be very interesting then.

Step one: cryptographic inventory

You cannot migrate what you have not inventoried. The first deliverable is a list of every place your systems use asymmetric crypto: TLS endpoints, code-signing pipelines, S/MIME or PGP usage, VPN concentrators, IoT firmware verification, blockchain wallets, JWT signing keys, certificate authorities, document signing.

For each entry: the algorithm, the key length, the lifetime of the secrets it protects, the renewal frequency. Spreadsheet is fine. The exercise typically takes a quarter. Most organisations are surprised by how many places asymmetric crypto lives.

Step two: prioritise by data lifetime

Sort the inventory by how long the protected data retains value. The top of the list is your migration priority.

1. 20+ years: government secrets, healthcare archives, certain financial settlement data, IP behind 20-year patents.
2. 5 to 20 years: most enterprise data, financial records, contracts under retention requirements.
3. 1 to 5 years: typical SaaS data, customer relationship data.
4. Under 1 year: session tokens, short-lived API credentials, ephemeral data.

Tier 1 and 2 data should already be on hybrid PQ key exchange where the protocol supports it. Tier 4 can wait until the next regular crypto migration cycle.

Step three: hybrid TLS first, signatures second

The first migration most teams take is TLS key exchange to hybrid (X25519 + ML-KEM). Hybrid means both classical and post-quantum algorithms are used; if either is broken the connection is still secure. This is the only mode currently supported across major libraries (OpenSSL 3.5+, BoringSSL, Rustls, Go crypto/tls).

Signature migration (TLS server certificates signed with ML-DSA instead of RSA/ECDSA) is harder. Certificate sizes increase 10x to 50x. Many embedded devices and older middleboxes break. Do this after the key-exchange migration is stable, and only on systems where the increased size is tolerable.

Step four: code-signing and document-signing pipelines

Long-lived signatures matter most. A binary signed in 2026 with RSA-2048 is potentially forgeable in 2035. Sign critical artefacts with hybrid signatures (RSA + ML-DSA) so the signature remains valid under either algorithm. Sigstore's roadmap includes hybrid signing; Microsoft and Apple have published similar plans.

What we tell clients to do this year

• Complete the cryptographic inventory by Q3.
• Enable hybrid TLS (X25519 + ML-KEM) on internet-facing endpoints. Most managed CDNs (Cloudflare, Fastly) have a single toggle.
• Enable hybrid VPN where supported (WireGuard with Rosenpass, OpenVPN PQ).
• Begin testing PQ certificate issuance in non-production for systems that can tolerate the size increase.
• Update procurement contracts: any cryptographic component purchased now should support PQ migration.

Closing

Post-quantum migration is a multi-year structural change to the cryptographic backbone of the internet. It is also tractable if you start now and phase it across data-lifetime tiers. The teams that will be in trouble in 2030 are the ones that will start in 2029. The ones that will be fine started in 2025 and are about a third of the way through. Mid-2026 is the right moment to start if you have not.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.