Know what you have.
A briefing for network admins and systems engineers on inventory, crypto-agility, and the operational pitfalls that will dominate early deployment experience.
Operator-grade material. The cryptographic inventory comes first because without it, no meaningful migration prioritization is possible. Crypto-agility is the operating model that lets you swap cryptographic components without redesigning systems. The three pitfalls — MTU fragmentation, PKI chain validation, and IDS false positives — will surface during rollout and require advance planning.
The living register.
Before any migration decision can be made, produce a working cryptographic inventory. The goal is to systematically identify every TLS termination point, VPN endpoint, SSH key, certificate, signing pipeline, and firmware update channel that uses RSA, ECDH, ECDSA, or any classical public-key primitive. Tools like openssl s_client -connect host:443 probe exposed endpoints; grep-based scans of code repositories and configuration files surface hard-coded algorithm references; vendor queries close the rest.
Treat the register as living, not as a one-time snapshot. Cryptography is embedded in application libraries, middleware, hardware, and cloud services that are independently updated by different teams and vendors. The register should carry — for each row — the system identifier, owner, crypto function (key establishment / signature / hash / symmetric), algorithm in use, data longevity (<1 yr, 1–5 yr, 5–10 yr, >10 yr), external exposure (internet / partner / internal), trust role (CA / root / signing pipeline / standard), and the vendor's PQC roadmap status.
Priority is derived from three axes: long-lived data + external exposure + high-trust role = P1 (move first). Short-lived + internal + standard = P3 (later). Most operators below hyperscaler scale find five to fifteen rows in the P1 tier and forty total in the working register.
Discovery methods
- Network probe.
openssl s_clientand equivalent tools, plus internal certificate inventories, plus the firewall's allow-list of egress destinations using TLS. - Code and config scan. Grep for algorithm names (
RSA,ECDH,ECDSA,X25519,secp256r1) across repositories, Helm charts, Terraform, and Ansible playbooks. - Vendor query. A standard letter or RFP question: which FIPS standard does this product implement; what is the version and date; what is the hybrid story; what is the rollback path.
- Cloud-provider audit. Each cloud provider exposes TLS and KMS configuration differently. AWS KMS, Azure Key Vault, and GCP Cloud KMS each have PQC support that varies by service and region — confirm the workload, not the platform.
Crypto-agility, then hybrid.
NIST's Cybersecurity Whitepaper 39 (CSWP 39), finalized January 2026, formalizes what practitioners have known for years: the way to survive an algorithm transition is to build infrastructure that can swap cryptographic components without redesigning systems from scratch. In practical terms, this means avoiding hard-coded cipher suites in application code, preferring configurable TLS stacks over fixed-algorithm appliances, and ensuring certificate lifecycle management can handle algorithm changes without a full PKI redesign.
As vendors release updates supporting NIST FIPS 203 (ML-KEM for key establishment) and FIPS 204 (ML-DSA for signatures), the expectation is that teams will apply those updates through normal patch cycles rather than replacing hardware. The key exchange layer — TLS, IPsec IKEv2, SSH — is the highest-priority surface, because it is both the most widely exploited by HNDL and the most mature in terms of vendor support.
Hybrid key exchange — classical KEM (typically X25519 or P-256) combined with ML-KEM in a parallel construction — is the standard initial deployment posture. It maintains interoperability with endpoints and intermediaries that do not yet support the NIST algorithms, and it provides a security floor: an attacker must break both components independently. The IETF draft for ML-KEM in TLS 1.3 formalizes this for the most widely deployed transport protocol. Plan the hybrid-to-native sunset explicitly; do not allow doubled overhead to become permanent.
MTU. PKI. IDS.
Three specific problems will appear during rollout and require advance planning. Each maps to a deployment artifact you should validate before the production change window opens.
| Pitfall | What breaks | What to do first |
|---|---|---|
| MTU fragmentation | PQC public keys and ciphertext are significantly larger than classical equivalents. ML-KEM-1024 produces a 1,568-byte ciphertext compared to a few hundred bytes for ECDH. TLS handshake records will frequently exceed the standard 1,500-byte MTU, causing fragmented packets that stateful firewalls and deep-packet inspection appliances may silently drop. | Audit MTU settings across the path. Update firewall policies and any DPI rules that drop fragmented IP packets. Test the handshake at every MTU boundary in the path before production rollout. |
| PKI chain validation | Certificate chains that include PQC or hybrid signatures may fail validation silently in legacy PKI infrastructure, OCSP responders, and relying-party validators that do not yet support the new certificate structures. | Test full chain validation end-to-end, not just at the server endpoint. Include OCSP responders, intermediate CAs, and any old client TLS stacks in the validation path. Confirm dual-cert or composite-cert support where present. |
| IDS / IPS false positives | Intrusion-detection and prevention systems trained on classical traffic patterns will frequently flag PQC handshakes as anomalous. False positives will mask real incidents. | Coordinate IDS / IPS signature and rule updates with the security operations team before deployment. Confirm the rule update is in the change ticket. Validate that PQC traffic is whitelisted at the new signature, not the old one. |
Operational checklist before the change window
- MTU verified end-to-end. Including any DPI, IPS, or WAN optimizer in the path.
- Full chain validated. Server, intermediate, root, OCSP, and at least one representative legacy client.
- IDS rules updated. Change ticket numbered. Signature versions documented.
- Rollback path tested. Confirm classical-only fallback works without manual intervention.
- Cipher-suite negotiation logging on. So a silent downgrade is visible after deployment.
For the cryptographic depth that explains why the construction works the way it does (and the downgrade-attack and KDF-combiner pitfalls), see the Security Architects briefing. For the executive framing that justifies the inventory sprint and procurement-language update, send the Executives briefing. For the operator-level summary of the standards and timelines, see Foundation: Standards & Timelines. The inventory worksheet itself is planned as a Phase 2 deliverable in Tools.