Post-quantum crypto agility: what to flag now

Adversaries are archiving your TLS traffic right now.

They cannot decrypt it today. But when a practical quantum computer arrives, they will. The harvest-now-decrypt-later threat is not a forecast. Nation-state actors are storing encrypted traffic at scale. What is on the wire today is what is at risk when the decryption capability arrives.

Crypto agility is not the same as PQC migration

Migrating to post-quantum algorithms is the end state. Getting there requires knowing what you have first. Crypto agility is the capacity to swap cryptographic primitives without rewriting your stack. Most codebases do not have it.

The problem is that cryptographic dependencies are rarely inventoried. TLS cipher negotiation, key exchange algorithms, certificate chains, JWT signing keys, SSH host keys, and at-rest encryption for backups all use primitives that will be broken by a sufficiently large quantum computer. They live in different places. They are owned by different teams. They are almost never in one list.

Here is what a crypto agility audit typically surfaces:

1. RSA-2048 or EC P-256 key exchange in TLS 1.3 connections to external services, invisible at the application layer
2. Long-lived certificates with 3 to 10 year validity that will outlive any reasonable quantum timeline buffer
3. JWT tokens signed with RS256 or ES256 where the signing keys have no documented rotation schedule
4. S3 bucket server-side encryption using AES-256 with RSA-wrapped data keys (the RSA wrapper is the part that breaks)
5. SSH host keys on bastion hosts generated years ago, never rotated, using ecdsa-sha2-nistp256

None of these are bugs in the traditional sense. They are configuration facts. They are also the facts that determine your exposure window.

NIST finalisation is not the starting line

FIPS 203, 204, and 205 were finalised in August 2024. ML-KEM (formerly Kyber), ML-DSA (formerly Dilithium), and SLH-DSA (formerly SPHINCS+) are the current standards. This matters for new systems being built now. It matters less if your audit has not started yet.

Finalisation does not mean your current TLS libraries support these algorithms. OpenSSL 3.5 shipped ML-KEM. Older deployed versions do not have it. Your language runtimes may not have updated. Your cloud provider's managed TLS termination may offer hybrid mode (X25519MLKEM768) but not pure PQC yet.

I think framing the inventory as something that starts after NIST is done is wrong. The migration window is long. The inventory step has no dependencies on algorithm selection.

How we audit PQC exposure

We run a dedicated post-quantum cryptography review phase as part of our seven-phase pipeline. This is not a grep for cipher strings. It is active probing of each TLS endpoint, certificate chain, and key material source we can reach.

We connect to each TLS endpoint and attempt to negotiate a PQC hybrid cipher suite. If the server falls back to ECDH, we record that as a finding with the full handshake transcript. The certificate chain is parsed for key algorithm and validity period. A long-lived RSA certificate issued today gets a separate flag from a short-lived one, because the risk window is different.

Key material in SSH config files, environment variable stores, and secrets managers is enumerated where we have white-box access. Each item gets a risk annotation based on key type, estimated lifetime, and whether the data it protects would still be sensitive in ten years.

Every finding ships with the raw TLS handshake output, certificate parse, or key metadata that produced it. You see facts.

Starting the inventory

You do not need to be mid-migration to take action. The inventory is the useful first step. Here is a practical starting point for the most common sources:

openssl s_client -connect api.example.com:443 -tls1_3 </dev/null 2>/dev/null \
  | grep -E "Cipher|Protocol"

openssl s_client -connect api.example.com:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -E "Public Key Algorithm|Not After"

ssh-keyscan bastion.example.com 2>/dev/null \
  | ssh-keygen -l -f -

These commands give you the surface for a single host. They do not scale across a fleet, and they do not correlate findings against data sensitivity or key lifetime. That is what automated PQC review is for.

The quantum computers capable of breaking RSA-2048 are not here yet. But the encrypted traffic being collected today will still exist when they arrive. The window to act is measured in years, not days, and the inventory step carries no dependency on hardware timelines or standards committee schedules.

See how we run PQC review inside your environment at /poc/.