Transitioning to FIPS 140-3 – Timeline and Changes

Published: January 2021. Updated: August 2026. Reviewed by Encryption Consulting’s HSM Services team.

FIPS 140 (“Federal Information Processing Standard”) is the U.S. government’s security standard for cryptographic modules, the hardware, firmware, and software that generate keys, sign transactions, and encrypt data inside an HSM. FIPS 140-3 is the current version. It replaces FIPS 140-2, and the replacement is no longer a future event: it has a hard compliance deadline three weeks from today. This guide covers what FIPS 140-3 actually changed, the exact transition timeline, and the technical work involved in moving an HSM fleet, deployment topology, key ceremonies, high availability, and integration testing included, before FIPS 140-2 certificates go Historical.

Encryption Consulting also publishes a companion guide, FIPS 140-3: What Organizations Need to Know by Sept. 2026, which covers the compliance side of this transition in depth, including the FIPS Validated versus FIPS Compliant versus FIPS Capable distinction and the eleven security areas an assessment should cover. This article focuses on the HSM procurement and technical migration side: what changes on the hardware floor, not just on the compliance spreadsheet.

What Is FIPS 140-3, and How Does It Differ From FIPS 140-2?

FIPS 140-3 is the current NIST standard that defines the security requirements a cryptographic module must satisfy to be validated for use in U.S. federal systems and the many private-sector frameworks that reference it. It supersedes FIPS 140-2 and, for the first time, aligns U.S. federal cryptographic module requirements with the international standard ISO/IEC 19790:2012, with testing methodology aligned to ISO/IEC 24759:2017.

The differences are not cosmetic. Four changes matter most for HSM buyers and operators:

Area	FIPS 140-2	FIPS 140-3
Non-invasive security	Not addressed. Side-channel resistance was tested only informally, if at all.	A new, dedicated security area. Formal mitigation testing for power analysis, electromagnetic analysis, and timing analysis is required at Level 3 and above.
Software and firmware integrity	Accepted weaker error-detection checks.	From Level 2 upward, the module must verify its own code with an approved digital signature or HMAC-based test.
Algorithm support	Allowed Triple-DES, SHA-1 for signatures, RSA-1024, and MD5 in many contexts.	Disallows Triple-DES, SHA-1 for digital signatures, RSA-1024, and MD5 outright. TLS 1.0 and 1.1 are incompatible with the module’s approved configuration.
Module types	Written around hardware modules, with hybrid and software modules added later through interpretive guidance.	Formally defines hardware, firmware, software, hybrid-software, and hybrid-firmware modules, with no restriction on the security level a hybrid module can reach.

Two of these changes have direct operational consequences for an HSM fleet. Non-invasive security testing means an HSM vendor now has to demonstrate hardened resistance to physical side-channel attacks, not just logical ones, which is a meaningful hardware and firmware engineering bar. The software integrity requirement closes a real supply-chain gap: a compromised firmware update can silently change a module’s behavior without changing its external interface, and FIPS 140-3 requires the module to verify itself against exactly that scenario before it will run.

What Is the FIPS 140-3 Transition Timeline?

Three dates define this transition, and all three are confirmed against NIST’s Cryptographic Module Validation Program (CMVP) records.

Date	Milestone
September 22, 2019	FIPS 140-3 becomes the effective standard, published following approval by the Secretary of Commerce.
September 22, 2020	CMVP begins accepting FIPS 140-3 validation submissions.
April 1, 2022	CMVP stops accepting new FIPS 140-2 submissions for validation certificates. This was an extension from the original September 21, 2021 cutoff, granted to labs and vendors already under contract.
September 21, 2026	All remaining FIPS 140-2 certificates move to the CMVP Historical List. This date is three weeks from today.

The practical read: FIPS 140-3 has been the only standard CMVP validates new modules against for over four years. What changes on September 21, 2026 is not the validation process, that transition already happened, but the status of every certificate still sitting on FIPS 140-2. If your HSM fleet, your vendor’s roadmap, or your procurement specifications still reference FIPS 140-2 as an acceptable target, that reference expires on a fixed date, not a rolling one.

