Quantum readiness standards: from ML-KEM to deployment evidence

A product can support a post-quantum algorithm while a particular connection still uses traditional key establishment. An algorithm certificate can be valid while the offered software release falls outside the cryptographic module’s validated configuration. A working tunnel can conceal an unwanted fallback.

Quantum readiness therefore needs a chain of evidence: algorithm, protocol, implementation, and deployed behavior. Each link answers a different engineering question. This Field Note accompanies our standards explainer and applies that distinction to enterprise networking.

Standards and policy status checked October 12, 2026. Recheck the linked publication records when specifying a deployment.

Begin with the job the cryptography performs

Consider a branch gateway connecting to a data-center service. Key establishment creates shared secret material. Authentication establishes the basis for trusting the peer. Symmetric encryption protects the application traffic using derived keys.

These functions interact, but they need separate review. Replacing a vulnerable key exchange does not automatically migrate the certificate chain, firmware signatures, or every application behind the gateway. Post-quantum cryptography runs on conventional computing platforms; it does not require a quantum computer at each branch. It is also distinct from quantum key distribution. NIST’s PQC introduction.

Three NIST standards, two different roles

FIPS 203 specifies ML-KEM, a key-encapsulation mechanism. The parties use it to establish a shared secret over a public channel. The secret feeds subsequent cryptographic operations; ML-KEM does not replace AES as the algorithm encrypting all application bytes. ML-KEM-512, ML-KEM-768, and ML-KEM-1024 are parameter-set names, not AES key lengths. FIPS 203.

FIPS 204 specifies ML-DSA, a digital-signature algorithm. A signature supports integrity and authentication under the relevant trust rules. It does not hide the signed content. FIPS 205 specifies SLH-DSA, a stateless hash-based signature algorithm with a different mathematical foundation. SLH-DSA should not be confused with the stateful LMS and XMSS schemes. FIPS 204; FIPS 205.

For a network inventory, this suggests separate entries for session key establishment, peer authentication, and software-signing trust. Writing “PQC supported” in one column loses the distinctions needed to plan the migration.

NIST’s selection of an algorithm for future standardization is another distinct milestone. As of this article’s check date, HQC and FALCON remained on the selected-algorithms list awaiting their FIPS standards. Check the current record before treating a roadmap entry as a finalized standard. NIST selected algorithms.

A protocol must define how peers use the algorithm

An algorithm specification does not, by itself, define a TLS handshake or IKEv2 exchange. Peers need compatible message formats, identifiers, negotiation behavior, and key derivation.

For TLS 1.3, RFC 10024, published in August 2026, defines hybrid groups including X25519MLKEM768. These combine a traditional ephemeral elliptic-curve exchange with ML-KEM. The specified construction aims to retain protection if one component remains secure, subject to its assumptions. Combining two arbitrary algorithms is not an equivalent design. RFC 10024.

This change concerns key establishment. A session using a hybrid group can still authenticate with a traditional certificate signature. Review that authentication path separately, including the certificate chain and the systems that issue and verify it.

IKEv2 has its own standards path. RFC 9370 defines multiple key exchanges. At our check date, the ML-KEM-specific IKEv2 document was in the RFC Editor queue, rather than a published RFC. A vendor may implement a particular draft or release profile; record exactly which one. RFC 9370; IKEv2 ML-KEM document status.

IKEv2 also has a separate mechanism for mixing a postquantum preshared key, or PPK, into key derivation. It depends on appropriately generated secret material and secure distribution. A PPK is distinct from an ordinary authentication preshared key and from an ML-KEM exchange. RFC 8784.

“FIPS” needs an object and a scope

When a supplier says a product is “FIPS compliant,” ask what evidence supports that statement.

NIST’s Cryptographic Algorithm Validation Program tests algorithm implementations. The Cryptographic Module Validation Program evaluates modules against FIPS 140 requirements. An algorithm certificate alone does not establish module validation. Neither program is a substitute for testing protocol interoperability. NIST CAVP; CMVP FAQ.

Where your requirements call for a validated module, request its certificate number, module version, operating environment, security policy, and covered services. Then match those records to the offered product and deployment configuration. Keep this evidence with the release and configuration record, rather than accepting a certificate from an unrelated version.

Inspect a readiness claim

The following is an illustrative procurement note, not a test result from a named product:

The gateway supports ML-KEM. The supplier provided a FIPS certificate. Our test tunnel connected successfully. Quantum-readiness review is complete.

Before reading the explanation, identify two claims that still need evidence. What observation would distinguish support on the product sheet from protection on the connection?

Compare your reasoning

The note does not identify the negotiated key-establishment mechanism, fallback behavior, or authentication scheme. It also does not establish that the certificate covers this module, release, environment, and service. A connected tunnel proves connectivity; it does not prove the required cryptographic properties.

A stronger record names the peers and releases, captures the negotiated group or exchange, identifies the authentication path, and links applicable validation evidence. It includes a test where the peer cannot negotiate the required mechanism, showing whether the connection fails or uses an explicitly permitted alternative.

Repeat acceptance checks after rekey, failover, and software changes. Measure handshake and reconnection behavior under representative load and path conditions, including larger messages and fragmentation where relevant. These are deployment acceptance recommendations derived from the distinction between implementation support and runtime behavior, not claims that every product has passed those tests.

Read dates together with their scope

NIST IR 8547 remained an Initial Public Draft at the check date. Its proposed transition dates should be recorded as proposals, not presented as a universal enterprise deadline. NIST publication status.

NSA’s 2026-10-01 announcement states quantum-resistant support requirements beginning in 2027 for new commercial National Security Systems and phaseout by 2030 for legacy systems unable to support the required algorithms. Keep National Security Systems attached to those dates. Applicability depends on the system and governing requirements. NSA announcement.

For each requirement, retain the source, version, status, affected systems, owner, and review date. Treat a vendor’s planned release as a dependency until shipping support and your own acceptance evidence are available.

Turn the standards into an engineering record

Choose one service and record its endpoints, key establishment, authentication, software versions, applicable policy, and evidence owner. Map the proposed replacement to a protocol profile and supported implementation. Test both successful negotiation and the failure paths your policy must control.

Continue with the Cisco Quantum Readiness course to connect these standards to inventory and migration planning. RouteSwitchU is an independent training publisher and is not affiliated with or endorsed by Cisco Systems, Inc.