Post-quantum HTTPS migration: what to check before ML-KEM and ML-DSA

When cryptography becomes an operations task

Teams rarely update certificates and TLS settings because they want to play with cryptography. The usual reason is simpler: one day an old client, proxy, library, or certificate authority becomes the bottleneck for the whole system. A post-quantum migration is that kind of task. It does not start with formulas. It starts with a practical question: who establishes HTTPS connections to your service, and what happens if the rules of that connection change.

Today, RSA and elliptic-curve cryptography still sit at the center of most real HTTPS systems. The concern is that sufficiently powerful quantum computers could change the security model for those algorithms. This does not mean every certificate stops working tomorrow. It does mean infrastructure has to be prepared early. TLS, the certificate chain, client libraries, proxies, and error observability are not replaced in a single day.

Start by mapping the HTTPS chain

The first step should not be heroic. Pick one service and draw its path from client to application. Mark browsers, mobile apps, server-to-server integrations, internal scripts, and old devices. Then mark the CDN, load balancer, ingress, reverse proxy, service mesh, or the application itself if TLS termination happens there.

Write down the certificate chain separately: who issues the certificate, how it is renewed, where private keys live, who controls intermediate certificates, and whether different environments use the same settings or different ones. For a small team, this may already reveal uncomfortable details. One service renews certificates through automation, another still depends on a manual step. Some clients use the system trust store, while others carry an old pinned set of certificates.

Post-quantum changes touch exactly these boundaries. If you do not know where TLS terminates and who verifies the digital signature, you cannot test ML-KEM or ML-DSA safely.

ML-KEM and ML-DSA do different jobs

In post-quantum discussions, it is easy to collapse all algorithm names into one list. For an operations plan, two jobs must be separated. ML-KEM belongs to the part of the connection that agrees on secret material for a session. In TLS, that material helps both sides create keys for encrypting one specific connection. This is where the industry has already been moving more actively toward hybrid approaches, combining a new mechanism with an older one to preserve compatibility.

ML-DSA belongs to digital signatures. Signatures let a client verify a certificate and let systems trust the origin of data. This is a different part of the chain. Key exchange can often be tested gradually at the session level. Signatures are tied closely to certificates, certificate authorities, trust stores, and client-side validation.

So the practical question is not simply how to turn on ML-DSA. A better question is: which clients can verify this signature, which libraries support it, how large will the certificate chain become, and will your proxy, logging, and monitoring handle that change.

Why signatures are harder to operate

ML-DSA matters because it is standardized and available for implementation. But it is not an invisible replacement for older signatures. Post-quantum signatures have different key and signature sizes, different performance behavior, and different network effects. At the scale of a large edge provider, that becomes traffic, memory, and millions of verifications. At the scale of a small team, it may show up as a slower connection start, an unexpected failure in an old client, or a limitation in a library that nobody has reviewed for years.

The certificate ecosystem creates another layer of difficulty. Your server may be ready while the client operating system is not. A library may support a new algorithm while an intermediate proxy refuses a larger chain. A test with a modern browser may pass, while an old partner integration fails with an unclear TLS error.

That is why waiting for a perfect future algorithm is also risky. It is better to learn now how to see dependencies, measure costs, and plan rollback. ML-DSA may not be the most convenient tool for every case, but it is part of the real standardized path.

A small test plan for a test environment

Start with a baseline. Measure TLS connection setup time, the amount of data transferred during the handshake, the share of errors, and the typical client and library versions. Without this data, any test will be a feeling rather than an engineering decision.

Next, create a separate test route. Do not disable current algorithms for everyone. Check whether your TLS library, proxy, or load balancer has support for the required experimental or standardized modes. For ML-KEM, pay attention to hybrid variants. For ML-DSA, test not only the server but the entire certificate chain and client-side verification.

Build a client matrix: current browsers, mobile versions, internal services, partner integrations, automation scripts. For each one, record the result: connection succeeds, certificate verification fails, timeout, unclear TLS error, library crash. It is a boring table, but it turns post-quantum migration from an abstraction into a plan.

Anti-patterns to stop early

The first anti-pattern is updating one library and calling the task complete. TLS crosses several layers, and each layer can change behavior.

The second is testing only a modern browser. Your riskiest client is often not a browser. It may be an old server integration, a mobile app without updates, or an internal agent running on an outdated system.

The third is disabling old algorithms for architectural cleanliness. During migration, compatibility is more important than aesthetics. A safe plan needs gradual enablement, measurement, and rollback.

The fourth is treating ML-DSA as a vendor switch. This is not only a CDN or cloud platform feature. You still need to know who verifies certificates, what constraints the client has, and where you will see the error.

What can wait

You do not need to move the entire internal certificate authority to post-quantum signatures tomorrow. You do not need to remove RSA or ECDSA before broad client support exists. You do not need to optimize size and performance before you have your own measurements.

But the inventory should not wait. A map of TLS termination, a client list, a library list, baseline metrics, and a test environment are useful right now. They will help not only with ML-KEM and ML-DSA, but with any future HTTPS change.

Sources

• Cloudflare: https://blog.cloudflare.com/ml-dsa-will-have-to-do/
• NIST FIPS 203, ML-KEM: https://csrc.nist.gov/pubs/fips/203/final
• NIST FIPS 204, ML-DSA: https://csrc.nist.gov/pubs/fips/204/final
• IETF RFC 8446, TLS 1.3: https://www.rfc-editor.org/rfc/rfc8446