Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines

An algorithm name without its role is insufficient for migration. RSA might authenticate a certificate, transport a session secret, sign a software update, or decrypt an archived document. Those uses have different exposure timelines, consumers, and replacement paths. Record the operation and the protocol or file format that gives it meaning.

A sufficiently capable cryptographic quantum computer would threaten widely used factoring- and discrete-log-based public-key systems. For confidential traffic, an adversary can retain encrypted material now and attempt later decryption if the exchange becomes breakable. That motivates prioritizing data whose confidentiality must outlast the migration window, without predicting a specific date for such a computer.

NIST published ML-KEM in FIPS 203 and the ML-DSA and SLH-DSA signature standards in FIPS 204 and FIPS 205 in August 2024. A key-encapsulation mechanism establishes a shared secret; it is not a drop-in signature or a replacement for bulk authenticated encryption, and a signature standard serves a different operation. An algorithm standard also does not specify every TLS, certificate, hardware or application integration.

Symmetric cryptography is not the problem. NIST’s draft transition plan says it does not expect to move away from its symmetric standards, such as AES, SHA-2, SHA-3 and HMAC, and that approved symmetric primitives with at least 128 bits of classical security meet its lowest post-quantum category. Data wrapped with an AES-256 key in a KMS or HSM is already quantum-resistant; RSA or elliptic-curve key transport and signatures are what must change.

There is no single global deadline, but these are the dates that regulators, auditors and customers cite. Status is as of October 2026.

For each entry, capture system and owner, operation, algorithm and parameters, library/provider and version, protocol/format, key generation and storage, key identifier, data lifetime, external peers, hardware constraints, and upgrade mechanism. Include signatures verified by devices that cannot easily receive new firmware and data archives whose decryptors are rarely exercised.

Combine several evidence sources: dependency and configuration review, runtime negotiation, certificate and key inventories, code searches, vendor documentation, and representative traffic or artifact metadata. Each has blind spots. A library dependency does not prove which algorithm is used; a runtime trace may miss a dormant restore path.

Classify uncertainty explicitly. “RSA present in library” is a discovery lead; “this listener negotiated ECDHE with an RSA certificate” is observed use; “this firmware accepts only this signature profile” is a compatibility constraint if verified. Inventories become actionable when evidence and ownership are attached rather than when every cell is optimistically filled.

Include classical hygiene during discovery. Unsupported algorithms, shared keys across unrelated services, missing ownership, and untested restoration are present problems regardless of quantum timelines. Fixing them can also make later migration easier, especially when versioned formats and automated key deployment are introduced.

Record the inventory in a format tools can read. CycloneDX 1.6 (April 2024) added a cryptography bill of materials (CBOM) that describes algorithms, keys and certificates and links them to the components that use them.

Configuration files say what a server should do; a fresh handshake shows what it does. This script records the protocol, cipher, key-exchange group and certificate key for each endpoint in a list. A row whose key exchange is not X25519MLKEM768 is traffic an attacker could record today and decrypt later; the certificate key column is your signature migration list. It was tested with OpenSSL 3.6.4 against local servers offering hybrid key exchange, classical X25519 only, and TLS 1.2 with an RSA certificate, plus an unreachable endpoint.

#!/usr/bin/env bash
# One CSV row per TLS endpoint: what a fresh handshake actually negotiates.
# Needs OpenSSL 3.5 or later, which offers X25519MLKEM768 first.
# Usage: ./tls-inventory.sh endpoints.txt > tls-inventory.csv   (one host:port per line)
echo "endpoint,protocol,cipher,key_exchange,certificate_key,certificate_signature"
while read -r endpoint; do
  [ -n "$endpoint" ] || continue
  out=$(openssl s_client -connect "$endpoint" -servername "${endpoint%:*}" </dev/null 2>/dev/null)
  protocol=$(sed -n 's/^Protocol: //p' <<<"$out")
  cipher=$(sed -n 's/^New, .*Cipher is //p' <<<"$out")
  group=$(sed -n -E -e 's/^Negotiated TLS1.3 group: //p' -e 's/^(Peer|Server) Temp Key: ([^,]*).*/\2/p' <<<"$out")
  leaf=$(sed -n 's/^ *a:PKEY: \(.*\); sigalg: \(.*\)$/\1;\2/p' <<<"$out" | head -n 1 | tr -d ',')
  echo "$endpoint,${protocol:-no handshake},$cipher,$group,${leaf%%;*},${leaf#*;}"
