FIPS 140-2 vs 140-3 Validated Modules: How to Read the NIST CMVP List and What 3.13.11 Needs

Validated, compliant and the words in between

Marketing pages use many phrases. Only one of them points to a government record.

• FIPS validated: a certificate exists on the CMVP list for the module that does the encryption.
• FIPS compliant, FIPS ready, FIPS aligned, FIPS capable: no certificate is implied. The product may use approved algorithms such as AES, or may have been designed with the standard in mind, but nobody independent has tested the module.
• Uses a FIPS-validated module: the product relies on a validated library or operating system component. This can be fine, if the certificate covers that exact component and your configuration.

The DoD Assessment Methodology reflects this difference. Requirement 3.13.11 normally costs five points when not met, but it costs three points when encryption is used and it is not FIPS validated. That is the method's own partial-credit rule. It tells you that encryption without validation is better than none, and it still is not full credit.

What the two standards are

FIPS 140-2 and FIPS 140-3 are both federal standards for the security of cryptographic modules, meaning the hardware, software or firmware that performs encryption. FIPS 140-3 became effective on September 22, 2019. Instead of listing the module requirements itself, it points to the international standards ISO/IEC 19790 and ISO/IEC 24759, which define the requirements and the test method. The CMVP began accepting 140-3 submissions in September 2020.

The program has moved in stages. CMVP stopped accepting new 140-2 submissions in September 2021. Its transition table then lists September 21, 2026 as the date up to which 140-2 modules on the Active list can be used for new systems; after that, their certificates are moved to the Historical list. New 140-3 validations go on the Active list for five years. Interim validations last two years.

Reading the CMVP validated modules list

The search page is the official record. Each certificate has a number. Open the certificate detail page and read these fields in order:

• Module name, version and vendor. The version must match what you run. A certificate for version 3.0 does not cover version 4.2.
• Standard: FIPS 140-2 or FIPS 140-3.
• Status: Active, Historical or Revoked. A revoked certificate may not be used to show compliance. Historical means agencies should not put it in new systems, although it may serve legacy ones.
• Validation and sunset dates, which tell you when it moves to Historical.
• Overall level and module type: software, firmware, hardware or hybrid.
• Tested operating environments, meaning the processor and operating system combinations the lab actually tested. Check yours is listed.
• Security policy, a document that states the approved algorithms and how to put the module in its approved mode of operation. Read this one. It is where vendors hide the settings you have to apply.
• Related algorithm validations, which link to the CAVP list.

The Modules in Process list is not a validation

NIST also publishes a list of modules that are being tested. Being on it means a vendor has submitted a module, not that it passed. Do not cite it as evidence of validation.

Where this goes wrong in a real environment

• Wrong build: the vendor has a certificate for an older release and sells you the current one.
• Not in approved mode: the module is validated, but a setting has the product use non-approved algorithms or a different code path.
• Unlisted environment: you run on an operating system or processor that is not among the tested environments.
• Two layers: a database encrypts with its own library while the certificate you found belongs to the operating system library. The module that really performs the encryption is the one that needs the certificate.
• Encryption not in scope: CUI is protected by a VPN or disk encryption that is validated, but the same CUI also travels over a path that is not.

A checklist you can use in a plan

For each place CUI is encrypted at rest or in transit, write down the product, the module that does the work, its certificate number, the status and sunset date, the tested environment and the setting that turns on approved mode. Put that in your system security plan next to requirement 3.13.11. Re-check the list on a schedule, because a certificate that is Active today has a sunset date.

We review cryptography choices for regulated environments as scoped, authorized work. We do not issue validations and we do not act as your assessor.

Sources

• Cryptographic Module Validation Program (NIST CSRC)
• CMVP validated modules: search and status definitions (NIST CSRC)
• FIPS 140-3 standards and documents (NIST CSRC)
• FIPS 140-3, Security Requirements for Cryptographic Modules (NIST)
• CMVP modules in process list (NIST CSRC)
• NIST SP 800-171 Rev. 2, requirement 3.13.11 (NIST)

This article is general information, not legal, contracting or technical advice for your environment. Contract clauses, DoD policy and certification rules are set by the Department of Defense and your contract; check what applies to you with your prime, your contracting officer and counsel. Last reviewed November 9, 2026.

Next article

Next · SecurityMicrosoft Entra Privileged Identity Management for Small Tenants: Just-in-Time Roles, Approval and Break-Glass AccountsMost small tenants have two or three people who are permanent Global Administrators. Privileged Identity Management turns those standing rights into roles people activate for a short time when they need them. Here is a practical setup for a small organization, including the emergency accounts that keep you from locking yourself out.8 min read

Related reading

• RegulationK-12 Student Data Security: FERPA, COPPA and CIPA in Plain Words, and How to Vet an Edtech Vendor8 min
• RegulationWhat a CMMC Level 2 Assessor Examines, Asks and Tests: Evidence and Six-Year Retention9 min