No. Validation means a lab tested a specific cryptographic module against FIPS 140 requirements and the CMVP reviewed it. It says nothing about how your application uses that module, how you manage keys, or whether you pick sound algorithms and settings. It is one input, not a verdict.
What validation is
The Cryptographic Module Validation Program, or CMVP, is a joint effort of NIST and the Canadian Centre for Cyber Security. It aims to promote the use of validated cryptographic modules and gives federal agencies a security metric for procurement. Accredited labs verify that each module meets a set of testable cryptographic and security requirements, and the CMVP reviews and validates each submission.
FIPS 140-3 is the current standard, titled Security Requirements for Cryptographic Modules. CMVP began validating to it on 22 September 2020. Modules are listed as active for 5 years, or 2 years for interim validations.
The 140-2 sunset
The CMVP page says modules validated to FIPS 140-2 can be accepted by federal agencies through 21 September 2026. After that they move to the historical list, where agencies may keep using them only for existing systems. If your product claims a 140-2 module, check which list it is on now and whether your customers care.
What it does and does not tell you
| Question | Answered by validation? |
|---|---|
| Was this module tested by an accredited lab? | Yes |
| Is the module on the active list? | Check the CMVP listing |
| Does your build actually call the validated module? | No, you must verify |
| Is it running in the approved mode? | No, you must verify |
| Are your keys stored and rotated well? | No |
| Is the algorithm choice right for the data? | No |
| Is the rest of the app safe? | No |
The pitfalls tend to be practical. A product may bundle a validated library but ship another crypto implementation for some code paths. A module may be validated only for certain operating environments or versions, and an upgrade may fall outside the listing.
How to approach it as an app team
- Ask whether a customer or rule actually asks for validated modules. Do not adopt the constraint without a reason.
- If yes, name the exact module and version, and check its listing on the CMVP site.
- Configure the platform so the application can only reach validated primitives, and test that it fails closed.
- Record the evidence: module name, version, configuration and where it runs.
- Keep doing the ordinary work: authenticated encryption, key separation, rotation, and a compromise plan.
OWASP's key management guidance says keys should be generated within a cryptographic module with at least FIPS 140-2 or 140-3 compliance, and that hardware modules are preferred over software ones. Note that password hashing guidance from OWASP lists PBKDF2 for cases where FIPS-140 compliance is needed, which shows how the requirement can shape algorithm choice.
Try it yourself
Open the framework mapping demo and see how one control is tied to evidence. A validated module is one piece of evidence for a crypto control, never the whole answer.
Click through it at your own pace, or open it full screen.
Safeguard can generate an SBOM and scan your dependencies, so outdated cryptography libraries with known advisories show up in one inventory, and policies can gate a build on them. A free scan is at gold.safeguard.sh/scan.
Quick check
Is FIPS validated the same as FIPS compliant?
No. Validated refers to a module listed by the CMVP. Compliance claims about a whole product need their own evidence and scope.
Does using AES make my app FIPS validated?
No. The algorithm can be approved while the implementation is not validated.
Sources
- NIST Cryptographic Module Validation Program
- OWASP Key Management Cheat Sheet
- OWASP Password Storage Cheat Sheet
Last reviewed: 19 October 2026.
