The Half of the PQC Problem Nobody Finished
Post-quantum key exchange is, for practical purposes, solved. Hybrid ML-KEM key agreement now ships by default in mainstream browsers, TLS libraries and CDN edges, and most enterprises inherited it without doing any work.
Authentication is the unfinished half. Every TLS handshake still proves identity with an RSA or ECDSA signature chained to a classical certificate authority. A cryptographically relevant quantum computer breaks that chain, and unlike key exchange, it cannot be fixed by a library upgrade alone — it requires new certificates, new CA hierarchies, and new lifecycle tooling.
The edge-to-origin leg is where this becomes concrete first. Mutual TLS between a CDN or reverse proxy and an origin server uses a private trust store, entirely under your control. There is no browser compatibility matrix and no public CA gating the change, which makes it the ideal first production deployment of quantum-safe authentication.
What a Quantum-Safe mTLS Deployment Requires
An ML-DSA-capable crypto stack
ML-DSA (FIPS 204) signing requires a modern TLS stack — OpenSSL 3.5 or later, or an equivalent library with PQC signature support. Stock long-term-support Linux images generally ship an older branch, so the first blocker is usually the base image, not the certificate.
Audit which of your origin servers can even generate an ML-DSA key before designing the hierarchy. That inventory is the real project plan.
A private issuing hierarchy that speaks PQC
Legacy Windows-based certificate services cannot issue ML-DSA certificates. Origin authentication should be issued from a crypto-agile private CA that supports both classical and PQC profiles in parallel, so you can roll workloads over one fleet at a time rather than in a single cutover.
Automation that survives larger certificates
ML-DSA signatures and public keys are an order of magnitude larger than ECDSA equivalents. Expect bigger handshakes, more record fragmentation, and higher memory use on constrained appliances. Combined with shrinking maximum certificate lifetimes, manual renewal is not viable — ACME or an equivalent automated enrolment protocol is a prerequisite, not an optimisation.
A Practical Sequencing Model
- Inventory trust stores. Identify every private trust relationship: edge-to-origin, service mesh, API gateway to backend, database client certificates.
- Upgrade the crypto stack. Move origins to a TLS library with PQC signature support and validate performance under load.
- Stand up a parallel PQC issuing CA. Keep the classical hierarchy live; run both.
- Pilot on a non-critical origin. Measure handshake latency and CPU cost with real traffic.
- Automate rotation. Enrol the pilot into automated lifecycle management before scaling out.
- Expand fleet-wide, then deprecate. Retire classical-only issuance once every consumer validates PQC chains.
Why Start Now, Before the Public Web Does
Public web PKI is still working through the certificate-size problem, and proposals to compress the trust chain are not finalised. That timeline is outside your control. Private authentication is not.
Organisations that migrate internal mutual TLS first arrive at the public-web transition with the hard parts already done: an inventory that is accurate, a CA that is crypto-agile, and automation that can rotate certificates without a change window. Those that wait will attempt all three under a compliance deadline.
Where to Begin
Start with discovery, not procurement. Most enterprises underestimate the number of private trust relationships in production by a wide margin, and every one of them is a certificate that must eventually be reissued with a quantum-safe signature.
If your current issuing infrastructure cannot produce an ML-DSA certificate today, that is the constraint to fix first — see our guidance on PKI modernization and on migrating away from legacy certificate services.