FIPS 140-2 Sunset Sep 2026: Navigating the Shift to FIPS 140-3

The shift from the FIPS 140-2 standard is significant for organizations making use of HSMs, software-based cryptographic modules, VPN equipment, secure communications, and other items depending on validated crypto.

As of September 21, 2026, FIPS 140-2 validation will remain active on the CMVP list. Starting September 22, 2026, the remaining FIPS 140-2 validations will move to the Historical list, and FIPS 140-3 validations will become active.

That being said, it does not mean that the existing FIPS 140-2 modules will start malfunctioning or will become insecure. The transition has implications for how businesses will be appraising validated crypto devices, especially when purchasing or employing them in the new systems.

What Does FIPS 140-2 End of Life Mean?

“FIPS 140-2 end of life” refers to the transition that occurs in September 2026, but does not signify the end of FIPS 140-2 technology.

The key aspect is the CMVP validation status.

FIPS 140-2 modules will remain on the list of “CMVP Active” until September 21, 2026, and starting from September 22, 2026, the validation status is going to change to “Historical”. NIST made a specific note concerning the importance of the “Historical” status compared to the “revoked” status, as the former indicates that the validation has been granted and the latter means that the information cannot be qualified as valid.

Why the FIPS 140-2 Sunset Date Matters Now

The main problem is waiting until a new project has gone through procurement or qualification to deal with FIPS issues. If the design calls for a FIPS 140-2 module that is already in Historical status when the company takes ownership of the system, it may be necessary to find a FIPS 140-3 alternative and redo the necessary work for compliance.

Companies with initiatives that will kick off in late 2026 or later should be reviewing their lists of approved vendors, bills of materials, product specifications, and replacement strategies now. Starting now allows for more time to match interfaces, capabilities, and environmental specifications and avoid having the validation status become an urgent sourcing problem.

What Happens to a FIPS 140-2 Module After It Becomes Historical?

As soon as a FIPS 140-2 validation is moved to the Historical list, its status in the CMVP database gets altered. However, this doesn’t imply that the following has happened:

The HSM stops working.
Available encryption keys go void automatically.
Available certificates expire right away.
Algorithms like AES become less secure all of a sudden.
The organization has to detach the module.

Instead, it is the responsibility of the organization to check the possibility of using the module based on specific requirements applicable to this system.

When the existing module is already used, the entity has a right to continue the module operation but consider planning its move to the corresponding FIPS 140-3 validated option whenever needed.

FIPS 140-2 Transition Guidance by Deployment Type

The consequences of the FIPS 140-2 transition depend on whether the module is applied in a new, existing, or replacement system. The table below explains what organizations need to check according to each possible case.

Deployment Situation	What to Review
New system after September 21, 2026	It is strictly prohibited to incorporate Historical FIPS 140-2 modules into new systems. Where FIPS is required, applicable Active FIPS 140-3 validated modules should be utilized.
Existing system using FIPS 140-2	Certain agency, program, and contract requirements may permit organizations to use Historical FIPS 140-2 modules in their existing systems.
Replacement component for an existing system	Make sure that applicable classification regimes classify the acquisition as maintenance of existing implementations.
Product containing a validated module	Make sure the appropriate requirements concern the whole product or the encryption module inside it.
Encrypted but non-validated product	Encryption and the use of an accepted algorithm are insufficient to achieve compliance with FIPS 140-2 or FIPS 140-3.

Difference Between FIPS 140-2 and FIPS 140-3

FIPS 140-3 replaces FIPS 140-2 with updated cryptographic module requirements and testing. The table below highlights the key differences between the two standards.

