FIPS 140-3: cryptographic module validation
FIPS 140-3 (Federal Information Processing Standard 140-3) was approved by the US Secretary of Commerce on 22 March 2019 and took effect on 22 September 2019. It sets the security requirements for cryptographic modules used by US federal agencies, and the validation programme that tests against it, the CMVP (Cryptographic Module Validation Program), is run jointly by NIST and the Canadian Centre for Cyber Security, so a single certificate serves both governments. Since 21 September 2026 every FIPS 140-2 certificate has left the Active list, which makes FIPS 140-3 the only standard behind an active certificate. This guide is written from the CMVP texts as they stand on 7 October 2026: the Implementation Guidance of 19 August 2026, the Management Manual of 9 April 2026, the SP 800-140C and SP 800-140D lists with their change logs, the 2026 NIST fees and the live queue.
Where things stand on 7 October 2026
Section titled “Where things stand on 7 October 2026”| Item | Current state | Source |
|---|---|---|
| FIPS 140-2 | Usable for new systems until 21 September 2026; all certificates then placed on the Historical List | CMVP overview, transition schedule |
| FIPS 140-3 Implementation Guidance | Last update 19 August 2026 (new IG 1.B on hybrid modules) | IG announcements |
| CMVP FIPS 140-3 Management Manual | Version 2.7, 9 April 2026 | Management Manual page |
| SP 800-140C (approved security functions) | Last change 22 June 2026: SP 800-90C random bit generator constructions added | SP 800-140C change log |
| SP 800-140D (key generation and establishment) | 9 April 2026: SP 800-227 (key encapsulation), RFC 5869 (HKDF) and the SPDM key schedule added | SP 800-140D change log |
| Normative references of FIPS 140-3 | Still ISO/IEC 19790:2012 (with the 2015 corrections) and ISO/IEC 24759:2017 | SP 800-140F section 2 |
| ISO/IEC 19790 and 24759 | New editions published 26 February 2025 (19790 edition 3, 24759 edition 4), not yet referenced by FIPS 140-3 | IEC catalogue |
| Modules In Process list (7 October 2026) | 191 FIPS 140-3 entries: 27 Pending Review, 54 Review, 66 Comment Resolution (lab), 26 Comment Resolution (CMVP), 17 Pending Resubmission, 1 Cost Recovery | CMVP MIP list |
Two details in that last row are worth reading carefully. The MIP list is voluntary (vendor and lab decide whether a module appears), so it is not the whole queue. And the date shown is when a module entered its current state: on 7 October 2026 the oldest "Pending Review" entry had been waiting since 8 August 2025. Any lead time you plan should come from your laboratory and the current list, not from a figure in a guide.
FIPS 140 lineage
Section titled “FIPS 140 lineage”The NIST catalogue shows a FIPS 140 of 13 April 1982, superseded by FIPS 140-1 on 11 January 1994. FIPS 140-2 was published on 25 May 2001 (Change Notice 2 dated 3 December 2002) and FIPS 140-1 was withdrawn on 25 May 2002. FIPS 140-3 superseded FIPS 140-2 in 2019.
| Version | Date | Status on 7 October 2026 |
|---|---|---|
| FIPS 140 | 13 April 1982 | Superseded by FIPS 140-1 |
| FIPS 140-1 | 11 January 1994 | Withdrawn 25 May 2002 |
| FIPS 140-2 | 25 May 2001 | Superseded; all certificates on the Historical List since September 2026 |
| FIPS 140-3 | Approved 22 March 2019, effective 22 September 2019 | In force; CMVP has accepted submissions since 22 September 2020 |
The structural change in FIPS 140-3 is that it no longer writes its own requirements. NIST describes it this way: "Rather than encompassing the module requirements directly, FIPS 140-3 references ISO/IEC 19790:2012", with testing done under ISO/IEC 24759:2017. CMVP, acting as validation authority, then modifies or replaces parts of those ISO texts through the SP 800-140 series and the Implementation Guidance (IG). This is why a new ISO edition does not change what a CMVP submission is judged against until NIST says so.
CMVP, CAVP, CSTL: who does what
Section titled “CMVP, CAVP, CSTL: who does what”| Actor | What it does | Output |
|---|---|---|
| CMVP (NIST and CCCS) | Reviews the lab test report and validates the whole module against FIPS 140-3 | Module certificate on the validated modules list |
| CAVP (NIST) | Validates algorithm implementations through the ACVTS servers | Algorithm certificate, a prerequisite for claiming an approved algorithm |
| CSTL | Independent laboratory accredited by NVLAP; tests the module and submits the report | Test report and recommendation to CMVP |
| NIST Billing | Collects the cost-recovery fee; a submission in the "Cost Recovery" state cannot move on until it is paid | Payment that unlocks review |
The CMVP page states that CMVP "is a joint effort" between NIST and the Canadian Centre for Cyber Security, and the Cyber Centre describes itself as "the Canadian certification authority". It also states that each CSTL "is an independent laboratory accredited by NVLAP", and the Cyber Centre sends would-be laboratories to the NVLAP web site. The production ACVTS server "is only available to NVLAP-accredited testing laboratories, and is the only way to create algorithm validation certificates".
The four security levels
Section titled “The four security levels”FIPS 140-3 inherits four levels and eleven requirement areas from ISO/IEC 19790:2012 (module specification; interfaces; roles, services and authentication; software/firmware security; operational environment; physical security; non-invasive security; sensitive security parameter management; self-tests; life-cycle assurance; mitigation of other attacks). The rows below are the ones the FIPS 140-3 IG quotes or interprets explicitly.
| Requirement | Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|---|
| Operator authentication | Not required | Role-based at minimum | Identity-based | Multi-factor identity-based (AS04.59) |
| Trusted channel for plaintext critical security parameters | No requirement | No requirement | Required; ports physically separated or interfaces logically separated | As level 3, with multi-factor identity-based authentication |
| Physical security | Production-grade | Tamper evidence | Tamper detection and response with zeroisation | Tamper detection and response with zeroisation |
| Environmental failure protection | No | No | Yes (zeroisation, shutdown or error state on failure, AS07.81) | Yes |
| Modifiable operating system | Control of its own sensitive security parameters | Adds an audit mechanism ("Security Level 2 only") | Nothing added | Nothing added |
| Non-invasive security (section 7.8) | Not applicable in CMVP until SP 800-140F defines metrics | Same | Same | Same |
The last row is the one most summaries get wrong. The IG states that "the requirements of ISO/IEC 19790:2012 section 7.8 Non-invasive security are non-applicable until defined in SP 800-140F", and section 6.2 of SP 800-140F reads "No additional requirements at this time". Until that changes, a vendor that has designed and publicly documented a side-channel countermeasure has it verified under section 7.12, mitigation of other attacks.
Module types and the hybrid question
Section titled “Module types and the hybrid question”ISO/IEC 19790 defines hardware, software, firmware and hybrid modules, and a hybrid is either a hybrid software or a hybrid firmware module: software or firmware combined with a disjoint hardware component inside one cryptographic boundary. The IG published on 19 August 2026, IG 1.B, clarifies what a hybrid is when its components sit on one system-on-chip, including a sub-chip hardware component. Its examples include a hybrid software module whose disjoint hardware is a PCIe accelerator card, and a hybrid software module whose disjoint hardware is a processor algorithm implementation inside the CPU.
Processor acceleration is where classification is decided by testing, not by intent. IG 2.3.C lists AES-NI as a known Processor Algorithm Accelerator (PAA). A module whose operational environments were all tested only with PAA/PAI is a hybrid. It stays a software or firmware module only if it is tested both with and without the accelerator, either on every operational environment or on at least one environment each way, and the accelerated algorithms must be CAVP-tested in both modes.
Approved algorithms: SP 800-140C and SP 800-140D
Section titled “Approved algorithms: SP 800-140C and SP 800-140D”SP 800-140C Rev. 2 and SP 800-140D Rev. 2 (both July 2023) replace annexes C and D of ISO/IEC 19790. NIST now keeps the live lists on two supplemental pages with dated change logs, so a function can be added without a new revision of the SP. The split matters: signatures, hashes, message authentication codes and random bit generators are in 140C; key generation, key derivation, key agreement, key transport and key encapsulation are in 140D.
| Family | Listed references | List | Recent change |
|---|---|---|---|
| Block cipher | AES (FIPS 197-upd1) with SP 800-38A to 38G modes; three-key Triple-DES | 140C | Since 1 January 2024 Triple-DES is only approved for decryption, unwrapping or CMAC verification for legacy use |
| Digital signature | DSA, RSA, ECDSA, EdDSA (FIPS 186-4 and 186-5), ML-DSA (FIPS 204), SLH-DSA (FIPS 205); LMS, HSS, XMSS (SP 800-208) | 140C | FIPS 204 and 205 added 13 August 2024 |
| Hash and XOF | SHA-1 and SHA-2 (FIPS 180-4), SHA-3 and SHAKE (FIPS 202), SP 800-185 functions, Ascon-Hash256, Ascon-XOF128, Ascon-CXOF128 | 140C | Ascon (SP 800-232) added 2 September 2025 |
| Message authentication | CMAC, CCM, GCM/GMAC, HMAC, KMAC, Ascon-AEAD128 | 140C | Ascon added 2 September 2025 |
| Random bits | SP 800-90B entropy sources, SP 800-90A Rev. 1 DRBG mechanisms, SP 800-90C constructions | 140C and 140D | SP 800-90C added 22 June 2026 |
| Key agreement | SP 800-56A Rev. 3 (DH, ECDH), SP 800-56B Rev. 2 (RSA) | 140D | |
| Key derivation | SP 800-56C Rev. 2, RFC 5869 (HKDF), SP 800-108r1-upd1, SP 800-132, SP 800-135 Rev. 1, TLS 1.3 key schedule, SPDM key schedule | 140D | HKDF and SPDM added 9 April 2026 |
| Key transport | SP 800-38F key wrapping; SP 800-56B Rev. 2 key encapsulation | 140D | |
| Key-encapsulation mechanism | ML-KEM (FIPS 203), SP 800-227 | 140D | FIPS 203 added 13 August 2024; SP 800-227 added 9 April 2026 |
SHA-1 still appears in the FIPS 180-4 entry, but what it may be used for is governed by SP 800-131A Rev. 2, which both lists cite under "Transitions". DES and MD5 are not listed. A module can contain non-approved algorithms, but they cannot be used in the approved mode, and IG 2.4.A defines how such functions must be treated.
Post-quantum migration
Section titled “Post-quantum migration”NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) on 13 August 2024 and says they "can and should be put into use now". On the CMVP side, all three entered the approved lists the same day, the IG self-test rules for them were added on 13 August 2024 and revised on 18 April 2025 and 2 September 2025, and IG D.S on key-encapsulation mechanisms (2 September 2025) gained a hybrid-KEM scenario on 9 April 2026.
Standardisation continues. NIST selected HQC as a second KEM on 11 March 2025 and said a final standard would follow in approximately two years; the Falcon signature is also in standardisation, and a separate call for additional signature schemes is running. NIST IR 8547, still an initial public draft (12 November 2024), sets out the plan to deprecate and then remove quantum-vulnerable algorithms from NIST standards by 2035. For national security systems the NSA has its own suite, CNSA 2.0, which specifies ML-KEM-1024 and ML-DSA-87.
FIPS 140-2 to FIPS 140-3: the full timeline
Section titled “FIPS 140-2 to FIPS 140-3: the full timeline”| Date | Event |
|---|---|
| 22 March 2019 | FIPS 140-3 approved |
| 22 September 2019 | FIPS 140-3 effective date |
| 20 March 2020 | SP 800-140 series published |
| 21 September 2020 | First FIPS 140-3 Implementation Guidance and Management Manual |
| 22 September 2020 | CMVP begins accepting FIPS 140-3 submissions |
| 14 June 2021 | Last date a CSTL could accept contracts for FIPS 140-2 Scenario 5 and Scenario 3 |
| 22 September 2021 | No new FIPS 140-2 certificates, except for vendors under contract with a CSTL before 15 June 2021 whose extension request CMVP accepted |
| 1 April 2022 | CMVP accepts only FIPS 140-2 reports that do not change the sunset date (IG G.8 scenarios 1, 1A, 1B, 3A, 3B and 4) |
| 6 June 2024 | Two-year interim validations begin for modules submitted before 1 January 2024 |
| 21 September 2026 | Last day FIPS 140-2 modules can be used for new systems |
| 22 September 2026 | All FIPS 140-2 certificates placed on the Historical List (transition schedule) |
NIST gives the sunset in two forms, one day apart: the CMVP overview says 140-2 modules can be used "through September 21, 2026", the transition schedule moves them to the Historical List on 22 September 2026. Both describe the same switch.
What "historical" means is set out on the validated modules page: "Federal Agencies should not include these in new systems but can be procured for legacy systems. This does not mean that the overall FIPS-140 certificates for these modules have been revoked." A revoked certificate is different: it "may not be referenced to demonstrate compliance".
Keeping a FIPS 140-3 certificate active
Section titled “Keeping a FIPS 140-3 certificate active”A new module is validated through a Full Submission (FS). Upon validation it goes on the Active list for five years, or two years for an interim validation. The Management Manual describes the interim route as "a temporary measure to shorten the queue", with more reliance on the CSTL and less CMVP oversight. An INTU submission in the SP 800-140B Rev. 1 format, received before the two-year sunset, extends it to five years from the interim validation date.
Changes after validation go through one of the Management Manual scenarios, and the scenario decides both the fee and the sunset date.
| Scenario | Used for | Sunset date | 2026 NIST cost-recovery fee |
|---|---|---|---|
| FS, Full Submission | New module, or changes that fit no revalidation scenario | 5 years (2 years if interim) | $16,000 (level 1), $17,000 (level 2), $17,500 (level 3), $19,000 (level 4) |
| UPDT, Update | Security-relevant changes with full testing of the affected sections | 5 years (2 years if interim) | $5,500 |
| ALG, OEUP, PTSC, CVE, TRNS, PHYS, NSRL, RBND | Algorithm update, new operational environment, sub-chip port, CVE fix, algorithm transition, enclosure change, non-security-relevant change, rebrand | Unchanged or inherited from the original certificate | $2,500 |
| VUP, VAOE | Administrative update, vendor-affirmed operational environment | Unchanged | $0 |
An extended cost-recovery fee may be added when the review needs more time: $1,000 for VUP, VAOE and the $2,500 scenarios, $1,500 for UPDT, and $3,000 (level 1) or $4,000 (levels 2 to 4) for a full submission. These are NIST fees only; the laboratory quote comes on top. A new operational environment is not a paperwork change either: OEUP requires CAVP testing on the new environment and the full regression test suite.
Relationship to ISO/IEC 19790 and 24759
Section titled “Relationship to ISO/IEC 19790 and 24759”| Text | Role in CMVP today |
|---|---|
| ISO/IEC 19790:2012 (with 2015 corrections) | Security requirements, referenced by FIPS 140-3 |
| ISO/IEC 24759:2017 | Test requirements, as modified by SP 800-140 |
| SP 800-140A, 140B Rev. 1 | Changes to vendor documentation and to the Security Policy (19790 annexes A and B) |
| SP 800-140C Rev. 2, 140D Rev. 2 | Replace annexes C and D (approved functions, SSP generation and establishment) |
| SP 800-140E, 140F | Replace annexes E and F (authentication mechanisms, non-invasive metrics) |
| FIPS 140-3 IG | Interpretations, last updated 19 August 2026 |
| ISO/IEC 19790:2025, ISO/IEC 24759:2025 | Published 26 February 2025; not referenced by FIPS 140-3 as of 7 October 2026 |
Claims the texts contradict
Section titled “Claims the texts contradict”| Common claim (including earlier versions of this page) | What the primary text says |
|---|---|
| "ML-KEM is not in SP 800-140C, so key encapsulation cannot be claimed yet" | Key encapsulation belongs to SP 800-140D, where FIPS 203 was added on 13 August 2024 (SP 800-140D change log) |
| "Level 3 requires documented side-channel testing, level 4 a side-channel evaluation" | Section 7.8 is not applicable until SP 800-140F defines metrics, and SP 800-140F has none (IG; SP 800-140F section 6.2) |
| "At level 2 the operating system must be evaluated against a Common Criteria protection profile" | The FIPS 140-3 level 2 operating-system requirement quoted in the IG is an audit mechanism ("Security Level 2 only") |
| "At level 3 the CSP ports must be physically separated" | Ports physically separated or interfaces logically separated, through a trusted channel (IG text of 19790 section 7.3.4) |
| "A library using AES-NI is generally accepted as a software module" | Only if tested with and without the accelerator; if every environment was tested only with PAA/PAI, the module is a hybrid (IG 2.3.C) |
| "SP 800-140A modifies ISO/IEC 24759 test methods" | SP 800-140 is the derived test requirements; SP 800-140A modifies vendor documentation requirements (19790 annex A) |
| "Historical 140-2 certificates can no longer be used by federal agencies" | Not in new systems, but they can be procured for legacy systems; historical is not revoked (validated modules page) |
| "FIPS 140-1 was the first version" | NIST lists a FIPS 140 of 13 April 1982, superseded by FIPS 140-1 |
| "A product with CAVP certificates for its algorithms is FIPS 140-3 compliant" | NIST: a product "does not meet the FIPS 140-2 or FIPS 140-3 requirements by simply implementing an approved security function and acquiring algorithm validation certificates" |
| "Designed for FIPS 140" or "FIPS 140 ready" is an acceptable claim | The Cyber Centre rejects every such wording; only "validated and has received Certificate #..." is acceptable |
Common pitfalls
Section titled “Common pitfalls”Quoting a certificate number without checking its status. Look the number up on the validated modules list: active, historical or revoked change what a buyer may do with it.
Treating a CAVP certificate as a validation. Algorithm certificates are a prerequisite of the module submission, not a substitute for it.
Ignoring processor acceleration. Decide early whether you will test with and without PAA/PAI; otherwise the module is classified as a hybrid (IG 2.3.C).
Changing the operational environment after validation. A different OS or platform is an OEUP with CAVP testing and the full regression suite, not an editorial change.
Letting an interim validation lapse. The INTU submission must reach CMVP before the two-year sunset or the certificate goes to the Historical List.
Asking for a "FIPS letter" instead of a certificate. CMVP suggests buyers ask the vendor for a signed letter, a form of vendor attestation, stating that the product is or embeds a validated module and giving the certificate number, then check that number against the list. The letter points to the certificate, it does not replace it.
FIPS 140-2 and FIPS 140-3 compared
Section titled “FIPS 140-2 and FIPS 140-3 compared”| Dimension | FIPS 140-2 | FIPS 140-3 |
|---|---|---|
| Requirements text | In the FIPS itself | ISO/IEC 19790:2012 by reference, modified by SP 800-140x |
| Test requirements | NIST Derived Test Requirements | ISO/IEC 24759:2017, modified by SP 800-140 |
| Approved functions | Annexes to FIPS 140-2 | SP 800-140C and SP 800-140D, maintained with dated change logs |
| Non-invasive security | Not a separate area | Separate area (7.8), not applicable in CMVP until SP 800-140F metrics exist |
| Level 4 authentication | Identity-based | Multi-factor identity-based |
| New submissions | Closed | Open |
| Certificates | All on the Historical List since September 2026 | 5 years active, 2 years for an interim validation |
For a vendor: a practical approach
Section titled “For a vendor: a practical approach”1. Check the requirement. Find out who asks for FIPS 140-3 and at which level: a US or Canadian federal buyer, a contract clause, or an integrator that needs a validated module inside its own product.
2. Consider embedding a validated module. A product can rely on a module already validated by someone else, and IG 1.A sets the conditions for binding and embedding modules. That may be enough for the buyer, provided the module provides all the cryptographic services.
3. Fix the boundary, type and level early. The module type (hardware, software, firmware, hybrid), the use of PAA/PAI and the target level per area drive the test scope.
4. Get algorithm certificates first. Each approved algorithm needs CAVP testing through the lab, on each operational environment that will be listed.
5. Write the Security Policy in the SP 800-140B Rev. 1 format. It is public after validation, and NIST cites the automated processing of submissions in this format as one way to reduce the backlog.
6. Plan the life cycle. Budget the revalidation scenarios and the five-year (or two-year interim) sunset, and watch the IG change summary, which NIST updated three times in 2026 (27 February, 9 April and 19 August).
For European radio products, these choices sit next to RED obligations and the IoT cybersecurity provisions of EN 303 645, which are separate frameworks and do not reference FIPS 140-3. For vendors also examining a Common Criteria ISO/IEC 15408 route, the analysis of the cryptographic boundary and the security functions can feed both dossiers, although each scheme has its own documents. The glossary consolidates the acronyms.
See also
Section titled “See also”- Product cybersecurity: obligation, evaluation, label
- TPM 2.0 and TCG hardware security
- CSPN and ANSSI Visa: French cybersec certification
- CMMC and UK Cyber Essentials: defense cyber baselines
- PSA Certified: Arm-led IoT security baseline
- SESIP: IoT platform security evaluation methodology
- Cyber Resilience Act (CRA)
Outlook
Section titled “Outlook”Three things to watch. First, whether and when NIST moves FIPS 140-3 to the 2025 editions of ISO/IEC 19790 and 24759: until it does, the 2012 and 2017 editions remain the reference. Second, the post-quantum lists: HQC and Falcon are still to be standardised, and NIST IR 8547 is still a draft. Third, the queue: the interim route and the automated processing of SP 800-140B Rev. 1 Security Policies are the levers NIST itself cites to reduce the backlog.
For a European vendor, FIPS 140-3 is not part of CE marking. It is a contractual requirement where a buyer asks for it, and since 21 September 2026 only a FIPS 140-3 certificate on the Active list answers it for a new system.
Further reading
Section titled “Further reading”- Common Criteria ISO/IEC 15408: generic security-evaluation framework, complementary to FIPS 140-3
- ETSI EN 303 645: cybersecurity for consumer IoT
- RED: European framework for radio equipment and its interplay with product cybersecurity
- Glossary: definitions of CMVP, CAVP, CSTL, ISO/IEC 19790
Sources & references
- FIPS 140-3, Security Requirements for Cryptographic Modules, NIST csrc.nist.gov/pubs/fips/140-3/final
- Cryptographic Module Validation Program (CMVP), overview and applicability of validated modules, NIST csrc.nist.gov/projects/cryptographic-module-validation-program
- FIPS 140-3 Transition Effort, transition schedule, NIST csrc.nist.gov/projects/fips-140-3-transition-effort
- CMVP Validated Modules, meaning of Historical and Revoked, NIST csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules
- FIPS 140-3 IG and RFG Announcements (Implementation Guidance, last update August 19, 2026), NIST and CCCS csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-ig-announcements
- CMVP FIPS 140-3 Management Manual (version 2.7, April 9, 2026), NIST and CCCS csrc.nist.gov/projects/cryptographic-module-validation-program/cmvp-fips-140-3-management-manual
- NIST SP 800-140, FIPS 140-3 Derived Test Requirements, and its A to F parts, NIST csrc.nist.gov/pubs/sp/800/140/final
- SP 800-140C: Approved Security Functions (supplemental list and change log), NIST csrc.nist.gov/projects/cryptographic-module-validation-program/sp-800-140-series-supplemental-information/sp800-140c
- SP 800-140D: Approved SSP Generation and Establishment Methods (supplemental list and change log), NIST csrc.nist.gov/projects/cryptographic-module-validation-program/sp-800-140-series-supplemental-information/sp800-140d
- NIST SP 800-140F, CMVP Approved Non-Invasive Attack Mitigation Test Metrics, NIST csrc.nist.gov/pubs/sp/800/140/f/final
- CMVP Modules In Process List, NIST csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-process/modules-in-process-list
- CMVP NIST Cost Recovery Fees (2026 fees), NIST csrc.nist.gov/projects/cryptographic-module-validation-program/nist-cost-recovery-fees
- Cryptographic Algorithm Validation Program (CAVP), NIST csrc.nist.gov/projects/cryptographic-algorithm-validation-program
- Cryptographic Module Validation Program (CMVP), Canadian Centre for Cyber Security www.cyber.gc.ca/en/tools-services/cryptographic-module-validation-program-cmvp
- FIPS 140-2, Security Requirements for Cryptographic Modules, NIST csrc.nist.gov/pubs/fips/140-2/upd2/final
- ISO/IEC 19790:2025, Security requirements for cryptographic modules (catalogue entry), IEC webstore.iec.ch/en/publication/105940
- ISO/IEC 24759:2025, Test requirements for cryptographic modules (catalogue entry), IEC webstore.iec.ch/en/publication/105942
- Post-Quantum Cryptography project, FIPS 203, 204, 205 and ongoing standardisation, NIST csrc.nist.gov/projects/post-quantum-cryptography
- HQC announced as a 4th round selection (March 11, 2025), NIST csrc.nist.gov/news/2025/hqc-announced-as-a-4th-round-selection
- NIST IR 8547 (initial public draft), Transition to Post-Quantum Cryptography Standards, NIST csrc.nist.gov/pubs/ir/8547/ipd
- Announcing the Commercial National Security Algorithm Suite 2.0, NSA media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
Frequently asked questions
- Is FIPS 140-3 mandatory in Europe?
- No. FIPS 140-3 is a US federal standard. NIST states that it applies to all US federal agencies that use cryptographic-based security systems to protect sensitive information, and the Canadian Centre for Cyber Security co-runs the validation programme and is its Canadian certification authority. No EU act requires it. European buyers may still ask for a CMVP certificate in a contract, but that is a contractual requirement, not a legal one.
- What is the difference between CMVP and CAVP?
- CAVP validates algorithm implementations (AES, SHA-2, ML-KEM and so on) through test vectors generated by the NIST ACVTS server, which only NVLAP-accredited laboratories can use for production certificates. CMVP validates the whole cryptographic module against FIPS 140-3. NIST says plainly that a product does not meet FIPS 140-3 by implementing an approved security function and holding algorithm certificates: only a module validation does that.
- What happened to FIPS 140-2 certificates in September 2026?
- CMVP states that FIPS 140-2 modules could be used for new systems until 21 September 2026, after which the certificates move to the Historical List (the transition schedule dates that move 22 September 2026). A historical certificate is not revoked: agencies should not put it in new systems, but may keep using it, and may procure it, for existing systems.
- How long is a FIPS 140-3 certificate active?
- Five years from the validation date, or two years for an interim validation. An interim validation can be converted to a full five-year one by an INTU submission in the SP 800-140B Rev. 1 format, which must reach CMVP before the two-year sunset. After the sunset the certificate moves to the Historical List.
- What are the four security levels of FIPS 140-3?
- FIPS 140-3 takes them from ISO/IEC 19790:2012. Operator authentication is not required at level 1, is at least role-based at level 2, identity-based at level 3 and multi-factor identity-based at level 4. Physical security goes from tamper evidence (level 2) to tamper detection and response with zeroisation (levels 3 and 4), with environmental failure protection at levels 3 and 4. Plaintext critical security parameters entering or leaving the module need a trusted channel at levels 3 and 4.
- Does FIPS 140-3 test side-channel resistance?
- Not as a level requirement today. The FIPS 140-3 Implementation Guidance states that the non-invasive security requirements of ISO/IEC 19790 section 7.8 are not applicable until SP 800-140F defines test metrics, and SP 800-140F still says "No additional requirements at this time". A vendor that claims a mitigation has it checked under section 7.12, mitigation of other attacks.
- Can ML-KEM be claimed in a FIPS 140-3 module?
- Yes. ML-KEM (FIPS 203) is a key-establishment method, so it is listed in SP 800-140D, not SP 800-140C: CMVP added it there on 13 August 2024, the day ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) were added to SP 800-140C. SP 800-227 on key-encapsulation mechanisms was added to SP 800-140D on 9 April 2026, and Implementation Guidance D.S covers key encapsulation, including the hybrid case.
- Who accredits the testing laboratories and how much does NIST charge?
- Every CSTL is an independent laboratory accredited by NVLAP; the Canadian Centre for Cyber Security sends prospective Canadian labs to NVLAP as well. NIST then charges a cost-recovery fee per submission. For 2026 a full submission costs $16,000 at level 1 up to $19,000 at level 4, plus an extended fee of up to $4,000 when the review needs more time. Laboratory test fees are separate and set by each lab.