FIPS 140-2 vs FIPS 140-3 is no longer a future-planning question. The transition is well underway, new FIPS 140-2 validations stopped being issued years ago, and any program citing FIPS in a requirement, a proposal, or an authorization package needs to know which standard applies, what a validation actually covers, and where its own modules stand.
The stakes are practical. FIPS validation is mandated for federal cryptography under FISMA, it reaches deep into the defense industrial base through CUI protection requirements, and it is one of the first things an assessor checks. It is also one of the most misunderstood labels in security, routinely treated as a general seal of approval when it is something far more specific.
This guide explains what FIPS 140-2 and 140-3 actually are, how the validation process works, where the transition stands, and, just as important, what a FIPS validation does not tell you about whether data on a device is protected.
FIPS 140-2 is a U.S. government standard, published by NIST, that defines security requirements for cryptographic modules, the combination of hardware, software, and firmware that implements encryption, key management, and related operations. The full requirements are set out in NIST’s Security Requirements for Cryptographic Modules.
The standard exists to answer a procurement problem: how does an agency know a vendor’s cryptography actually works as claimed? FIPS 140 answers it with independent testing. Accredited laboratories test modules against the standard, and NIST’s Cryptographic Module Validation Program (CMVP) reviews the results and issues a numbered validation certificate. Federal buyers can then check a public database instead of taking a datasheet’s word for it.
FIPS 140-3 is the successor standard, published in March 2019, which aligns U.S. requirements with the international ISO/IEC 19790 standard, as summarized in the Cloud Security Alliance’s overview of FIPS 140 compliance. The structure federal buyers know, four security levels, accredited-lab testing, CMVP validation, carries over; the underlying requirements and documentation model are updated.
The transition timeline is the part that trips people up:
The practical rule for anyone writing requirements today: specify FIPS 140-3 validation, or 140-2 with a status check, and verify the specific module and version on the CMVP database rather than accepting “FIPS compliant” on a datasheet. Compliant, in vendor language, sometimes means “uses approved algorithms” without any validation at all; validated means a certificate number exists.
Both standards define four ascending security levels, matched to data sensitivity and operating environment.
Level 1 requires at least one validated cryptographic algorithm and no exploitable known vulnerabilities in the module, with no physical security requirements. Software encryption modules commonly validate here.
Level 2 adds role-based authentication and tamper-evidence: seals or mechanisms that show when a module has been physically opened.
Level 3 moves from tamper-evidence to tamper-resistance, adds identity-based authentication, and requires that critical security parameters be zeroized if the module’s protection is breached.
Level 4 requires a complete protective envelope that detects and responds to any physical intrusion, including environmental attacks such as voltage or temperature manipulation, with immediate deletion of security parameters.
The level that matters is the one matched to the threat. A Level 1 software module and a Level 3 hardware module are both “FIPS validated,” and they are not interchangeable.
Validation runs through five stages, and the vocabulary matters: modules are validated, not certified, and precision on that point signals competence to a federal reviewer.
Two follow-on facts shape how validations should be read. Validation attaches to a specific module version, so a meaningful update can require revalidation, and the queue for testing and review runs long, which is why the module inside a shipping product is sometimes a version behind the vendor’s newest code. Both are reasons to check the database entry, not the marketing page.
Here is the misunderstanding that matters most, especially for anyone protecting data on devices that leave controlled spaces.
A FIPS validation covers the cryptographic module. It does not cover how the surrounding product uses it, and it does not require the product to demand authentication before that cryptography unlocks. A self-encrypting drive with a FIPS-validated module, and no enforced pre-boot authentication, decrypts transparently during normal startup: power it on and the validated encryption is simply bypassed. The cryptography passed its tests; the data is still exposed to anyone holding the device.
That is why FIPS status is the beginning of a storage security evaluation, not the end. The questions that follow are whether authentication is enforced before boot, whether protection layers are independent, and, for classified data at rest, whether the architecture meets the NSA CSfC two-layer requirement, an encrypted drive with pre-boot authentication plus independent software full drive encryption, as covered in why classified data at rest requires a CSfC architecture and in FIPS Is Not CSfC, which takes this argument through the defense leader’s lens.
Federal agencies: FISMA, enacted in December 2002 and modernized by the Federal Information Security Modernization Act of 2014, requires agencies to protect federal information with validated cryptography. If an agency system encrypts sensitive data, the module doing it is expected to be FIPS validated.
Defense contractors and the industrial base: CUI protection requirements under NIST SP 800-171, enforced through CMMC, extend FIPS-validated cryptography expectations to the contractors that handle controlled unclassified information, which is most of the defense supply chain.
Everyone selling into those markets: vendors whose modules are not validated are, in practical terms, not procurable for the covered use cases, which is why the CMVP database functions as a market gate as much as a security control.
Cigent builds secure storage and software encryption for exactly the environments where FIPS validation is table stakes and insufficient alone. Cigent products use FIPS-validated cryptographic modules [verify current module status and certificate references against the live CMVP listing at publication], enforce pre-boot and multifactor authentication so the validated cryptography cannot be bypassed at startup, and deliver both layers of the CSfC data-at-rest architecture, hardware encrypted storage plus independent software full drive encryption. Cigent components are listed on the NSA CSfC Components List, and Cigent solutions have been tested and validated by organizations including MITRE, NIST, NSA, and NIAP.
FIPS 140 is the federal government’s mechanism for knowing cryptography was independently tested, FISMA is what makes it mandatory, and FIPS 140-3 is where the program now lives, with 140-2 certificates on a published sunset path. Read validations precisely: module, version, level, current status, all checkable in the CMVP database.
Then ask the question the label cannot answer: what happens to the data when someone else powers on the device? For programs handling classified or sensitive mission data, the CSfC for DAR assessment maps your platform against the layered architecture that answers it.
FIPS 140-2 is a NIST standard defining security requirements for cryptographic modules, the hardware, software, and firmware combinations that perform encryption and key management. Modules are independently tested by accredited labs and validated through NIST’s Cryptographic Module Validation Program, which issues numbered certificates.
FIPS 140-3, published in March 2019, supersedes 140-2 and aligns U.S. requirements with the international ISO/IEC 19790 standard. The four-level structure remains, with updated requirements and documentation. CMVP stopped accepting new 140-2 submissions in September 2021, so all new validations are against 140-3.
Existing FIPS 140-2 certificates have remained usable, but they are on a sunset path, scheduled to move to the CMVP Historical List in September 2026. New acquisitions should specify FIPS 140-3 or verify a 140-2 module’s current status in the CMVP database before relying on it.
A cryptographic module is the specific combination of hardware, software, and firmware that implements cryptographic functions such as encryption, decryption, and key generation. FIPS validation applies to that module at a specific version, not to the entire product built around it.
FISMA, enacted in 2002 and modernized in 2014, requires federal agencies to protect information systems, which in practice means using FIPS-validated cryptographic modules wherever cryptography protects federal data. Agencies inherit the requirement directly; contractors inherit it through CUI rules.
Level 1 requires validated algorithms with no physical security mandates. Level 2 adds role-based authentication and tamper-evidence. Level 3 requires tamper-resistance, identity-based authentication, and zeroization of secrets on breach. Level 4 requires full physical protection with automatic deletion on any detected intrusion.
The Cryptographic Module Validation Program is the NIST-run program that accredits testing laboratories, reviews their results, and issues FIPS validations. Its public database is the authoritative record: a module either has a current certificate entry there or it is not validated, whatever the datasheet says.
No. Validated means the module completed lab testing and holds a CMVP certificate. Compliant is vendor language that sometimes means only that approved algorithms were used, with no independent testing. Federal requirements are satisfied by validation, so always ask for the certificate number.
Not by itself. Validation covers the cryptography, not the unlock behavior. A validated self-encrypting drive without enforced pre-boot authentication decrypts on normal startup. Classified data at rest requires the NSA CSfC two-layer architecture: hardware encryption with PBA plus independent software full drive encryption.
Generally yes, wherever they handle controlled unclassified information. NIST SP 800-171 requirements, enforced through CMMC, expect FIPS-validated cryptography for protecting CUI, which extends the federal validation requirement across most of the defense industrial base.
Kelvin Quezada is a Product Marketing Manager at Cigent, where he leads strategy, positioning, and go-to-market efforts for the company’s Data-at-Rest protection solutions. With more than a decade of experience across cybersecurity deployments, product marketing, and technical enablement, he translates complex technical concepts into clear, mission-focused value for defense programs.
