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 LM-065 for the fundamentals every scheme shares; PCI PTS HSM is covered in LM-071.
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. Not yet reviewed by an accredited lab or certification body.
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. The CMVP has not adopted them, and the August 2026 IG still cites 19790:2012 as of 24 September 2026. 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. | These editions are pinned; the 2025 editions are not adopted |
| 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 (#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 (#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
- 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
- Common Criteria, EUCC & eIDAS CertificationSame track · Hardware Infrastructure · Same migration phase · Shares ML-KEM, ML-DSA
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.