Aspect	FIPS 140-2	FIPS 140-3
Status	Superseded by FIPS 140-3	Current successor to FIPS 140-2
Published	2001	2019
Effective Date	May 25, 2002	September 22, 2019
Validation Program	Cryptographic Module Validation Program (CMVP)	Cryptographic Module Validation Program (CMVP)
Primary Standard Basis	FIPS 140-2 requirements	Based on ISO/IEC 19790 with testing aligned to ISO/IEC 24759
Security Levels	Four security levels: 1–4	Four security levels: 1–4
Cryptographic Module Requirements	Defines security requirements for cryptographic modules	Updates and modernizes requirements for cryptographic modules
Physical Security	Requirements for physical protection based on the module’s security level	Updated physical-security requirements aligned with the newer framework
Non-Invasive Attack Mitigation	More limited requirements	Provides updated requirements for mitigation of non-invasive attacks, including applicable side-channel protections
Entropy Requirements	Entropy requirements were less comprehensive	Places greater emphasis on entropy sources and their documentation and validation
Software/Firmware Security	Defines requirements for software and firmware components	Updates software and firmware security requirements and testing
Sensitive Security Parameters	Defines requirements for management and protection	Provides updated requirements for sensitive security parameter management
Testing Requirements	FIPS 140-2 testing framework	Testing requirements are aligned with ISO/IEC 24759
International Alignment	Primarily U.S. federal standard	Greater alignment with international cryptographic-module standards
Current CMVP Status	FIPS 140-2 validations moved to the Historical list beginning September 22, 2026	Applicable FIPS 140-3 validations remain on the CMVP Active list
New Federal Procurements	Historical modules should not be included where the applicable requirements require an active validation	Active FIPS 140-3 validation can be used where FIPS validation is required
Existing Deployments	Historical modules may continue to be used depending on applicable requirements	Active validation provides the current validation path
Impact on HSMs	Existing FIPS 140-2 HSMs may require migration planning	New HSM procurements can evaluate applicable Active FIPS 140-3 validated modules
Overall Direction	Legacy validation standard	Current validation framework for cryptographic modules

FIPS 140-2 to FIPS 140-3 Migration Checklist

Organizations can use the following checklist to prepare their cryptographic infrastructure:

Inventory all HSMs and cryptographic modules.
Record each CMVP certificate number.
Check whether each certificate is Active, Historical or Revoked.
Verify the exact validated module version.
Document the validated operating environment.
Identify systems using FIPS 140-2 modules.
Separate existing deployments from new projects.
Review agency, regulatory and contractual requirements.
Identify FIPS 140-3 replacement options.
Test application compatibility.
Plan cryptographic-key migration.
Update procurement requirements.
Document the migration roadmap.
Maintain evidence for audits and assessments.

Impact on Existing HSM Deployments

The transition does not automatically require every existing FIPS 140-2 HSM to be removed or replaced on September 22, 2026.

For existing systems, organizations should review:

The CMVP status of the HSM’s cryptographic module.
The exact module version and configuration.
The applicable agency or regulatory requirements.
Contractual requirements.
Internal security policies.
Whether the system is considered an existing deployment or a new system.
Whether the vendor provides a FIPS 140-3 validated replacement.

According to NIST recommendations, federal entities could still utilize FIPS 140-2 modules that fall under the historical category in existing systems. Thus, organizations should not act as if this transition will require them to “swap out every single HSM straight away“. On the contrary, this should be a part of a well-organized process of changing the cryptographic infrastructure.

Impact on New HSM Procurements

The situation differs for the case of a new acquisition.

When FIPS validation is necessary, it is far better to choose a valid FIPS 140-3 module than a module that has a status of historical FIPS 140-2 validation.

For instance, organizations trying to implement a new PKI system should not consider an HSM only because “it has a FIPS 140-2 certification” written in its product description.

The Procurement Team should verify:

CMVP certificate number
FIPS version
Validation status
Module version
Approved operating environment
Security level
Validated algorithms
Validated configurations
Vendor lifecycle/support status

A product may have multiple models or firmware versions, and not every version is necessarily covered by the same validation.

HSM Migration: What Organizations Should Check

Organizations with existing HSM infrastructure should begin with an inventory.

Identify Every Cryptographic Module

Organizations are advised to start by compiling a full inventory of their hardware security modules (HSMs) and other crypto modules that are present throughout their system.

The inventory should comprise not only hardware HSMs but also software crypto modules, cloud crypto services that are used, and modules that have been embedded into security appliances or software.

For each of the modules, the information that should be recorded includes product name, product manufacturer, product model, version of software or firmware, CMVP certificate number, FIPS version, level of security, installation location, operating environment, and name of the owner.

Having a detailed inventory helps organizations identify whether they still use FIPS 140-2 modules or whether any of the modules have a valid FIPS 140-3 approval.

Check the CMVP Certificate

Having compiled the inventory, the organization must authenticate each cryptographic module with the NIST Cryptographic Module Validation Program (CMVP). Never depend simply on any vendor’s assertion that a product is “FIPS certified”

The organization must validate the exact certificate number, status of the validity, version of the module, configuration validated, operating environment, and the security level that is applicable. By doing so, it can establish the status of the module as being Active, Historical, or Revoked, with verification of this version’s correspondence with that covered by the certificate.

Separate Existing and New Deployments