What Happens When a FIPS 140-2 Certificate Goes Historical?

Historical status is a change in the CMVP database, not a kill switch on the hardware. An HSM running a FIPS 140-2 validated module keeps encrypting, signing, and generating keys exactly as it did the day before. Nothing on the device stops working on September 21, 2026.

What stops working is the certificate’s standing as current proof of validated cryptography. A Historical certificate no longer satisfies federal procurement requirements for new systems, no longer supports FedRAMP Authorization to Operate on its own, no longer meets HIPAA technical safeguard expectations built on current NIST standards, and no longer holds up the same way in a PCI HSM or financial-examiner review. CMVP itself still lists Historical modules and continues to support the purchase and use of existing systems built on them, but it explicitly recommends buyers choose from currently validated modules for new deployments going forward.

In practice, three categories of organizations feel this differently:

• Organizations with no compliance obligation tied to CMVP status. A Historical certificate is a low-urgency issue. Plan a normal hardware refresh cycle toward FIPS 140-3.
• Organizations with a compliance obligation that references “validated” cryptography (FedRAMP, HIPAA, PCI HSM, defense contracts, state and federal procurement). A Historical certificate is an active finding waiting to happen at the next audit, examination, or contract renewal.
• Organizations actively procuring new HSMs right now. Any purchase order that specifies FIPS 140-2 as an acceptable validation target, rather than requiring an active FIPS 140-3 certificate, is building next year’s compliance gap today.

What Deployment Topology Should You Plan for an HSM Fleet Migration?

Migrating to FIPS 140-3 validated modules is a good forcing function to re-evaluate HSM topology, not just swap hardware in place. Four decisions shape the migration:

• Centralized versus distributed clusters. A centralized HA cluster in one or two data centers is simpler to validate and monitor, but it concentrates risk. A geographically distributed cluster spreads risk and supports regional data residency requirements, at the cost of more complex key synchronization and network segmentation.
• On-premises, cloud HSM, or hybrid. Cloud HSM services such as AWS CloudHSM and Google Cloud HSM now ship with FIPS 140-3 Level 3 validated hardware, which can shorten a migration considerably compared to a full on-premises hardware refresh. A hybrid model, on-premises HSMs for root and issuing CA keys, cloud HSM for high-throughput application workloads, is common where key custody requirements differ by use case.
• Partitioning and multi-tenancy. Decide whether the new modules will use logical partitions per application or per business unit, and confirm the FIPS 140-3 boundary and security level apply consistently across every partition, not just the physical appliance as a whole.
• Network segmentation for management interfaces. HSM management and PKCS#11/KMIP client traffic should sit on separate, tightly controlled network segments. Use the migration as the checkpoint to confirm this segmentation still matches current architecture, especially if the fleet has grown since the last topology review.

Document the target topology before ordering hardware. A migration that starts with “buy the same box, just newer” tends to reproduce whatever topology gaps the current fleet already has.

What Is the FIPS 140-3 Cryptographic Boundary, and Why Does It Matter Here?

The cryptographic boundary is the explicit physical or logical perimeter that encloses every hardware, firmware, and software component performing cryptographic operations inside the module. Everything inside the boundary was tested and validated together as a unit; nothing outside it can be assumed to carry the certificate’s assurance, even if it sits in the same physical chassis.

This matters directly during migration for three reasons. First, a firmware update that changes anything inside the boundary, including a patch that touches cryptographic code paths, technically produces a different module than the one that was validated, which is why vendors must re-submit updated firmware for its own certificate rather than treating it as a minor version bump. Second, FIPS 140-3 formally supports hybrid modules (hardware plus firmware, or hardware plus software) with no restriction on the security level they can reach, so a migration that changes the module type, for example moving from a pure hardware appliance to a cloud HSM service with a software-managed control plane, needs its own boundary review, not an assumption that “HSM to HSM” is a like-for-like swap. Third, when evaluating a cloud HSM or HSM-as-a-Service offering, confirm exactly what sits inside the vendor’s validated boundary and what sits outside it in the provider’s shared infrastructure; a certificate that covers the underlying hardware does not automatically cover every layer of a multi-tenant service built on top of it.

