FIPS 140-2 and 140-3: Federal Encryption Validation Standards

FIPS 140-2 and FIPS 140-3 are the two active U.S. federal standards governing the validation of cryptographic modules used in government and regulated-industry systems. Issued by the National Institute of Standards and Technology (NIST) under the authority of the Federal Information Security Modernization Act (FISMA), these standards define a four-level security hierarchy that shapes procurement decisions, vendor certification pathways, and compliance mandates across federal agencies, defense contractors, healthcare organizations, and financial institutions. Understanding where each standard applies, how they differ, and what the validation process entails is essential for procurement officers, security engineers, and compliance professionals operating under federal or federally-adjacent requirements.

• Definition and Scope
• Core Mechanics or Structure
• Causal Relationships or Drivers
• Classification Boundaries
• Tradeoffs and Tensions
• Common Misconceptions
• Checklist or Steps
• Reference Table or Matrix

Definition and Scope

FIPS 140, in both its second and third revision, defines security requirements for cryptographic modules — hardware, software, or firmware components that implement approved cryptographic functions. The standard is formally published by NIST under the Federal Information Processing Standards program, and validated modules are listed in the Cryptographic Module Validation Program (CMVP), a joint initiative operated by NIST and the Canadian Centre for Cyber Security (CCCS).

FIPS 140-2, published in May 2001 (FIPS PUB 140-2), governed cryptographic module validation for over two decades. FIPS 140-3, approved in March 2019 (FIPS PUB 140-3), supersedes it by incorporating ISO/IEC 19790:2012 and ISO/IEC 24759:2017 as its normative technical baseline. As of September 22, 2021, NIST stopped accepting new FIPS 140-2 validation submissions; existing FIPS 140-2 certificates remained valid through September 21, 2026, per NIST transition guidance.

Scope is defined by the module boundary — the physical or logical perimeter that encloses all hardware, software, and firmware components subject to security requirements. Modules outside federal procurement pipelines are not required to seek validation, but FIPS 140 compliance has become a de facto requirement in regulated sectors beyond the federal government, including HIPAA-governed environments and PCI DSS-governed payment systems.

Core Mechanics or Structure

Both standards organize security requirements into eleven functional areas:

1. Cryptographic module specification
2. Cryptographic module ports and interfaces
3. Roles, services, and authentication
4. Finite state model
5. Physical security
6. Operational environment
7. Cryptographic key management
8. Electromagnetic interference/electromagnetic compatibility (EMI/EMC)
9. Self-tests
10. Design assurance
11. Mitigation of other attacks

These eleven areas are evaluated across four ascending security levels (Level 1 through Level 4). Each level adds requirements on top of the prior level rather than replacing them.

Level 1 requires that the module implement at least one approved security function and use approved algorithms, with no specific physical security mechanisms beyond basic production-grade enclosures.

Level 2 adds requirements for tamper-evidence — coatings, seals, or pick-resistant locks — and role-based authentication. Common Criteria (CC) Evaluation Assurance Level 2 (EAL2) is required for software components at this level under FIPS 140-3.

Level 3 mandates tamper-detection and tamper-response mechanisms that zeroize critical security parameters (CSPs) when physical intrusion is detected. Identity-based authentication replaces role-based authentication, and plaintext CSPs must not traverse any interface.

Level 4 is the highest tier, requiring complete physical protection envelopes that detect penetration from any direction and delete all CSPs on detection. This level is appropriate for unprotected physical deployment environments and is rarely pursued in commercial products.

Testing is conducted by accredited Cryptographic and Security Testing (CST) laboratories, not by NIST directly. The laboratory submits a validation report to the CMVP, which then issues the certificate. The NIST CMVP validated modules list contains over 4,000 active and historical certificates as of 2024.

Encryption key management practices are directly implicated in the key management requirements under Area 8 of both standards, making validated key storage and lifecycle controls a central technical concern in module design.

Causal Relationships or Drivers

The legislative driver for FIPS 140 compliance is the Federal Information Security Modernization Act of 2014 (FISMA 2014, 44 U.S.C. § 3554), which requires federal agencies to implement information security programs that include the use of NIST-approved cryptographic standards. Office of Management and Budget (OMB) Circular A-130 further directs agencies to use FIPS-validated modules for protecting sensitive federal information.

The shift from FIPS 140-2 to FIPS 140-3 was driven primarily by the need to align U.S. federal standards with international cryptographic frameworks. By adopting ISO/IEC 19790 as its normative base, FIPS 140-3 harmonizes U.S. federal validation with the requirements recognized across NATO partners and allied governments that independently reference ISO/IEC 19790.

A secondary driver is the advancing threat landscape around post-quantum cryptography. While neither FIPS 140-2 nor FIPS 140-3 mandates post-quantum algorithms directly, FIPS 140-3's modular structure is designed to accommodate NIST's post-quantum cryptography standardization outputs — including FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), finalized by NIST in August 2024 — without requiring another wholesale revision of the module validation framework.

Defense procurement adds a parallel driver: the Department of Defense (DoD) mandates FIPS 140-2 or 140-3 validated cryptography in systems handling Controlled Unclassified Information (CUI) and classified data under Committee on National Security Systems Policy (CNSSP) No. 15 and related directives.

Classification Boundaries

The FIPS 140 framework draws three primary classification boundaries that determine applicability and validation pathway:

Module type boundary: A module may be classified as a hardware module, software module, firmware module, or hybrid. Hardware modules with physical boundaries must satisfy physical security requirements in all four levels. Software modules operating on a general-purpose operating system (GPOS) cannot achieve Level 3 or Level 4 because they cannot satisfy the physical tamper-response requirements without hardware support.

