FIPS 140-2 security requirements

Key takeaways

• FIPS 140-2 defines four security levels (Level 1 through Level 4) for validating the cryptographic hardware and software modules that protect sensitive data.
• CMVP stopped accepting new FIPS 140-2 validation submissions in September 2021. FIPS 140-3 is now the only standard accepting new cryptographic module validations.
• All FIPS 140-2 certificates move to the CMVP Historical list on September 21, 2026, regardless of when each one was originally issued.
• Historical status does not instantly disable a deployed module, but most federal agencies and regulated buyers require a currently validated (not historical) module for new purchases and new system authorizations.
• Organizations should inventory every cryptographic module in use, confirm vendor FIPS 140-3 timelines, and prioritize systems tied to federal contracts, FedRAMP, CMMC, or PCI DSS before the deadline.

Published: March 2023. Updated: August 2026. Reviewed by Encryption Consulting’s compliance and cryptography team.

FIPS (Federal Information Processing Standard) 140-2 is a standard published by the National Institute of Standards and Technology (NIST) that sets security requirements for cryptographic modules, the hardware or software components that generate, store, and use cryptographic keys to encrypt or otherwise protect data. It was the baseline requirement for any cryptographic module used in U.S. federal systems for two decades. That is no longer the current state of the standard. NIST’s Cryptographic Module Validation Program (CMVP), the joint U.S. and Canadian program that tests and certifies cryptographic modules, has replaced FIPS 140-2 with FIPS 140-3 as the only standard accepting new validations, and it is retiring FIPS 140-2 certificates on a fixed timeline. This guide explains what FIPS 140-2 actually requires, exactly where it stands today relative to FIPS 140-3, and what enterprises still running FIPS 140-2 validated modules need to do before the transition completes.

What does FIPS 140-2 require? The four security levels

FIPS 140-2 requires that a cryptographic module meet a defined set of controls across cryptographic algorithms, key management, physical security, and operational security, tested against one of four increasing security levels. An organization picks the level that matches its risk profile and regulatory requirements, not the highest level by default, since higher levels also mean more cost and operational overhead.

1. Level 1

   Basic security. At minimum, a Level 1 module must use an approved algorithm, but it has no physical security mechanisms beyond production-grade components. This level fits low-cost software cryptographic modules and general-purpose computing hardware.

2. Level 2

   Adds tamper-evidence. A Level 2 module must show physical evidence of tampering (tamper-evident coatings, seals, or pick-resistant locks) and requires role-based authentication for operators. This is the common baseline for commercial hardware security modules (HSMs) and network appliances.

3. Level 3

   Adds tamper-detection and response. A Level 3 module must detect and respond to physical tampering attempts, typically by zeroizing (erasing) sensitive key material, and it requires identity-based authentication rather than shared roles. Most enterprise HSMs used for PKI, code signing, and cloud key management are validated at Level 3.

4. Level 4

   The highest level. A Level 4 module must provide a complete envelope of protection against physical and environmental attacks, including monitoring for voltage and temperature manipulation intended to defeat other security controls. This level is reserved for the most sensitive deployments, such as protecting classified information.

Within each level, FIPS 140-2 (and FIPS 140-3) also grades the module against a fixed set of requirement areas: cryptographic module specification, approved algorithms, physical security, operational environment, key management, electromagnetic interference and compatibility (EMI/EMC), self-tests, and mitigation of known attacks. A module’s certificate lists which level it achieved in each area, so two modules with the same overall level can still differ in specific requirement areas.

Is FIPS 140-2 still valid? The FIPS 140-2 to FIPS 140-3 transition timeline

Partially, and for a shrinking window. FIPS 140-2 modules validated before the cutoff dates below remain listed as valid until they move to Historical status, but CMVP has not accepted a new FIPS 140-2 submission in years and has set a fixed date after which every remaining FIPS 140-2 certificate becomes historical. Here is the primary-source timeline, drawn from NIST’s own CMVP transition documentation:

Date	Milestone
May 25, 2001	FIPS 140-2 is originally published by NIST, replacing FIPS 140-1.
March 22, 2019	NIST approves and issues FIPS 140-3, effective September 22, 2019.
September 22, 2021	CMVP stops accepting new FIPS 140-2 validation submissions, with a limited exception for vendors already under contract with a testing lab before June 15, 2021.
April 1, 2022	CMVP closes the remaining exception window; no new FIPS 140-2 submissions are accepted from this date forward.
September 21, 2026	Every FIPS 140-2 validation certificate still active moves to the CMVP Historical list, five years after validation or on this date, whichever is later.

Table 1: FIPS 140-2 to FIPS 140-3 transition timeline (source: NIST CSRC, FIPS 140-3 Transition Effort)

As of this update, the September 21, 2026 deadline is weeks away. FIPS 140-3 is the current, active standard for all new cryptographic module validations. FIPS 140-2 is not withdrawn overnight and existing certificates do not vanish, but “Historical” is a distinct CMVP status from “Active,” and buyers who specifically require an actively validated module, which includes most federal procurement and many regulated industries, will not accept a historical certificate for a new purchase.