What Are the Key Ceremony Implications of Migrating to a New HSM?

Moving cryptographic material to a newly validated module is rarely a simple copy operation, and treating it as one is the most common technical mistake in an HSM migration.

• Root and CA keys almost always require a new ceremony. Because the cryptographic boundary changes with the module, root CA and other long-lived signing keys generally need to be generated fresh, inside the new module’s validated boundary, under a documented, witnessed ceremony, rather than exported and reimported. Plan custodian roles, M-of-N quorum requirements, and evidence capture (video, signed logs, witness attestations) the same way you would for a first-time root ceremony.
• Application and data-encryption keys may support a documented migration path. Some vendors offer secure key cloning or wrapped export/import between modules in the same product family, provided both modules are FIPS validated and the transfer stays encrypted end to end or uses split-knowledge procedures. Confirm this capability, and its own compliance standing, directly with the vendor before relying on it; do not assume it exists.
• Update your CP/CPS and key ceremony documentation. If a Certificate Policy or Certification Practice Statement references specific hardware, certificate numbers, or module names, the migration triggers a documentation update, not just a technical one, and that update itself may need governance sign-off before the new module goes into production.
• Re-attest custodian roles. Confirm that key custodians, ceremony witnesses, and approvers named in your governance documentation are still current, and formally re-attest their roles as part of the ceremony record for the new module.

For a full walkthrough of ceremony structure, custodian controls, and evidence packaging, see Encryption Consulting’s guide to designing a root CA key ceremony.

How Do You Plan a FIPS 140-3 HSM Migration?

A practical migration sequence, in order:

1. Inventory every cryptographic module in scope, HSMs, cloud HSM services, and vendor libraries included, and record each one’s current CMVP certificate number and status.
2. Verify every certificate directly at the CMVP Validated Modules Search page rather than relying on a vendor’s marketing claim of FIPS compliance.
3. Confirm your HSM vendor’s FIPS 140-3 validated firmware or hardware roadmap, including the target certificate number and expected availability date.
4. Define the target deployment topology, data center or cloud region placement, HA cluster size, and partitioning model, before ordering replacement hardware.
5. Plan the key ceremony for the new module: custodian roles, M-of-N quorum, key generation or migration method, and evidence capture.
6. Stage the new module alongside the existing one in a parallel or active-passive configuration, and cut application integrations over in controlled batches.
7. Validate every dependent application, backup path, and disaster-recovery node against the new HSM before decommissioning the FIPS 140-2 module.

Hardware lead times and lab validation queues mean this sequence typically spans three to six months for a production fleet with high availability requirements. Starting the inventory step today, three weeks before the Historical deadline, is still workable for planning purposes, but it will not complete a full hardware swap before September 21, 2026 for most organizations; the realistic goal at this point is a documented, funded migration plan with an active FIPS 140-3 procurement path, not a finished fleet replacement.

How Do You Maintain High Availability and Backup During the Migration?

An HSM migration should never create a single point of failure, even temporarily. A few rules keep availability intact:

• Keep N+1 capacity throughout the swap. Add the new FIPS 140-3 module to the cluster alongside the existing one rather than replacing a node outright, so the cluster never drops below its normal failover capacity mid-migration.
• Confirm your backup HSMs are FIPS 140-3 validated too. A backup or DR-site HSM still running FIPS 140-2 firmware undermines the compliance benefit of migrating the primary cluster, and it will still show a Historical certificate after September 21, 2026.
• Export key backups in a form the new module accepts. Key backup and restore should stay encrypted in transit and at rest, using vendor-supported wrapped export or split-knowledge procedures compatible with the new module’s boundary, not a raw export that assumes identical firmware on both ends.
• Rehearse failover and recovery on the new modules before cutover completes. Test that a live failover to the new HSM works under load, and that a restore from backup onto a freshly provisioned new module succeeds, before you decommission the last FIPS 140-2 node.