Operational environment boundary: For software and firmware modules, the operational environment (OE) is a critical classification axis. Modifiable OEs — such as standard commercial operating systems — require an approved operating system and introduce constraints on the algorithms that can be approved in that context. Non-modifiable OEs are typically embedded firmware running on a fixed platform.

Algorithm approval boundary: The validated module must use only NIST-approved cryptographic algorithms listed in the NIST Approved Security Functions Annex for FIPS 140-3. An AES implementation must use an approved mode of operation (CBC, GCM, CCM, etc.); non-approved modes disqualify that function from counting toward the validated boundary. Similarly, RSA and elliptic curve implementations must conform to specific key size minimums — RSA at a minimum 2048-bit modulus, EC at minimum 224-bit curves per NIST SP 800-131A Rev 2.

Tradeoffs and Tensions

Validation lag vs. security currency: The CMVP validation process historically takes 12 to 24 months from submission to certificate issuance, depending on laboratory queue depth and finding resolution cycles. This lag means a validated module may ship with a cryptographic implementation that is 2 to 3 years behind the current NIST approved algorithm list at the time of deployment. Vendors face pressure to ship validated products but cannot rapidly update algorithms without re-entering the validation queue.

Scope of validation vs. scope of deployment: A FIPS 140 certificate covers a specific module boundary at a specific version. Updating the operating system, patching the firmware, or changing a hardware component can invalidate the certificate or move the deployment outside the validated configuration. Security teams must decide whether to maintain exact validated configurations — potentially delaying security patches — or operate in non-validated configurations while pursuing re-validation.

FIPS 140-2 sunset pressure: Federal agencies and vendors face a hard deadline of September 21, 2026, after which FIPS 140-2 certificates transition to "historical" status per NIST guidance (CMVP Transition Announcement). Products carrying only FIPS 140-2 certificates will technically no longer satisfy federal procurement requirements after that date, creating a forced migration cycle that intersects with hardware refresh timelines.

Software module limitations: Software-only FIPS 140-3 validation is capped at Level 2 because Level 3 mandates physical tamper-response. Organizations requiring higher assurance for software-driven hardware security modules must deploy purpose-built hardware platforms.

Common Misconceptions

Misconception: FIPS 140 validates the security of the entire product. The standard validates a cryptographic module, not the security posture of any application or system using that module. A product integrating a FIPS 140-3 Level 2 validated module can still be insecure if the surrounding application misuses the cryptographic functions, improperly manages keys, or exposes plaintext through application-layer vulnerabilities.

Misconception: Using FIPS-approved algorithms is equivalent to FIPS 140 validation. Implementing AES-256 or SHA-384 does not constitute FIPS 140 compliance. Validation requires that the specific implementation of those algorithms — in the specific module boundary — be tested by an accredited CST laboratory and certified through the CMVP. Algorithm approval and module validation are distinct processes.

Misconception: FIPS 140-3 replaced all FIPS 140-2 certificates immediately. NIST established a phased transition with a defined sunset window. FIPS 140-2 certificates issued before September 22, 2021 remain valid through September 21, 2026, per NIST's transition schedule.

Misconception: Level 4 is the standard target for federal agencies. The overwhelming majority of CMVP-listed certificates are at Level 1 or Level 2. Level 3 applies to purpose-built hardware devices like HSMs and smartcard platforms. Level 4 certifications are rare globally and are typically confined to specialized cryptographic hardware for defense and intelligence applications.

Misconception: FIPS 140 covers export controls. Cryptographic export is governed separately by the Export Administration Regulations (EAR) administered by the Bureau of Industry and Security (BIS), as detailed under U.S. Export Controls on Encryption. FIPS validation has no bearing on export license requirements.

Checklist or Steps

The following sequence describes the FIPS 140-3 validation process as structured by NIST and CMVP procedures:

1. Define the cryptographic module boundary — Identify all hardware, software, and firmware components that will be included within the module perimeter subject to validation.
2. Select the target security level — Determine the intended Security Level (1–4) based on deployment environment and physical security requirements.
3. Identify applicable approved algorithms — Cross-reference all cryptographic functions against the NIST Approved Security Functions list for FIPS 140-3, including algorithm self-tests and known-answer tests (KATs).
4. Engage an accredited CST laboratory — Select a laboratory from the NIST-accredited CST laboratory list (NVLAP-accredited labs) and initiate pre-validation coordination.
5. Prepare the Security Policy document — Draft the non-proprietary Security Policy that will be published with the certificate, documenting module design, roles, services, and approved modes of operation.
6. Conduct algorithm validation (ACVTS) — Submit algorithm implementations to the Automated Cryptographic Validation Testing System (ACVTS) to obtain algorithm validation certificates, which are prerequisite to module validation.
7. Complete laboratory testing — The CST laboratory performs all required tests across the eleven functional areas and documents findings in a Validation Test Report (VTR).
8. Submit to CMVP for review — The laboratory submits the VTR and accompanying documentation to NIST/CCCS. CMVP staff review for completeness and conformance.
9. Resolve findings — Address any issues identified during CMVP review; unresolved findings delay or block certificate issuance.
10. Receive and publish certificate — Upon approval, NIST issues the certificate number and publishes the module on the CMVP validated modules list, including the Security Policy document.

Reference Table or Matrix

References

• NIST FIPS PUB 140-2 (May 2001)
• NIST FIPS PUB 140-3 (March 2019)
• NIST Cryptographic Module Validation Program (CMVP)
• CMVP FIPS 140-3 Transition Effort
• NIST Automated Cryptographic Validation Testing System (ACVTS)
• [NIST SP 800-131A Rev 2 — Transitioning the Use of Cryptographic Algorithms and Key Lengths](