PQC is Part of TLS Hygiene

PQC is Part of TLS Hygiene

“RSA will fall by 2030.”
“Nothing will happen for fifty years.”

Both claims appear in the same forum thread, neither helps you run production infrastructure.

The question that matters is not the calendar date; it is which systems would still be valuable to an attacker the day after a large quantum computer exists.
Once that is answered, post-quantum cryptography (PQC) stops being a headline and becomes another hygiene item—like key length, cipher suites, or certificate expiry.

1. Discover what you have

Before you pick a PQC key-exchange algorithm you need visibility:

  • Every DNS name the organisation controls
  • Every certificate that claims those names (CT logs + internal CA logs)
  • Where each certificate is terminated—load balancer, CDN, appliance, cloud proxy, partner network
  • The TLS version, key-exchange groups and cipher suites actually negotiated today

Without this list you cannot tell whether you are already partially protected (e.g. a CDN that offers hybrid KEM) or still exposing 1024-bit DH in a forgotten colo.

Create the inventory once, then keep it fresh with automation. CT monitors, active scanners, and CD/CI hooks are usually enough.

2. Treat PQC as a deployment property, not a certificate flag

A certificate only carries public-key material; the real question is what runs on the wire.

For example, if a domain is fronted by a PQC-ready CDN, hybrid key exchange will take place even if the origin server remains unchanged. Conversely, if you have a legacy appliance terminating TLS connections, it will continue to use classical cryptography even if you re-issue the certificate with ECDSA-P384. Alternatively, switching your ingress layer to a provider that supports X25519ML-KEM768 can upgrade half your estate with a single change window.

Map the inventory line-by-line to the terminating infrastructure; that tells you where you can flip the PQC bit and where you need a longer migration story.

3. Add PQC to the existing TLS programme

You already track certificate lifecycle (issuance, renewal, revocation), forbidden protocol versions (SSLv3, TLS 1.0, TLS 1.1), and minimum key length and allowed signature algorithms. Extend the same policy language by requiring hybrid post-quantum KEM for external endpoints that carry long-lived sensitive data, tagging each endpoint in the inventory with pqc=yes / partial / no, blocking deployment pipelines that regress a pqc=yes service back to classical-only, and preferring providers that expose hybrid groups in their console/API—make it a procurement checkbox.

4. Prioritise by data lifetime, not buzz

High-value + long-retention = upgrade first.
Public marketing site with 30-day cache → can wait.
Internal API whose JWTs are valid for ten years → upgrade now.

Document the decision in the same risk register you use for cryptographic agility. When the quantum threat model changes, re-score and re-order; no need to re-write the whole framework.

5. Keep the inventory alive

Quantum timelines will keep sliding. Your job is to know:

  • What you own,
  • Which parts will still matter when the slide stops, and
  • The concrete step you will take next month, not next decade.

Maintain the inventory, enforce the policy, and the organisation is ready the day the news breaks.

Photo by Emma Simpson on Unsplash