What Are the Integration Prerequisites Before You Migrate?

Before cutting any application over to the new module, confirm the following:

• Every application’s PKCS#11, KMIP, CNG, or JCE client library is compatible with the new module’s firmware and API version. A library built against an older interface can fail silently rather than loudly.
• FIPS mode is actually enabled in the production configuration of every dependent application, not just supported by the module. A FIPS-validated module running in a non-FIPS default configuration, “FIPS Capable” rather than “FIPS Compliant” in practice, is one of the most common gaps compliance assessments miss.
• Throughput and latency are tested under realistic load. Non-invasive attack mitigations and stricter self-tests in FIPS 140-3 modules can measurably change signing and encryption performance compared to older FIPS 140-2 hardware; capacity-plan accordingly rather than assuming a straight swap.
• Monitoring, alerting, and audit logging reference the new module’s certificate number and serial identifiers, so operational dashboards and compliance evidence stay accurate after cutover.
• Runbooks for key rotation, backup, and incident response are updated to reflect the new module’s procedures, since FIPS 140-3’s stricter authentication and key management rules may change steps that used to be routine.

What Happens If You Miss the September 21, 2026 Deadline?

The most common failure mode is not a dramatic outage. It is a quiet compliance gap created by procurement paperwork that was never updated. A typical version: a purchasing team issues a renewal order referencing the same HSM model and specification sheet used two or three years earlier, which still lists FIPS 140-2 as an acceptable validation target. The hardware ships, gets deployed, and works fine technically, but the organization has just added a module whose certificate is about to be, or already is, on the Historical list, into a compliance-bound environment.

The consequences surface later and unevenly: a FedRAMP continuous monitoring reviewer flags the module, a HIPAA breach investigation finds the encryption in place does not qualify for safe harbor, a defense contract renewal stalls because the required active FIPS 140-3 certificate cannot be produced, or a financial examiner opens a finding your team cannot close without another hardware cycle. None of these are hypothetical; they are the direct, foreseeable result of a procurement specification that was never updated to match the compliance deadline.

Two actions close this gap before it opens. First, review every open purchase order, RFP, and vendor contract for HSM hardware or firmware, and add “active FIPS 140-3 CMVP certificate at time of delivery” as a hard requirement, not a preference. Second, audit any HSM delivery already scheduled for after September 21, 2026 against the vendor’s confirmed FIPS 140-3 certificate number; if the vendor cannot provide one, that delivery is the gap.

Module Status Decision Table

Module status	What to do	Deadline
FIPS 140-2 certificate, currently Active	Continue operating deployed hardware; begin FIPS 140-3 migration planning and procurement now.	Certificate moves to Historical on September 21, 2026.
FIPS 140-2 certificate, already Historical or Revoked	Do not rely on it for new compliance-bound procurement; prioritize replacement for regulated workloads.	Now.
FIPS 140-3 certificate, Active	Preferred status for all new HSM procurement and compliance-sensitive deployments.	Ongoing; confirm status at each renewal.
FIPS 140-3 submission listed on the CMVP Modules In Process list	Track the listing; do not cite an in-process submission as current validation in an audit or attestation until it clears to Active.	Varies by vendor and CMVP queue.
No CMVP certificate; vendor claims “FIPS compliant” only	Treat as unverified. Request the certificate number and confirm Active status directly at csrc.nist.gov before deployment.	Before procurement, not after.

Limitations

This guide covers the general HSM migration path and does not replace a vendor-specific gap assessment. Sector-specific frameworks, FedRAMP, PCI HSM, and defense procurement among them, can impose stricter interim requirements or their own transition timelines layered on top of the CMVP deadline. Security-level requirements (Level 2 versus Level 3 versus Level 4) also change what “compliant” migration looks like for a given use case; a Level 3 payment HSM and a Level 1 software module do not carry the same migration burden. This article focuses on FIPS 140-3 module validation and does not cover post-quantum algorithm migration, which is a related but separate project for most HSM fleets. CMVP certificate statuses and queue timelines can change; always confirm current status at the CMVP Validated Modules Search page before making a procurement or compliance decision.

