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. This page maps the definition, mechanics, classification structure, and validation process for both standards, serving as a reference 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, across both its second and third revisions, 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 catalogued in the Cryptographic Module Validation Program (CMVP), a joint initiative operated by NIST and the Canadian Centre for Cyber Security (CCCS).

FIPS PUB 140-2, published in May 2001, governed cryptographic module validation for over two decades. FIPS PUB 140-3, approved in March 2019, supersedes it by incorporating ISO/IEC 19790:2012 and ISO/IEC 24759:2017 as its normative technical baseline — a structural shift that aligns U.S. federal validation with international cryptographic standards. 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 published on the CMVP website.

Scope is defined by the module boundary — the physical or logical perimeter enclosing 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 procurement requirement in healthcare (under HIPAA), financial services (under federal banking regulations), and defense contracting (under DFARS clause 252.204-7012). The encryption providers on this provider network document vendor modules that have achieved CMVP certification across both standards.

Core Mechanics or Structure

The validation process under both FIPS 140-2 and FIPS 140-3 is administered through the CMVP, which designates accredited third-party testing laboratories — known as Cryptographic and Security Testing (CST) laboratories — to conduct module evaluations. As of 2024, NIST accredits CST laboratories through the National Voluntary Laboratory Accreditation Program (NVLAP), program code 201019-0, administered under NIST Handbook 150-17.

Both standards organize security requirements across 11 domains:

Under FIPS 140-3, requirements within each domain are assigned to one of four Security Levels, with Level 1 representing the baseline and Level 4 representing the most stringent physical and logical protections. Each Security Level builds cumulatively on the requirements of the level below it.

FIPS 140-3 introduces several structural changes absent from FIPS 140-2: the separation of software module requirements from hardware module requirements, expanded self-test requirements, and alignment with ISO/IEC 19790's terminology for operator authentication. The Approved Security Functions list — defining which algorithms a validated module may use — is maintained separately by NIST in SP 800-140C, one of five companion documents (SP 800-140A through 800-140F) that operationalize FIPS 140-3 requirements.

Causal Relationships or Drivers

The transition from FIPS 140-2 to FIPS 140-3 was driven by three converging pressures. First, FIPS 140-2's technical baseline had not been substantially revised since 2002 (Change Notice 2), leaving requirements that did not account for side-channel attacks, virtualized environments, or post-quantum algorithm considerations. Second, international harmonization pressures — particularly from allied governments in the Five Eyes intelligence-sharing arrangement — created demand for alignment with ISO/IEC 19790, which the United Kingdom, Canada, Australia, and Germany had already adopted or referenced in their own national frameworks. Third, FISMA and its implementing guidance under NIST SP 800-53 Rev 5 (control SC-13) requires that federal agencies use cryptographic protections validated under a FIPS-approved standard — a statutory driver that forces module vendors to maintain current validation status.

The mandatory CMVP provider requirement for federal procurement creates a commercial incentive structure: vendors selling to federal agencies, or to contractors handling Controlled Unclassified Information (CUI) under NARA's CUI Registry, must obtain and maintain certificates. This has produced a CMVP queue that historically runs 12 to 24 months for initial validation, a structural bottleneck documented in NIST's annual CMVP status reports.

Healthcare organizations subject to the HIPAA Security Rule are not explicitly required by statute to use FIPS 140-validated modules, but HHS guidance and OCR enforcement patterns treat FIPS validation as strong evidence of compliance with the encryption implementation specification at 45 CFR §164.312(a)(2)(iv). The provides additional context on how FIPS validation intersects with sector-specific compliance frameworks.

Classification Boundaries

The four Security Levels under both FIPS 140-2 and FIPS 140-3 define distinct physical and logical protection thresholds:

Security Level 1 requires only that the module use approved algorithms and that no obvious security vulnerabilities exist. No specific physical security mechanisms are mandated. Software-only modules and single-chip implementations operating in unprotected environments typically target Level 1.

Security Level 2 adds requirements for tamper-evidence — physical coatings, seals, or pick-resistant locks that show evidence of physical access — and role-based authentication. Operating system requirements become relevant at this level when the module runs on a general-purpose platform.

Security Level 3 requires tamper-detection and response mechanisms: circuitry that zeroes cryptographic keys when physical intrusion is detected. Identity-based authentication (as distinct from role-based) is required. Multi-chip embedded and multi-chip standalone module types are typical Level 3 deployment scenarios. Hardware Security Modules (HSMs) used in payment card processing networks commonly target Level 3.

