FIPS 140-3 ML-KEM validation: is your module approved?

FIPS 140-3 ML-KEM validation means that an ML-KEM implementation (the post-quantum key-encapsulation mechanism defined in FIPS 203) has passed algorithm testing under NIST’s Cryptographic Algorithm Validation Program and is listed as an approved service inside a cryptographic module certified by the Cryptographic Module Validation Program. If either of those two steps is missing, the product is not validated.

OT and critical infrastructure operators often protect site-to-site links, edge-to-cloud paths and remote engineering access with equipment that will stay in service for ten years or longer. That makes the gap between “supports ML-KEM” and “validated ML-KEM” a procurement question, not just a technical one. This article explains how the validation chain works, how to check it yourself, and where the 2026 FIPS 140-2 sunset leaves existing equipment.

Is ML-KEM approved under FIPS 140-3?

Yes. ML-KEM is an approved algorithm under FIPS 203, and CMVP accepts it as an approved security function inside FIPS 140-3 modules. A specific product only benefits from that approval once its own implementation has been tested and certified.

NIST published FIPS 203 in August 2024. The standard says plainly that “ML-KEM is an approved alternative that is presently believed to be secure, even against adversaries in possession of a large-scale fault-tolerant quantum computer.” It also explains why the algorithm matters for links between sites: the key establishment schemes specified in SP 800-56A and SP 800-56B are vulnerable to attacks that use sufficiently-capable quantum computers.

The companion document is NIST SP 800-227, finalised in September 2025. It makes some requirements and recommendations for implementing and using KEMs in FIPS 140-validated cryptographic modules. In other words, FIPS 203 defines the algorithm, and SP 800-227 explains how to use a KEM correctly inside a validated boundary.

ML-KEM also brings a self-test requirement that validation labs look for. NIST’s CAVP and CMVP staff pointed out that key generation needs either a pairwise consistency test for every key pair or a known-answer test before first use, and that ML-KEM is the first time this is a requirement for Key Generation functions.

What is the difference between CAVP algorithm validation and a CMVP certificate?

CAVP confirms that an algorithm implementation produces correct outputs. CMVP certifies the whole cryptographic module, including its boundary, key management, self-tests and Security Policy. You need both.

The Cryptographic Algorithm Validation Program (CAVP) exists as a branch of the CMVP to perform algorithm tests on cryptographic modules, and it is a NIST programme. Testing runs through NIST’s Automated Cryptographic Validation Test System (ACVTS), where a server sends test inputs and checks the outputs that come back. For ML-KEM, ACVTS checks key generation, encapsulation and decapsulation against the internal algorithms in FIPS 203.

CMVP is broader. It is a joint effort between the National Institute of Standards and Technology under the Department of Commerce and the Canadian Centre for Cyber Security, a branch of the Communications Security Establishment. Accredited Cryptographic and Security Testing (CST) laboratories evaluate the module against FIPS 140-3, which refers to ISO/IEC 19790 and ISO/IEC 24759, and CMVP reviews and issues the certificate.

The adoption numbers show how far apart the two stages are. At NIST’s 2025 Workshop on Guidance for KEMs, the CAVP reported:

• 45 ML-KEM KeyGen and 52 ML-KEM Encap/Decap algorithm validations (NIST, CAVP / CMVP Perspective on KEMs, 2025).

Algorithm certificates usually appear well before module certificates, because CMVP review takes much longer. A vendor quoting an A-number is reporting progress. It is not showing you a validated module.

How do I check whether a cryptographic module has a validated ML-KEM implementation?

Look up the CMVP certificate, open its Security Policy, and confirm that ML-KEM is listed as an approved algorithm with a CAVP reference, for the exact hardware and firmware version you run.

A five-step verification routine

1. Get the certificate number from the vendor. Ask for the CMVP certificate number, not a marketing statement. If the module is still in review, ask whether it appears on the CMVP “Modules In Process” or “Implementation Under Test” lists. Being on those lists is not validation.
2. Search the CMVP Validated Modules database. Check that the status is Active and that the standard is FIPS 140-3. Then note the sunset date.
3. Read the Security Policy’s approved algorithms table. ML-KEM should appear with its CAVP certificate number and the parameter sets tested (ML-KEM-512, -768 or -1024), covering both key generation and encapsulation/decapsulation. If the module uses a combined classical and post-quantum exchange, look for a hybrid KEM entry as well.
4. Cross-check the CAVP entry. CAVP records list the tested operating environment and capabilities. A typical entry shows ML-KEM EncapDecap and ML-KEM KeyGen against a named operating system and processor. Make sure that environment matches what you will deploy, whether that is a physical appliance or a virtual instance on a Linux host in your own cloud.
5. Match the version. The certificate covers specific hardware, firmware and software versions. Compare them with the version running in your substations, plants or data centres.

This check matters because CMVP’s position is strict: “Non-validated cryptography is viewed as providing no protection to the information or data”, which means the data is treated as plaintext wherever validated cryptography is required.

Can hybrid key exchange still be FIPS compliant?

