FIPS 140-3 Certification
FIPS 140-3 and the CMVP in depth: what a certificate proves, how to read one, and what adding post-quantum cryptography changes for a validated module. Start with Cryptographic Product Certification: Fundamentals for the fundamentals every scheme shares; PCI PTS HSM is covered in PCI Certification.
Why this matters: The lab-tested scheme a network or payment HSM meets first: a FIPS 140-3 certificate proves one module at one version and configuration. Adding ML-KEM or ML-DSA changes the module, and the CMVP accepts that change only through one of its own submission routes.
Start here: Open Level and boundary planner and choose the FIPS 140-3 security level and module boundary for the anchor HSM.
Practitioner orientation — not laboratory training. Owner review recorded on 1 November 2026. Content updated 2 November 2026 since that review; these changes are not covered by that recorded review. Not yet reviewed by an accredited laboratory or certification body.
General security practitioner route
Focus on what each certificate can support, where its boundary stops, and which claims need confirmation. Exact component and submission details remain available as cited reference material.
FIPS 140-3, Security Requirements for Cryptographic Modules, was approved on 22 March 2019, took effect on 22 September 2019 and replaced FIPS 140-2. It is “applicable to all Federal agencies that use cryptography-based security systems to protect sensitive information in computer and telecommunication systems”, and it “provides four increasing, qualitative levels of security”. Canada accepts the same validations for its federal agencies.
The standard itself is short. Its §2 says FIPS 140-3 “is based on ISO/IEC 19790:2012/Cor.1:2015(E) and ISO/IEC 24759:2017(E)”, and the SP 800-140 series lists what NIST supersedes or modifies. ISO published 2025 editions of both documents (ISO/IEC 19790:2025 and ISO/IEC 24759:2025). Three statements have to be read together. FIPS 140-3 §3.1 says: “When referring to ISO/IEC 19790:2012(E) and ISO/IEC 24759:2017(E), the latest edition of the referenced document (including any amendments) applies.” The CMVP’s FIPS 140-3 Standards page still lists only the 19790:2012 and 24759:2017 editions, and the August 2026 IG still cites 19790:2012 throughout. Yet one IG note (IG 4.4.B) says the IG “is consistent with ISO/IEC 19790:2025”. The sources cited here contain no CMVP statement that adopts the 2025 editions or sets a transition date (checked 23 October 2026), so ask the laboratory which edition applies to a submission. Both ISO documents are paid, so this module does not reproduce them. It teaches from public NIST documents and real Security Policies instead.
Five documents, five jobs
| Document | Job | Current version |
|---|---|---|
| FIPS 140-3 | The standard. Names the eleven areas and the four levels, and points to the ISO documents. | Approved 22 March 2019; unchanged |
| ISO/IEC 19790:2012 (Cor.1:2015) and ISO/IEC 24759:2017 | The security requirements (19790) and the test requirements (24759). Paid documents. | The editions FIPS 140-3 names; the CMVP’s standards page lists no 2025 edition |
| SP 800-140, A–F | NIST’s modifications: test requirements, documentation (A), Security Policy format (B), approved security functions (C), key generation and establishment (D), authentication (E), non-invasive attack testing (F). | Per document |
| Implementation Guidance (IG) | How the CMVP interprets the requirements, section by section. | Last update 19 August 2026 |
| Management Manual | How the programme runs: labs, submissions, queue states, revalidation routes. | v2.7, 9 April 2026 |
Versions as of 24 September 2026. The Manual and IG change several times a year; open the live documents before relying on a section number.
Who does what
- The CMVP is “a joint effort between the National Institute of Standards and Technology and the Canadian Centre for Cyber Security” (FIPS 140-3).
- Accredited CST laboratories test. Vendors “use independent, accredited Cryptographic and Security Testing (CST) laboratories to have their modules tested”.
- The vendor contracts the lab, supplies the module and documents, and fixes what the lab finds.
- The CMVP reviews the lab’s submission. If it passes, the validation authorities issue a certificate number (Manual §4.1.1.6).
What gets validated: a module, not a product
A certificate covers a cryptographic module: a defined boundary, at named versions, in tested operational environments, used in its approved mode. Two real Security Policies show how narrow that can be:
- AWS-LC 3 (#5314NIST certificate page for #5314 (opens in a new tab), software): “The cryptographic boundary is defined as … a cryptographic library consisting of the bcm.o file”. The application that links it is outside, and the computer is only the “Tested Operational Environment’s Physical Perimeter”.
- QASM (#5497NIST certificate page for #5497 (opens in a new tab), HSM): the certificate covers the QASM module. The appliances it goes into add an x86 single-board computer running hardened Linux, which the Security Policy describes as a separate part of the product.
Read a certificate, field by field
The certificate page for #5497 (opens in a new tab) — one of the four Level 3 HSMs whose certificates approve ML-KEM and ML-DSA — reads like this as of 24 September 2026:
- Module Name / Standard
- QASM Cryptographic Module · FIPS 140-3
- The validated thing is a named module, not a company or a product line.
- Status / Sunset Date
- Active · 8/18/2031
- Validations expire. Full validations get five years, interim ones two (Manual §7.1.15).
- Overall Level
- 3
- A summary of the per-area levels in the Security Policy (next section).
- Caveat
- When installed, initialized and configured as specified in Section 11.1 of the Security Policy; No assurance of minimum security of SSPs … that are externally loaded …
- The conditions of use. Outside them, you are not running the validated configuration.
- Security Level Exceptions
- Operational environment: N/A · Non-invasive security: N/A · Mitigation of other attacks: N/A
- Where an area is rated differently from the overall level.
- Module Type / Embodiment
- Hardware · MultiChipStand
- What kind of module it is. Changing the embodiment later means a new validation.
- Approved Algorithms
- ML-KEM KeyGen A5631 · ML-DSA SigGen A5631 · SLH-DSA SigGen A5631 · …
- Each approved function with its algorithm-validation (CAVP) reference.
- Related Files / Validation History
- Security Policy · Consolidated Certificate · 8/19/2026 Initial, 8/21/2026 Update (atsec)
- The Security Policy holds the rules; the history shows every revalidation and the lab.
A certificate snapshot for reading practice. Open the live page before quoting it: dates, versions and algorithms change with every revalidation.
Check off all sections and mark this reading done.
Related modules
- Cryptographic Product Certification: FundamentalsSame track · Hardware Infrastructure · Same migration phase · Shares ML-KEM, ML-DSA, FIPS 140-3
- ACVP Lab Workflow: From Vector Set to EvidenceSame track · Hardware Infrastructure · Same migration phase · Shares ML-KEM, ML-DSA, FIPS 140-3
- Confidential Computing & TEEsSame track · Hardware Infrastructure · Shares ML-DSA, ML-KEM, FIPS 140-3
- Secure Boot & Firmware PQCSame track · Hardware Infrastructure · Shares ML-DSA, ML-KEM, FIPS 140-3
Check your understanding
6 questions on FIPS 140-3 Certification, each with its answer and the reason.
Take the quizNext step
Produce the artifact: Vendor Scorecard BuilderThis module belongs to phase 7 (Vendor & Supply Chain); Vendor Scorecard Builder produces a deliverable of that phase in the Command Center.
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.