What Would Encryption Consulting Recommend?

Start with a verified inventory, not a purchase order. Before replacing a single HSM, confirm exactly which modules in your environment carry Active FIPS 140-2 certificates, which are already Historical, and which already run FIPS 140-3. That inventory step alone resolves most of the false confidence organizations carry into this deadline, since “FIPS compliant” on a vendor data sheet and “FIPS 140-3 validated” in the CMVP database are not the same claim.

From there, we typically recommend two tracks running in parallel. Encryption Consulting’s HSM Services team handles the technical side: fleet inventory, deployment topology design, key ceremony planning and execution, and staged migration to FIPS 140-3 validated hardware or cloud HSM services, with high availability preserved throughout. For organizations that want the hardware managed rather than owned outright, HSM-as-a-Service delivers FIPS 140-3 validated, dedicated HSM capacity without the lead time or capital cost of a full on-premises refresh, which can meaningfully shorten the timeline for teams starting late.

In parallel, Encryption Consulting’s Compliance Advisory team maps the migration to whatever framework your organization answers to, FedRAMP, HIPAA, PCI HSM, or defense procurement, so the evidence package (certificate numbers, ceremony records, updated CP/CPS) is ready for the next audit or examination rather than assembled after the fact.

Frequently Asked Questions

When do FIPS 140-2 certificates become invalid?

All FIPS 140-2 certificates move to CMVP Historical status on September 21, 2026. Existing deployments keep functioning, but the certificate no longer satisfies federal procurement, FedRAMP, or HIPAA safe harbor requirements that call for an active, validated module.

Can I still buy a FIPS 140-2 validated HSM after September 21, 2026?

You can still purchase and deploy hardware carrying an existing FIPS 140-2 certificate, but CMVP will no longer treat that certificate as current. For new procurement, request an HSM with an active FIPS 140-3 certificate instead, since relying on a soon-to-be Historical module creates avoidable compliance risk.

Does my current HSM stop working when its FIPS 140-2 certificate goes Historical?

No. Historical status is a validation-database change, not a kill switch. The module keeps encrypting, signing, and generating keys exactly as before. What changes is whether an auditor, examiner, or federal contracting officer will still accept that certificate as proof of current compliance.

What is the biggest technical difference between FIPS 140-2 and FIPS 140-3?

FIPS 140-3 adds a dedicated non-invasive security area that requires HSM vendors to test and mitigate side-channel attacks such as power analysis and electromagnetic analysis, a class of attack FIPS 140-2 never addressed. It also aligns testing with ISO/IEC 19790:2012 and ISO/IEC 24759 and disallows legacy algorithms like Triple-DES, SHA-1 for signatures, RSA-1024, and MD5.

How long does it take to migrate an HSM fleet to FIPS 140-3?

Plan for three to six months once you include hardware lead times, key ceremony scheduling, and integration testing across every application that talks to the HSM. Vendor firmware-only upgrades move faster; a full hardware swap across a production fleet with high availability requirements typically anchors the low end of that range.

Conclusion

September 21, 2026 is not a soft target. It is a fixed date CMVP has held for years, and it arrives in weeks, not quarters. Organizations that treat this as a hardware refresh alone will miss the parts that actually create risk: a deployment topology that was never re-evaluated, a key ceremony done informally instead of documented, backup HSMs still running old firmware, and integration testing skipped because “it’s the same HSM, just newer.” The technical work, inventory, verified certificate status, topology design, key ceremony, HA-safe cutover, and integration validation, is what separates a compliant migration from a hardware purchase that looks compliant on paper.

Contact Encryption Consulting at [email protected] to start an HSM fleet inventory and FIPS 140-3 migration plan before the September 21, 2026 deadline.

References

NIST CSRC: FIPS 140-3 Transition Effort

Federal Register: Announcing Issuance of FIPS 140-3

NIST CSRC: Cryptographic Module Validation Program (CMVP)

Encryption Consulting: FIPS 140-3 What Organizations Need to Know by Sept. 2026