What technologies and systems does this affect?

Anything built on a FIPS 140-2 validated cryptographic module is in scope. That is a wider list than most teams expect, because FIPS 140 validation applies to the module, not the finished product it ships inside.

• Hardware security modules (HSMs) used for PKI root and issuing CA key protection, code signing, database and application encryption, and key ceremonies.
• Cloud HSM and key management services, including AWS CloudHSM, Azure Key Vault Managed HSM, and Google Cloud HSM, each backed by a specific validated module and firmware version.
• Software cryptographic libraries, such as OpenSSL FIPS modules and platform crypto providers embedded in operating systems and applications.
• Network and security appliances, including VPN gateways, TLS-terminating load balancers, and firewalls that perform cryptographic operations in a dedicated module.
• Smart cards and authentication tokens used for PIV/CAC credentials and hardware-backed multi-factor authentication.
• Disk and storage encryption appliances validated for data-at-rest protection in regulated environments.

Regulatory frameworks that reference FIPS 140 by name, including FedRAMP, CMMC, HIPAA Security Rule guidance, PCI DSS, and several state and international government procurement standards, are the areas most directly affected, since they typically require an actively validated module rather than any module that was ever validated.

What is the impact for organizations still referencing FIPS 140-2?

The impact splits cleanly into two categories: systems already in production and new procurement.

Systems already in production. A FIPS 140-2 validated module that moves to Historical status does not stop functioning and does not automatically fail an existing authority to operate (ATO). CMVP explicitly continues to support historical modules for use in already-deployed systems. The risk is indirect: audit findings, contract renewal language, and new ATO reviews increasingly ask whether a module is “currently validated,” and a historical certificate does not satisfy that language even though the hardware still works.

New procurement. This is where the deadline bites immediately. Federal agencies, defense contractors under CMMC, and many regulated buyers write “FIPS 140-2 or FIPS 140-3 validated” into RFPs out of habit, but a growing share now require FIPS 140-3 specifically, or “currently validated” status, for any new purchase after September 21, 2026. Buying a module today that is only FIPS 140-2 validated means buying a certificate that goes historical within the warranty period of the hardware.

How do you check if a module is FIPS 140-2 Historical or FIPS 140-3 Active?

Check the module’s certificate status directly on NIST’s own record rather than trusting a vendor data sheet, since data sheets are not always updated the day a certificate changes status.

1. Locate the FIPS validation certificate number for each cryptographic module in your inventory (check the vendor’s compliance documentation, the device’s admin console, or the purchase order).
2. Search that certificate number in the CMVP Validated Modules Search on csrc.nist.gov.
3. Read the “Status” field on the certificate record: it will show Active, Historical, or Revoked.
4. Confirm the exact hardware and firmware version in production matches the version listed on the certificate; a firmware update can invalidate the FIPS validation if it was not covered by the certificate.
5. For modules from cloud providers, check the provider’s published FIPS compliance documentation for the specific service and region, since validation status can vary by deployment.
6. Review current vendor contracts and support agreements for any clause referencing “FIPS 140-2 validated” or “FIPS 140-3 validated” and flag mismatches for renewal.

FIPS 140-2 to FIPS 140-3 remediation and migration checklist

Use this sequence to move from an unmanaged FIPS 140-2 footprint to a documented FIPS 140-3 migration plan.

1. Inventory every cryptographic module in production, including HSMs, cloud key management services, software crypto libraries, and network appliances, and record each module’s FIPS certificate number.
2. Check each certificate’s status against the CMVP Validated Modules Search and tag every module as Active, Historical, or Revoked.
3. Prioritize by exposure: rank systems tied to federal contracts, FedRAMP authorizations, CMMC assessments, or PCI DSS scope above internal-only systems.
4. Contact each vendor for its FIPS 140-3 validated replacement hardware or firmware, and get a documented delivery timeline in writing rather than a verbal roadmap.
5. Update procurement and contract language to require “FIPS 140-3 validated” (not just “FIPS 140 validated”) for every new cryptographic module purchase going forward.
6. Plan hardware and firmware refresh cycles around the September 21, 2026 historical-status date rather than around the hardware’s own end-of-life schedule, since the two rarely line up.
7. Confirm crypto-agility in your applications: verify nothing is hardcoded to a specific module identifier, PKCS#11 slot configuration, or certificate number that would break during a module swap.
8. Document the migration plan and current status for auditors, and update your compliance evidence package to reflect actual certificate status rather than an assumption that FIPS 140-2 is still current.

FIPS 140-2 vs. FIPS 140-3: what’s different

Aspect	FIPS 140-2	FIPS 140-3
Current validation status	Withdrawn for new submissions; certificates move fully to Historical on September 21, 2026	Active; the only standard CMVP accepts new module submissions against
Published / effective	May 25, 2001	Approved March 22, 2019; effective September 22, 2019
Security levels	4 levels (Level 1 to Level 4)	4 levels (Level 1 to Level 4), same numbering, with tightened requirements at each level
International alignment	U.S.-specific requirements	Aligned with ISO/IEC 19790:2012 and ISO/IEC 24759 test methods
Non-invasive attack testing	Not addressed	Added as a testable requirement at higher security levels
Software and firmware module criteria	Original 2001-era criteria	Updated to reflect modern software and firmware module design
Accepting new submissions	No, stopped September 2021	Yes