done < "$1"

Use a planning comparison: required secrecy lifetime plus estimated migration time versus the risk horizon chosen by the organization. The horizon is a scenario, not a scientific forecast. A medical archive needing twenty years of confidentiality and a three-year migration deserves different urgency from a short-lived public-status token.

Signing has its own timeline. A software update signed today may need to be verified by a device for many years. Inventory the verifier upgrade path, trust anchors, signature formats, offline behavior, and ability to reject obsolete profiles. Replacing the signing service alone cannot teach an old verifier a new algorithm.

Use standardized hybrid constructions from maintained libraries rather than composing algorithms yourself. TLS already has one: the X25519MLKEM768 group combines X25519 with ML-KEM-768, so a session stays confidential unless both are broken. It is on by default in Chrome and Edge 131 and later, Firefox 132 and later on desktop, Safari 26, OpenSSL 3.5, Go 1.24, Node.js 24.5 and JDK 27, so many endpoints negotiate it after a library upgrade. Track the exact implementation and profile, because deployment support changes faster than the primitive standards.

Measure message and certificate sizes, handshake fragmentation, memory, latency, signing/verification throughput, hardware support, and failure behavior. A cryptographically appropriate algorithm can still break a constrained device or exceed an intermediary’s message limit. Decide rollback rules that preserve an explicit minimum security policy instead of silently negotiating whatever works.

Stage migration with versioned data formats, dual-read or dual-verification windows where justified, controlled new-write defaults, and a retirement gate. Keep recovery tests for old encrypted data until its supported lifetime ends. Cryptographic agility means a tested change process and bounded accepted profiles, not accepting every algorithm mentioned by an input.

• Run the endpoint inventory above and upgrade TLS terminators, proxies and service meshes to libraries that negotiate X25519MLKEM768; the TLS guide at /domains/identity-crypto/key-management-pki/tls-pki-operations/ has the server settings.
• Test load balancers, firewalls and inspection devices with the larger ClientHello, and keep X25519 as a fallback group.
• List RSA and elliptic-curve key transport outside TLS, such as data keys wrapped to a public key, and move at-rest wrapping to symmetric keys in a KMS, as in /domains/identity-crypto/key-management-pki/envelope-encryption-rotation/.
• Find the signers whose verifiers are hardest to update, such as firmware and boot chains, and plan their ML-DSA, SLH-DSA or LMS migration first.
• Add post-quantum support to procurement requirements and to the crypto-agility tests of new formats and protocols.

An ordinary pilot connection or signature must interoperate with the intended peers. Unsupported or disallowed profiles must fail predictably; corrupted and wrong-context artifacts must fail authentication. Test maximum-size messages and the oldest supported consumer, not only two current development machines.

For each retired algorithm, demonstrate that no required active operation still depends on it or document a bounded exception with an owner and date. A scan that finds no string naming the algorithm cannot prove the absence of a hardware, vendor, or archived-data dependency.

Revisit the standards table and vendor support when you implement each step. Standards are final for ML-KEM, ML-DSA and SLH-DSA, while FN-DSA, HQC and the NIST transition dates are still moving. Sector rules and contracts can impose earlier dates than the national plans.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism. August 2024.
2. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard. August 2024.
3. NIST FIPS 205: Stateless Hash-Based Digital Signature Standard. August 2024.
4. NIST SP 800-227: Recommendations for Key-Encapsulation Mechanisms. September 2025.
5. NIST IR 8547 (initial public draft): Transition to Post-Quantum Cryptography Standards. November 2024.
6. NIST: HQC selected as a backup KEM (March 2025)
7. NSA: Commercial National Security Algorithm Suite 2.0
8. UK NCSC: timelines for migration to post-quantum cryptography
9. European Commission: coordinated roadmap for the transition to post-quantum cryptography
10. Cloudflare: post-quantum support by client and library
11. CycloneDX 1.6 and the cryptography bill of materials

Reference information

Tags

Key managementTLSPost-quantum cryptography

SDLC phase

DesignMaintenance

Role

AppSec engineers

ASVS 5.0.0 requirements

v5.0.0-11.1.2 · v5.0.0-11.1.3 · v5.0.0-11.1.4 · v5.0.0-11.2.2 · v5.0.0-11.2.3

Download this guide as Markdown

Continue exploring