Yes. CMVP Implementation Guidance D.S explicitly recognises approved hybrid KEMs, as long as at least one ML-KEM component is combined with the other method in a way that follows SP 800-227.

Hybrid key agreement combines a classical exchange and a post-quantum KEM into one session key, so an attacker has to break both. SP 800-227 provides guidelines for vendors who wish to securely combine keying material produced via approved post-quantum methods with keying material produced via other (potentially quantum-vulnerable) methods.

CMVP has since put this into its module process. Its supplemental guidance states that IG D.S Key Encapsulation Mechanisms Scenario 2 specifies approved Hybrid KEMs that can be used as part of a module’s approved services, and lists as approved IG D.S Scenario 2 (hybrid KEM) and SP 800-227 Section 4.6.2 using one or more ML-KEM plus one or more non-ML-KEM. Modules declare this as a “KEM-Hybrid” or “KEM-Hybrid-Full” security function, which gives you a specific term to look for in a Security Policy.

Hybrid designs also hold up over time. The hybrid note in NIST IR 8547 says the disallowment of quantum-vulnerable algorithms after 2035 was not intended to apply to hybrid modes that incorporate an approved PQC algorithm alongside a quantum-vulnerable algorithm. For reference, the proposed IR 8547 timeline is:

• Quantum-vulnerable algorithms at 112-bit security strength: deprecated after 2030, disallowed after 2035 (NIST, Dustin Moody, NIST PQC: The Road Ahead, 2025).

Quantum Network’s QPN gateway is one example of the hybrid pattern. It combines a classical part and an ML-KEM part into one session key and renews both handshakes every two minutes. Whatever product you are evaluating, the same rule applies: ask whether the hybrid combination is claimed as an approved service in a CMVP Security Policy, because supporting the design is not the same as having it validated.

Does a firmware update that adds ML-KEM invalidate an existing FIPS certificate?

No. The certificate stays valid for the versions it lists. The new firmware is not covered until the vendor submits a change through a CST laboratory and CMVP accepts it.

This is the point where OT teams most often lose track of their validation status. A CMVP certificate is tied to specific module versions. If you install firmware that adds ML-KEM, your device is running a version that the certificate does not list. The old certificate has not been revoked, but your deployed configuration has moved outside it.

The FIPS 140-3 CMVP Management Manual defines the submission routes for modified modules. Changes that do not affect security can be handled with a lighter administrative update. Adding a new approved algorithm such as ML-KEM affects security by definition, so it needs laboratory testing and, depending on how much has changed, either a partial or a full revalidation. For operators this leads to three practical choices:

What happens to FIPS 140-2 modules after the 2026 transition?

FIPS 140-2 certificates have moved to CMVP’s Historical List. They can still be used in existing systems, but they should not be chosen for new systems.

• Cut-off date: September 21, 2026. Until then, FIPS 140-2 active modules could be used for new systems. After it, the certificates move to the Historical List (NIST CMVP, 2026).
• Active-list period for current validations: 5 years, or 2 years for interim validations (NIST CMVP, 2026).

NIST confirms that even on the historical list, CMVP supports the purchase and use of these modules for existing systems. The FIPS 140-2 Management Manual is firmer about new projects: no new systems should consider the use of validated modules on the historical list. The same rule applies in Canada, where FIPS 140-2 modules could be accepted for Designated Information through September 21, 2026.

None of these legacy modules contain ML-KEM. FIPS 140-2 stopped accepting new validations long before FIPS 203 existed. So any network refresh or new site connection in an OT estate is a chance to move to a FIPS 140-3 module with ML-KEM in its Security Policy, rather than adding another historical device.

How should OT and critical infrastructure operators plan around ML-KEM validation?

Treat validation status as a lifecycle attribute that you track per asset and per link, and phase post-quantum protection in based on how long the data needs to stay confidential.

Former CISA Director Jen Easterly put the urgency this way when CISA, NSA and NIST released their joint factsheet: “It is imperative for all organizations, especially critical infrastructure, to begin preparing now for migration to post-quantum cryptography.” In Canada, the Canadian Centre for Cyber Security published its own roadmap, ITSM.40.001, in June 2025, and that roadmap is a useful reference alongside NIST IR 8547.

Some practical points specific to OT environments:

• Split links by validation requirement. Links that carry regulated or contract-bound data need a module with ML-KEM in its approved services. Other paths, such as air-gapped test networks, may accept validated classical cryptography plus a post-quantum layer that has not been validated yet.
• Write certificate numbers into tenders. Require the CMVP certificate number, a Security Policy that lists ML-KEM (and hybrid KEM, if used), and a vendor commitment on how quickly firmware with new algorithms will be resubmitted.
• Ask how crypto agility is handled during validation. Being able to swap the post-quantum algorithm is valuable. Each swap, however, restarts the CMVP cycle for that version.
• Treat virtual and physical gateways separately. A CAVP entry tested on one operating environment does not automatically cover a virtual deployment on a different Linux platform in your cloud.

Quantum Network designs its QPN gateways for OT site-to-site, edge-to-cloud and remote access connections. When you evaluate any gateway for these paths, the verification routine above is the way to separate validated cryptography from cryptography that is only implemented.