Table 2: FIPS 140-2 vs. FIPS 140-3 comparison

Limitations

This guide covers the general FIPS 140-2 requirements and the CMVP transition timeline; it does not replace a legal or compliance review of your specific contractual, federal, or industry obligations, which vary by agency and by contract. Historical-status handling also varies: some federal agencies grant limited exceptions or extended use periods for historical modules already deployed in an authorized system, while others do not. Consult your agency’s authorizing official or your Compliance Advisory partner before assuming a historical certificate is acceptable for your specific authorization. This guide also does not cover the Implementation Guidance (IG) documents CMVP publishes for FIPS 140-3, which detail edge cases in testing and are updated more frequently than the standard itself.

What would Encryption Consulting recommend?

Do not wait for an audit finding to discover a module has gone historical. Run the inventory step first, even before contacting vendors, because most organizations underestimate how many systems quietly depend on a single FIPS-validated module for key storage or TLS termination.

For organizations that need to move off aging, FIPS 140-2 validated hardware without a multi-year infrastructure project, HSM-as-a-Service gives you FIPS 140-3 validated key protection on a managed, cloud-delivered model, so the validation status of the underlying hardware is the vendor’s responsibility to maintain, not yours to track certificate by certificate. For the compliance side of the transition, our Compliance Advisory team can run the module inventory, map it against your specific regulatory obligations (FedRAMP, CMMC, PCI DSS, and similar frameworks), and build the remediation roadmap alongside your team. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified, and our advisory work is built around named, repeatable methodologies rather than a generic audit checklist.

If you want the deeper technical breakdown of what changes on the hardware and firmware side of the migration, read our companion piece, Transitioning to FIPS 140-3: Timeline and Changes. For a side-by-side comparison built specifically around the transition deadline, see FIPS 140-2 vs FIPS 140-3: Differences and Transition Deadline in our Education Center. If your HSM strategy itself needs a wider review, our Enterprise Guide to HSM-as-a-Service covers how to evaluate managed HSM options beyond FIPS validation alone.

Conclusion

FIPS 140-2 built the four-level framework that still shapes how organizations evaluate cryptographic modules today, but it is no longer the standard NIST is validating new modules against, and its remaining certificates have a fixed expiration into historical status on September 21, 2026. That does not mean every FIPS 140-2 validated system needs to be replaced this quarter. It does mean every organization that has ever cited FIPS 140-2 in a compliance document, an RFP, or an ATO package needs a current answer to a simple question: is the module we are relying on actively validated, or historical? Get that inventory done now, while there is still runway to plan the FIPS 140-3 migration on your own schedule instead of an auditor’s.

Frequently asked questions

Is FIPS 140-2 still valid? Partially, and only until September 21, 2026. Existing FIPS 140-2 certificates continue to appear on the CMVP list, but CMVP stopped accepting new FIPS 140-2 submissions in September 2021, and every remaining certificate moves to Historical status on that date. A historical certificate is not the same as an active one for procurement purposes, even though the underlying hardware keeps functioning.

What’s the difference between FIPS 140-2 and FIPS 140-3? Both define four security levels for cryptographic modules using the same Level 1 through Level 4 structure, but FIPS 140-3 aligns with the international ISO/IEC 19790:2012 standard, adds non-invasive attack testing requirements, and updates the criteria for modern software and firmware modules. FIPS 140-3 is the only standard currently accepting new validations.

What happens to my systems when a FIPS 140-2 certificate goes historical? The module itself does not stop working, and CMVP continues to support historical modules for use in already-authorized systems. The practical impact shows up in audits, contract renewals, and new authorization reviews that specifically require a currently validated module rather than any module that was once validated.

Do I need FIPS 140-3 validated hardware right now? For any new purchase, yes, since FIPS 140-2 has not accepted new submissions since 2021 and buying FIPS 140-2 only hardware today means buying a certificate that goes historical almost immediately. For hardware already deployed and authorized under FIPS 140-2, you have a migration window, but it should be planned now rather than after the September 21, 2026 deadline.

What are the four FIPS 140-2 and FIPS 140-3 security levels? Level 1 requires an approved algorithm with no dedicated physical security. Level 2 adds tamper-evidence and role-based authentication. Level 3 adds tamper-detection and response with identity-based authentication, the level most enterprise HSMs target. Level 4 adds a complete envelope of protection against physical and environmental attacks, reserved for the most sensitive deployments.

References

• NIST, FIPS 140-2, Security Requirements for Cryptographic Modules (Withdrawn)
• NIST, FIPS 140-3, Security Requirements for Cryptographic Modules
• NIST CSRC, FIPS 140-3 Transition Effort
• NIST CSRC, Cryptographic Module Validation Program (CMVP)