Post-quantum cryptography migration

Your browser probably negotiated a post-quantum key exchange to load this page. Chrome switched to hybrid ML-KEM by default in version 131 (November 2024), as BleepingComputer reported when Google announced the change, and Cloudflare reported in late October 2025 that more than half of the human-initiated HTTPS traffic on its network already used it. The public internet is moving on its own.

Your internal systems are a different story. The VPN to your processor, the certificates on your payment terminals, the signing keys for your mobile app, the HSM that holds your root CA: none of those change when Chrome updates. A post-quantum cryptography migration is the planned work of moving those systems to the new NIST standards, in an order that protects the most sensitive data first.

Which algorithms replace RSA and elliptic curves?

The algorithms that replace RSA and elliptic curves are NIST’s post-quantum standards: ML-KEM (FIPS 203) for key exchange, and ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for signatures, all published on August 13, 2024. Two more are coming, FN-DSA for compact signatures and HQC as a backup key exchange.

SLH-DSA relies only on hash functions, which makes it a conservative choice for long-lived roots of trust, but its signatures run from about 8 KB to about 50 KB depending on the parameter set. FN-DSA produces much smaller signatures than ML-DSA, and we plan for it where certificate size is a real constraint, but we don’t recommend building production systems on a standard that isn’t final. HQC exists so that you have a key exchange based on different mathematics if a weakness ever appears in lattices. It is worth designing room for, not deploying today.

Where does a post-quantum migration start?

A post-quantum migration starts with a cryptographic inventory: a list of every place your systems use public-key cryptography, the data each one protects and how long that data must stay confidential. Most companies have never built one, and without it nobody can decide what to move first or estimate the effort.

You cannot migrate what you haven’t found. We combine three sources. Network scans show what your TLS and SSH endpoints negotiate. Code and dependency analysis shows which libraries your applications call and with which algorithms. Interviews and configuration reviews cover what scanners miss: HSM key stores, certificates baked into firmware, database encryption settings, partner file transfers and the managed services whose internals you can’t see.

The result is a CBOM, a cryptographic bill of materials in the same spirit as a software bill of materials. For each item it records the algorithm, key size, library, owner, the data it protects and how long that data must stay confidential. That last field decides the order. A session token that expires in an hour can wait. A mortgage file or a clinical record that must stay private for 20 years cannot.

If you haven’t done any of this before, a quantum readiness assessment is a lighter first step that sizes the problem before you commit to a full migration.

Crypto-agility before algorithm swaps

The most useful architectural change is making the next change cheap. That is what crypto-agility means: applications ask a central library or service for “a key exchange” or “a signature” instead of hard-coding RSA-2048 in forty places.

This matters because the post-quantum standards are young. Parameter choices may shift, HQC and FN-DSA will arrive later, and implementation bugs will be found. An organization that can change an algorithm through configuration will handle those events in weeks. One that has to patch every application will take years, which is roughly how the SHA-1 retirement went.

In practice we look for a few patterns: cryptography behind a small number of internal libraries, algorithm identifiers in configuration rather than code, certificate issuance automated end to end, and a way to report which algorithm each service uses in production.

Hybrid key exchange goes first

Key exchange is where harvest-now, decrypt-later attacks bite, so it is usually the first thing we move. The standard choice in 2026 is X25519MLKEM768 in TLS 1.3, which combines classical X25519 with ML-KEM-768. If either component holds, the session key stays secret.

The support is already there in most stacks. OpenSSL 3.5, released on April 8, 2025, added ML-KEM, ML-DSA and SLH-DSA and changed its default TLS key shares to offer X25519MLKEM768, according to its release notes. The work is mostly upgrading the libraries behind load balancers, API gateways, service meshes and VPN concentrators, then checking that middleboxes don’t break on the larger handshake. Some older firewalls and TLS inspection appliances do.

Signatures, PKI and HSMs take longer

Moving signatures is harder than moving key exchange, for three reasons. Signed artifacts live a long time (firmware, documents, code releases). Certificate chains grow, since an ML-DSA-65 signature is 3,309 bytes against 64 bytes for ECDSA P-256. And your PKI depends on HSMs, certificate authorities and client software that all need to agree.

A realistic sequence starts with internal PKI you control, such as service-to-service mTLS, code signing and document signing, before public web certificates. Public TLS certificates depend on browser and CA/Browser Forum decisions that you don’t control, so we track them rather than plan around a date.

For HSMs, the question is whether your current models can run ML-KEM and ML-DSA through a firmware update, whether that firmware keeps its FIPS 140-3 validation, and whether you need new hardware. That answer often determines the budget more than anything else.

Questions to ask your vendors

Most of your cryptography runs inside products you buy. We send each critical vendor a short written set of questions and track the answers:

• Which NIST post-quantum algorithms does the product support today, and in which version?
• Does it support hybrid key exchange (X25519MLKEM768) in TLS, and is it on by default?
• Can the algorithm be changed by configuration, or does it need a new release?
• What is the dated roadmap for ML-DSA certificates and signatures?
• Will the post-quantum implementation be covered by FIPS 140-3 validation, and when?
• What breaks if the other side of the connection doesn’t support post-quantum algorithms?

Vague answers (“we are quantum-ready”) are themselves useful data. They tell you where to put pressure or look for alternatives.

What does post-quantum performance testing show?

Post-quantum performance testing usually shows that ML-KEM is not the bottleneck, since its operations are about as fast as the elliptic-curve math it replaces. The real costs appear in bytes: larger TLS handshakes, larger certificate chains and larger signed payloads, which hurt most on slow mobile links and constrained devices.

We measure in your environment, not from benchmarks on someone else’s hardware. Typical tests cover handshake latency through your load balancers, throughput on busy API gateways, certificate chain size on mobile clients over slow networks, and memory and timing on constrained devices like payment terminals or industrial controllers. Protocols with fixed field sizes, some IoT and smart-card formats in particular, are where post-quantum signatures cause real trouble.

How long does a post-quantum cryptography migration take?

A post-quantum cryptography migration usually spends its first six to eight weeks on discovery and design: inventory, CBOM, vendor questionnaires and a test plan. After a pilot of hybrid key exchange, the rollout runs in waves, and its length depends on your size and your vendors, so we estimate it once the inventory is done.

1. Discover (weeks 1 to 6). Inventory, CBOM, data lifetime classification and vendor questionnaires.
2. Design (weeks 5 to 8). Crypto-agility target, migration backlog and test plan, reviewed with security and architecture.
3. Pilot. Hybrid key exchange on a limited set of internal and external endpoints, with measurements and a rollback plan.
4. Roll out in waves. Key exchange across the estate first, then internal signatures and PKI, then the long tail of legacy and vendor systems.
5. Keep it current. The CBOM becomes a maintained record, updated as NIST finalizes FIPS 206 and the HQC standard.

Banks and insurers usually carry the longest-lived data, so their backlogs tend to be larger; see our notes on banking and finance and telecommunications.

AndesQubit is opening engagements in stages. If your organization is planning this work, tell us about your systems and we’ll let you know when we can start and what we would look at first.