Security Level 4 requires a complete physical protection envelope that detects and responds to all unauthorized physical access attempts, including penetration from any direction. Environmental failure protection — guarding against voltage and temperature attacks — is mandatory. Level 4 certificates are rare globally; the CMVP active certificate list typically shows fewer than 20 Level 4 certificates at any given time, concentrated in purpose-built defense and intelligence hardware.

Module type boundaries also affect classification. FIPS 140-3 formally recognizes hardware modules, software modules, firmware modules, and hybrid modules — distinctions that carry different security requirement sets, particularly for the operational environment domain.

Tradeoffs and Tensions

The CMVP validation cycle creates a documented tension between security currency and operational continuity. Because validation testing takes 12 to 24 months on average, module vendors must lock cryptographic implementations at the time of submission. A module validated under a specific algorithm configuration cannot be updated — even to patch a vulnerability — without initiating a new validation cycle or a NIST-approved change request. This means that operationally deployed modules may lag behind algorithm guidance, particularly as NIST's post-quantum cryptography standardization process produces new approved algorithms under FIPS 203, 204, and 205.

A second tension exists between breadth of approval and depth of assurance. Level 1 validation confirms algorithmic correctness but does not assess implementation security in the deployment environment. An agency deploying a Level 1-validated software module on an unsecured general-purpose operating system has met the letter of FIPS requirements but may have introduced attack surfaces that the validation did not examine.

The transition deadline between FIPS 140-2 and FIPS 140-3 also created a procurement gap: modules submitted under FIPS 140-2 before September 22, 2021 continued through the queue under the old standard, while new submissions required FIPS 140-3 compliance. Agencies purchasing modules during the 2022–2026 window must verify certificate dates and applicable standard to determine which requirements govern the module. The how to use this encryption resource page outlines how to navigate certificate lookups within this network's structure.

Common Misconceptions

Misconception: FIPS 140 validates the security of an entire product or system. Validation applies only to the defined cryptographic module boundary. A product containing a validated module may still have security vulnerabilities outside that boundary. The CMVP certificate describes the specific configuration tested — not the product as shipped.

Misconception: FIPS 140-2 and FIPS 140-3 certificates are interchangeable for all procurement purposes. Some agency-specific or program-specific requirements explicitly reference the standard version. Contracting officers and program security offices must verify that the certificate version meets the requirement as written in the solicitation or security plan.

Misconception: FIPS 140 validation is perpetual once granted. NIST places certificates on the Historical list when they reach the end of their validity window. FIPS 140-2 certificates issued before September 22, 2021, move to Historical status on September 21, 2026, per NIST's published transition schedule. Agencies relying on Historical certificates for active deployments must reassess compliance status.

Misconception: Level 4 is the standard target for federal agencies. The overwhelming majority of CMVP-verified certificates are at Level 1 or Level 2. Level 3 applies to purpose-built hardware devices such as 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 encryption export controls. Cryptographic export is governed separately by the Export Administration Regulations (EAR) administered by the Bureau of Industry and Security (BIS), under 15 CFR Part 742.15. FIPS validation status 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 procedural documents:

1. Define the cryptographic module boundary. Identify all hardware, software, and firmware components that will be included within the module perimeter subject to validation. Document all ports, interfaces, and physical enclosure details.

2. Select the target Security Level. Determine the intended Security Level (1–4) based on deployment environment, physical security requirements, and applicable procurement specifications.

3. Identify applicable approved algorithms. Cross-reference all cryptographic functions against the NIST Approved Security Functions list published in SP 800-140C. Any non-approved algorithm used within the module boundary must be explicitly excluded from security claims.

4. Prepare the Security Policy document. Draft the module's Security Policy — a required deliverable specifying roles, services, authentication mechanisms, and operational rules. The Security Policy becomes a public document upon certificate issuance.

5. Engage an accredited CST laboratory. Select a NVLAP-accredited Cryptographic and Security Testing laboratory from the NIST NVLAP provider network. The laboratory conducts formal testing against the Implementation Under Test (IUT).

6. Complete algorithm testing via ACVTS. All cryptographic algorithms must be validated independently through the Automated Cryptographic Validation Testing System (ACVTS), operated by NIST under the Cryptographic Algorithm Validation Program (CAVP). ACVTS certificates are prerequisites for CMVP submission.

7. Submit the validation package to CMVP. The CST laboratory submits the completed test report and documentation package to CMVP. NIST reviews for consistency and correctness before issuing the certificate.

8. Receive certificate and manage ongoing compliance. Upon approval, the module is verified on the CMVP active certificates page. Any modification to the module that falls outside the approved operational configuration requires a change request or new submission.

Reference Table or Matrix

FIPS 140-2 vs. FIPS 140-3: Key Structural Comparison

Security Level Requirements Summary