Organizations must differentiate between cryptographic modules that have been used in existing systems and those that will be used in the future. A Historical FIPS 140-2 module can continue to be put to use in the existing system, depending on whether the pertinent agency or relevant contract, regulation, or program permits it.

In any new system for which FIPS validation is required, organizations ought to investigate an Active FIPS 140-3 validated option rather than continue using a Historical FIPS 140-2 module.

Identify FIPS 140-3 Alternatives

For each FIPS 140-2 module that has finally been classified as having “Historical” status, organizations should look for an appropriate FIPS 140-3 substitute.

The alternative does not just have to be picked according to the FIPS validation status.

Organizations should also look for differences in security level, algorithms provided, interfaces, cryptographic performance, key capacity, firmware specifications, availability features, cloud integration, and support for device lifecycle.

Plan Key Migration

When it comes to substituting an HSM, an appropriate strategy is vital in relation to the cryptographic keys that are processed or protected by the HSM.

Various issues related to key generation, storage, recovery, rotation, migration, encapsulation, and destruction should be resolved in a transition plan.

The transition plan should also define entities and applications dependent on specific keys, such as certificate authorities, TLS infrastructure, code-signing systems, databases, payment systems, and other cryptographic usage. Key transitions should be performed with due diligence to ensure the absence of any interruptions and critical loss.

Review the Operating Environment

It is essential to check whether the HSM or cryptographic element runs in the mode specified in its CMVP certificate. The verified module may have its own demands in terms of the firmware version, software version, operating systems used, hardware installations, and mode regulations.

Updating the firmware or changing the environment can lead to the fact that the solution does not match the validated mode any longer. Thus, teams need to get acquainted with the requirements stated in the certificate relative to its security policy and configuration before they make any serious changes in the infrastructure.

Evaluate Application Compatibility

Before transitioning to a new HSM, it is essential for businesses to determine if their applications will be able to connect with the new system in question.

This means checking out the APIs, PKCS #11 API, vendor SDKs, protocols used for key and certificate management, mechanisms to authenticate users, and configurations for providing high availability of services.

The process of testing compatibility should happen in a controlled environment prior to the organization migrating to production to ensure there are no unexpected downtimes in the usage of applications that rely on the older HSM device.

Review Compliance and Contractual Requirements

Organizations should examine relevant requirements to determine if there are any requirements that actually require them to use FIPS-validated cryptography.

These requirements may be stated in federal regulations, requirements established by contracts, requirements stated in regulatory compliance frameworks, customer agreements, or internal security policies.

It is not always the case that the validation of an organization’s FIPS 140-2 module has changed results in a requirement to replace the device. The actual need for the replacement will depend on the governing layer of requirements and the purpose of usage of the particular module.

Create a Migration Roadmap

Finally, organizations should create a documented migration roadmap for HSMs and other cryptographic modules that have moved to the Historical list.

The roadmap should identify the affected systems, module owners, replacement candidates, testing requirements, key-migration activities, target dates, dependencies, and rollback procedures.

A structured roadmap allows organizations to prioritize critical infrastructure and migrate in phases rather than treating the FIPS 140-2 transition as an immediate, organization-wide hardware replacement exercise.

What Should Organizations Do Now?

The FIPS 140-2 transition must be viewed as an ongoing procedure in terms of managing cryptographic infrastructure and not just as an event where some products are replaced after a day.

The first step for organizations is to manage their knowledge regarding what kind of cryptographic assets they have and which modules have been moved to the Historical list; moreover, it is important to define whether the given Historical module is part of an old system or it belongs to a new one.

In case of existing systems, the organization should study the regulatory and law-enforcement requirements and create a migration plan.

In the case with the new systems where the necessity for using FIPS modules is present, the organization should prioritize the purchase of those HSMs that are validated according to the FIPS 140-3 standard.

With regard to the HSM environment, the migration task should start much earlier than the HSM equipment fails. The task may be challenging because the organization must consider such factors as the migration process, compatibility of applications, availability of systems, backup process, and the process of disaster recovery.

Conclusion

FIPS 140-2 transition is considered to be a major development for companies using HSMs and other encryption modules. Even though already installed FIPS 140-2 may be used depending on the requirements, those companies planning to implement a new system should check the CMVP status and choose an appropriate active FIPS 140-3 validated solution.

Trusted Code Signing Certificates

Prevent Code Tampering and Authenticate Code Integrity by Digitally Sign your Code with Trusted Code Signing Certificates.

Get Code Signing Certificate

FIPS 140 2 End of Life: Impact on HSMs and Cryptographic Modules