What NIST Actually Published
In August 2024, NIST finalized three post-quantum cryptographic standards. FIPS 203 standardizes ML-KEM, the key encapsulation mechanism derived from CRYSTALS-Kyber. FIPS 204 standardizes ML-DSA, the digital signature algorithm derived from CRYSTALS-Dilithium. FIPS 205 standardizes SLH-DSA, the stateless hash-based signature scheme derived from SPHINCS+. A fourth standard, FIPS 206 for FN-DSA (based on FALCON), was also published.
These are not draft standards or recommendations pending finalization. They are stable, published FIPS standards with assigned numbers. Any infrastructure operator waiting for NIST to "finalize" PQC standards before beginning migration planning has passed that trigger point.
The standards are publicly available at no cost from NIST. ML-KEM (FIPS 203) is the primary algorithm for most operators: it handles key exchange and key encapsulation, which is the component that protects session key establishment in TLS, IPSec, and similar protocols. ML-DSA (FIPS 204) handles digital signatures, relevant for certificate infrastructure and code signing. Understanding which of these applies to your immediate risk surface is the starting point for migration planning.
Why the Key Exchange Layer Is the Priority
Operators looking at the published standards reasonably ask where to start. The answer is almost always the key exchange layer: specifically, the ECDH-based key establishment in your TLS and VPN infrastructure.
Here is the logic. Symmetric encryption (AES-256) and hash functions used in HMAC are minimally affected by quantum computing, requiring only key length increases rather than algorithm replacement. RSA and elliptic curve cryptography used in digital signatures is quantum-vulnerable, but certificates typically have short validity periods, meaning the harvest-now exposure for authentication data is bounded. The harvest-now exposure for session keys established via RSA or ECDH key exchange is more immediate: those keys protect data that may have long confidentiality requirements even though the key exchange itself was short-lived.
ML-KEM is designed as a drop-in replacement for ECDH in key encapsulation contexts. The API pattern is conceptually similar: a public key is used to encapsulate a shared secret, and the corresponding private key is used to decapsulate it. The underlying mathematics are different (module lattices rather than elliptic curves), but the integration interface is close enough that existing TLS libraries like OpenSSL and BoringSSL have already shipped ML-KEM support in their pre-production and production branches.
The Certificate Infrastructure Is a Separate Problem with a Different Urgency
Moving TLS key exchange to ML-KEM does not automatically update your certificate infrastructure. Certificates use RSA or EC keys for the signature that authenticates the server. This is a real migration task, but it has different urgency characteristics from the key exchange migration.
Certificate signatures authenticate the handshake. An attacker who captures today's TLS traffic needs to break both the key exchange (to get the session key) and the certificate signature (to verify they are not being fed a false certificate in a future man-in-the-middle replay). Practically, the key exchange is the higher-priority harvest-now target: session keys protect bulk data, while certificate signatures protect handshake authentication.
That said, certificate authority infrastructure has long replacement cycles, and the organizational work to migrate root CAs, intermediate CAs, and subscriber certificates to ML-DSA keys is substantial. Starting that planning concurrently with key exchange work makes sense, because both tracks require the same upstream work: cryptographic agility in your key management infrastructure and an inventory of all certificate-dependent systems.
Implementation Realities in Network Equipment
The gap between a published FIPS standard and deployed production capability in network infrastructure is significant. Most enterprise network equipment, firewalls, load balancers, and network encryption appliances with embedded TLS stacks are running firmware with cryptographic libraries that pre-date the final NIST standards. Vendors are in various stages of updating their firmware.
This creates a practical sequencing problem. You can update your software-based TLS endpoints (web servers, API gateways, client libraries) to support ML-KEM relatively quickly, since these run on general-purpose hardware and can be updated with software releases. Your network appliance firmware trail is likely to lag by 12 to 24 months for most vendor update cycles, and by longer for equipment with extended support contracts or embedded systems.
The implication is that hybrid key exchange mode, which combines classical ECDH with ML-KEM in a single key establishment, is not just a transition convenience. It is likely to be a required compatibility posture for 2 to 4 years during the period when some endpoints have been updated and others have not. NIST and IETF have published guidance on hybrid key exchange. In TLS 1.3 specifically, draft RFC specifications for ML-KEM-based hybrid key exchange are at advanced stages. This is the mechanism you will use in practice during the transition period.
What Operators Should Do in the Next 12 Months
Based on the deployment work we have done in our pilot program and conversations with security engineers at financial and infrastructure organizations, the practical near-term actions break into three categories.
The first is cryptographic inventory. Before you can migrate, you need a complete map of where RSA and ECDH key material is used in your network: not just public-facing TLS certificates (which certificate transparency logs help with), but SSH host keys, inter-service mTLS, code signing keys, VPN peer authentication, hardware security module key hierarchies, and any application-level encryption that operates outside the standard certificate infrastructure. This inventory is harder than most teams expect and takes 2 to 4 months for mid-size infrastructure environments.
The second is cryptographic agility infrastructure. This means building or deploying key management infrastructure that can handle key material from multiple algorithm sources: existing ECDH, ML-KEM, and eventually QKD-distributed keys, routing each to the right application context without requiring application code changes. Organizations that invest in this layer now spend their algorithm migration effort connecting new sources, not redesigning application interfaces.
The third is vendor assessment. Survey your key infrastructure vendors: your PKI provider, your network appliance vendors, your HSM vendor, your cloud provider's KMS offering. Ask specifically which of your current software versions support FIPS 203 / ML-KEM, and what the timeline is for firmware support in your hardware. This gives you the realistic constraint on how fast you can actually migrate, independent of your own readiness.
We are not saying this migration is simple. It is not. But the NIST publication milestone removes the largest single uncertainty from the planning timeline: algorithm selection. The remaining uncertainties are deployment schedules, vendor timelines, and your own internal prioritization. Those are manageable with the right planning horizon.
