Read this first
FIPS 140-3 validates a cryptographic MODULE, not an algorithm and not a system. It says a specific version of a specific boundary, built and tested a specific way, met a security standard. It does not say your protocol is right, your key management is sane, or that you use the module correctly. And the date that matters right now is 21 September 2026, when every remaining FIPS 140-2 certificate moves to the historical list.
What it actually is
FIPS 140-3 is the US and Canadian standard for validating cryptographic modules, published on 22 March 2019 and superseding FIPS 140-2. Unlike its predecessor it is not a standalone specification: it adopts ISO/IEC 19790:2012 and ISO/IEC 24759:2017, with the NIST SP 800-140x series carrying the modifications. Validation is run by the Cryptographic Module Validation Program, jointly with Canada's CCCS, through accredited laboratories.
A module here is a bounded thing: a hardware security module, a software cryptographic library, a firmware component. The standard covers the module's boundary and interfaces, roles and authentication, key management across the key lifecycle, physical security where relevant, self-tests, and lifecycle assurance. It is an engineering and process standard about how the container is built, not a statement about the mathematics inside it.
The three things people conflate
| What it validates | Who issues it | What it does not tell you | |
|---|---|---|---|
| FIPS 140-3 (module validation) | That a specific version of a specific module met the security requirements for its boundary, roles, key management and self-tests | CMVP, through an accredited lab | Whether the algorithms inside are correctly implemented in every edge case, or whether you use the module correctly |
| ACVP / CAVP (algorithm validation) | That an algorithm implementation produced the right answers for NIST's test vectors | CAVP, automated | How the implementation behaves on inputs the vectors do not cover, which is where real defects live |
| [Conformance testing](/guides/pqc-conformance-testing) | That an implementation adheres to the specification, including the inputs it is required to REJECT | Anyone, including you | Nothing about module boundaries or operational assurance. It is a different question, not a weaker one |
The relationship matters in one direction: a FIPS 140-3 validated module contains algorithm implementations that carry CAVP certificates, so module validation depends on algorithm validation. Neither depends on conformance testing, which is exactly why we run it separately. Our own conformance work has found implementations that pass every published test vector and still skip a required input check, because a vector suite tests what it contains and nothing else. The full distinction is in ACVP vs conformance vs FIPS 140-3.
The date in front of you
21 September 2026
On that date every remaining FIPS 140-2 certificate moves to the CMVP historical list. This is not a recall: CMVP explicitly supports continued purchase and use of historical-list modules for existing systems. But procurement language, auditors and customer questionnaires frequently treat the active list as the bar, and a module on the historical list will start failing those checks whether or not the underlying cryptography changed.
New FIPS 140-2 submissions closed on 31 March 2022, so anything validated since is already 140-3. The practical question is not whether your vendors have begun, it is whether the specific module versions you deploy are covered, which is a different and usually less comfortable question. That is an inventory task before it is a procurement one.
Where post-quantum fits
FIPS 140-3 is algorithm-agnostic. It does not require post-quantum cryptography and it does not forbid it; it governs the module, while the approved-algorithm question is settled by the SP 800-140x series and the underlying algorithm standards. ML-KEM, ML-DSA and SLH-DSA were finalised as FIPS 203, FIPS 204 and FIPS 205 in August 2024, which is what makes them eligible to appear inside a validated module at all.
Which specific modules carry post-quantum validation today changes continually, and any number written on a page like this is wrong within weeks. The honest answer is the CMVP validated modules search, and the honest planning assumption is that validated post-quantum modules will lag the standards by a meaningful margin, because validation always lags. If a mandate requires you to be on validated modules, that lag is on your critical path and belongs in your migration plan rather than in a surprise the quarter before an audit.
What to do with this
- Inventory modules, not just algorithms. Record which validated module version each system actually loads. This is the input to both the 2026 date and any post-quantum requirement, and almost nobody has it.
- Ask vendors the specific question. Not "are you FIPS validated" but "which certificate number, which module version, and is it 140-3". The first question always gets a yes.
- Do not treat validation as correctness. It is a floor for procurement, not evidence the implementation handles malformed input properly. Test that separately.
- Sequence it against the real deadlines. Module validation is a supply-chain dependency with its own lead time, sitting inside the migration windows on the deadlines page.
Frequently asked questions
Does FIPS 140-3 require post-quantum cryptography?
No. FIPS 140-3 governs how a cryptographic module is built and validated, not which algorithms you must use. The post-quantum requirement, where you have one, comes from elsewhere: NIST IR 8547's 2030 and 2035 dates, CNSA 2.0 for national-security systems, or a sector regulator. FIPS 140-3 is the mechanism by which a module containing those algorithms gets validated, not the reason to adopt them.
What happens on 21 September 2026?
Every remaining FIPS 140-2 certificate moves to the CMVP historical list. Modules on that list can still be purchased and used for existing systems, and CMVP says so explicitly. The practical impact is procedural: procurement rules, auditors and customer security questionnaires often treat active-list status as the requirement, so a historical-list module starts failing paperwork even though nothing about it changed.
Is a FIPS 140-3 validated module guaranteed to implement ML-KEM correctly?
No, and this is the most consequential misunderstanding about validation. Module validation covers the boundary, roles, key management and self-tests, and the algorithms inside carry CAVP certificates proving they match NIST's test vectors. Neither exercises the inputs a specification requires an implementation to reject. We have tested implementations that pass every published vector and still skip a required check.
What is the difference between FIPS 140-3 and CAVP or ACVP validation?
ACVP is the protocol behind CAVP algorithm validation: it proves an algorithm implementation produced the right answers for NIST's vectors. FIPS 140-3 validates the module that contains those implementations, covering boundary, roles, key management, physical security and self-tests. Module validation depends on algorithm validation, not the other way round.
Which modules are validated for ML-KEM today?
This changes continually, so the only correct answer is the CMVP validated modules search rather than a figure on a page. The planning assumption worth holding is that validated post-quantum modules lag the algorithm standards by a meaningful margin, and if a mandate requires validated modules, that lag sits on your critical path.