Federal Information Processing Standard 140-3 (FIPS 140-3), Security Requirements for Cryptographic Modules, is a US government standard published by the National Institute of Standards and Technology in March 2019. It specifies security requirements for the hardware, software and firmware components that perform encryption and related functions, called cryptographic modules. Modules are tested by accredited labs and validated through the Cryptographic Module Validation Program (CMVP), run jointly by NIST and the Canadian Centre for Cyber Security. FIPS 140-3 supersedes FIPS 140-2 and aligns with the international standards ISO/IEC 19790 and ISO/IEC 24759.
At a glance
- It applies to cryptographic modules, not whole products, companies or systems.
- It defines four increasing, qualitative security levels, from Level 1 to Level 4.
- Validation means lab testing plus a CMVP certificate for a specific module version and configuration.
- FIPS 140-2 validated modules were accepted through September 21, 2026, then moved to the Historical list.
- US federal agencies and their contractors are the main users; many commercial buyers use it as a benchmark too.
What problem it solves
Encryption only protects data if it is implemented correctly. Weak random number generation, keys left exposed in memory, unapproved algorithms or modules that fail silently can undermine encryption that looks fine on a data sheet. A buyer usually has no way to inspect that.
FIPS 140-3 gives a common, independently tested baseline. When a module is validated, an accredited lab has checked it against defined requirements and the CMVP has reviewed the results. For buyers, the certificate number turns a vague “military-grade encryption” claim into something checkable: which module, which version, which level and which operating environment.
How it works
Scope of requirements. The standard covers areas such as module specification and interfaces; roles, services and authentication; software and firmware security; operating environment; physical security; non-invasive security; management of keys and other sensitive security parameters; self-tests; life-cycle assurance; and mitigation of other attacks.
Approved functions. A conforming module uses approved security functions, such as algorithms and key management techniques specified in NIST standards and recommendations.
Testing and validation. The vendor hires an accredited Cryptographic and Security Testing laboratory, which tests the module and submits a report. The CMVP reviews it and, if satisfied, issues a certificate listing the module, version, level, tested environments and approved functions. Review times vary and can be long.
Lists. Validated modules appear on the CMVP’s validated modules list. Modules whose certificates have expired or been moved, including former FIPS 140-2 certificates after the transition, appear on the Historical list, which NIST says should not be used for procurement decisions.
Security levels
FIPS 140-3 defines four levels. Each adds requirements to the one below it; detailed requirements come from ISO/IEC 19790 as modified by NIST. The descriptions below are general and simplified.
| Level | General idea | Typical modules | What to check on the certificate |
|---|---|---|---|
| Level 1 | Basic security requirements; no specific physical protection beyond production-grade components | Software libraries and many operating system crypto modules | Module name, version and tested operating environments |
| Level 2 | Adds requirements such as evidence of tampering and role-based authentication | Some appliances, tokens and hardware modules | Physical security level and roles |
| Level 3 | Stronger protection against physical access and tampering, and stronger operator authentication | Many hardware security modules | Overall level and any lower-level sections |
| Level 4 | Highest level, for modules in physically unprotected environments | Specialized high-security hardware | Overall level and environmental protections |
A certificate states an overall level, and the module’s documentation can show different levels for individual areas. This is general information, not legal advice; the required level depends on your contract, program or agency.
When it matters for buyers
- When selling to or serving US federal agencies. Contracts and programs commonly require validated cryptography for protecting sensitive data.
- When choosing a cloud service for FedRAMP-related work. Ask whether encryption uses validated modules and in which services and regions.
- When buying an HSM or key management service. The validation level and mode are central to the purchase.
- When FIPS 140-2 certificates have moved to the Historical list. Check vendors’ plans for FIPS 140-3 replacements.
- When planning for post-quantum cryptography (PQC). New algorithms also need to appear in validated modules before some customers can use them.
Our governance, risk and compliance overview covers advisors who help map encryption requirements to your contracts.
Questions to ask vendors
- Which cryptographic modules does your product use, and what are their CMVP certificate numbers?
- Is the certificate FIPS 140-3, or FIPS 140-2 now on the Historical list, and what is your replacement plan?
- Does validation cover the exact version, firmware and operating environment we would run?
- Does the product need a special FIPS mode, and is it on by default in our deployment?
- What overall security level does the certificate show?
- For cloud services, which services, endpoints and regions use validated modules?
How it differs from FIPS 140-2
FIPS 140-2 was the previous version of the standard, first issued in 2001. FIPS 140-3 replaced it, aligning the requirements with ISO/IEC 19790 and its test methods with ISO/IEC 24759, and adding areas such as non-invasive security. The CMVP stopped accepting FIPS 140-2 submissions for new certificates on September 22, 2021, and FIPS 140-2 validated modules were accepted through September 21, 2026 before moving to the Historical list. Both use four security levels, but a FIPS 140-2 certificate is not a FIPS 140-3 certificate. For buyers, the practical question is whether a vendor’s modules hold current FIPS 140-3 validation for the version you will run, especially for FedRAMP and other federal work under FISMA.
Problems this helps with
- A government customer requires FIPS-validated encryption
- Vendor says its product is "FIPS compliant" and we can't tell what that means
- Our FIPS 140-2 certificates are moving to the historical list
- Choosing an HSM or key management service for regulated data
