Why the FIPS 140-3 Transition Is Harder Than It Looks: Eight Challenges That Derail Programs

Most organizations discover the FIPS 140-3 transition is far more complex than a certificate swap. The September 21, 2026 deadline for all FIPS 140-2 certificates to move to Historical status has now passed. Eight structural challenges consistently derail programs: misleading compliance language, a CMVP validation queue running twelve to eighteen months, legacy algorithms embedded in vendor code, HSM lead times of three to six months, cloud KMS defaults that are not in FIPS mode, an uncontrollable vendor ecosystem, assessment scopes that miss SaaS and devices, and a timeline less forgiving than it first appears. Each has a known solution, and every solution consumes time that cannot be recovered once the deadline has passed.

Quick Answer: Why Is the FIPS 140-3 Transition So Difficult?

The FIPS 140-3 transition consistently surprises organizations because the hardest problems are structural, not technical. The CMVP queue runs twelve to eighteen months, longer than most programs plan for. HSMs have three to six month hardware replacement lead times when firmware upgrade paths do not exist. Cloud KMS is almost never in FIPS mode by default. And the most common production gap, FIPS-capable-but-not-enabled, is invisible to standard security audits. Starting the vendor conversation and the cryptographic discovery simultaneously is the single most important first action.

Key Takeaways

• Vendor confirmations of “FIPS compliance” without a CMVP certificate number are unverifiable self-declarations. The box-checking approach produces false confidence, not coverage.
• The most common gap in production environments is FIPS-capable-but-not-enabled: a valid certificate on a module running in a non-FIPS default configuration, invisible to standard audits.
• The CMVP queue runs twelve to eighteen months. A module submitted in mid-2025 may not hold an active certificate by September 21, 2026. In-process status is not a valid compliance state for FedRAMP, OCR, or financial examination.
• HSMs are the longest lead-time item: when no firmware upgrade path exists, replacement runs three to six months, which means the vendor conversation belongs at the start of the program.
• No major cloud provider puts key management in FIPS mode by default. AWS FIPS endpoints, Azure HSM-backed tiers, and GCP Cloud HSM key rings are all explicit configuration choices that must be made deliberately.
• Assessment scopes that cover only HSMs and TLS endpoints miss SaaS platforms, custom applications, and connected devices, where significant legacy algorithm exposure is commonly found.
• The September 21, 2026 deadline for FIPS 140-2 Historical status has now passed. Organizations without active FIPS 140-3 certificates for all in-scope modules have a current compliance gap, not an upcoming one.

This is Part 2 of a three-part series. Part 1 covers what FIPS 140-3 requires, what changed from FIPS 140-2, and why the September 21, 2026 deadline carries immediate compliance weight. Part 3 is the step-by-step transition playbook.

Here is how most FIPS 140-3 conversations go. An organization asks vendors to confirm FIPS 140-3 certification. The vendors say yes, they are compliant. The organization documents the response, checks the box, and moves on, feeling reasonably covered. That approach produces false confidence that is, in some ways, more dangerous than no assessment at all. The compliance gaps that surface during audits and breach investigations are almost never the ones everyone already knows about. They are structural ones: the product that holds a valid FIPS certificate but runs in a non-FIPS default configuration, the cloud key management service pointed at a standard endpoint when compliance requires the FIPS endpoint, the HSM firmware nobody checked for a FIPS 140-3 upgrade path until it was too late to replace the hardware.

Challenge 1: What Does “FIPS Compliant” Actually Mean?

Three phrases appear interchangeably in vendor responses, procurement documents, and internal compliance reviews. They are treated as equivalent. They are not, and the gap between them is exactly where most organizations are surprised.

Term	What it actually means	What auditors accept
FIPS Validated	An independent NIST-accredited laboratory tested the specific module at a specific version, and NIST issued an active certificate verifiable at csrc.nist.gov. The certificate number is tied to the exact hardware and firmware or software build tested.	Yes. This is what federal procurement, HIPAA, FedRAMP, and CMMC require.
FIPS Compliant	A vendor self-declaration. No laboratory, no certificate, no external verification. The vendor is asserting that its product follows FIPS standards, but there is no mechanism to independently confirm this claim.	No. Cannot be independently verified the way a CMVP certificate number can be verified.
FIPS Capable	The product contains a FIPS-validated module that can run in FIPS-approved mode, but is currently running in a non-FIPS default configuration. Self-tests are off. Algorithm restrictions are not enforced. The certificate is real; the compliance is not.	No. The module must be operating in its FIPS-approved mode of operation, not merely capable of it.

Products frequently ship in non-FIPS defaults because those configurations expose more functionality. Enabling FIPS mode is a deliberate configuration step documented in the module’s Security Policy, and without a specific program to verify it, it often does not get taken. This gap generates no alerts, appears in no vulnerability scan, and is invisible to standard security audits. The only way to find it is a dedicated cryptographic assessment that examines actual runtime configuration against each module’s Security Policy.

Challenge 2: Why Does the CMVP Queue Exceed Most Transition Timelines?

The Cryptographic Module Validation Program (CMVP) queue has historically run twelve to eighteen months from submission to active certificate. That is not a temporary backlog; it is a structural feature of the validation process. Testing by a NIST-accredited Cryptographic Security Testing Laboratory (CSTL), followed by CMVP review, comment resolution, and certificate issuance, takes time that cannot be compressed by urgency.

The practical implication: a vendor module submitted for FIPS 140-3 validation in mid-2025 may not have had an active certificate by September 21, 2026. Organizations that treated an in-process CMVP submission as equivalent to active certification were carrying compliance risk they had not correctly characterized. A FedRAMP 3PAO assessment, an OCR audit, and a financial examiner review do not accept in-process status as a valid compliance state.

The response: monitor the CMVP In-Process list at csrc.nist.gov for every in-scope vendor module, engage vendors directly on realistic completion timelines, and build contingency plans for modules whose timelines create genuine uncertainty. These conversations need to happen at the start of any FIPS 140-3 program, in parallel with the rest of the assessment, because vendor timelines are entirely outside your control.

Challenge 3: Why Is Removing Legacy Algorithms Not a Simple Configuration Change?

FIPS 140-3 prohibits algorithms that are present in legacy environments across every regulated industry. Finding them is the straightforward part. Removing them is a different category of problem:

• Triple-DES persists in payment interfaces, legacy middleware, and database encryption that has not been touched in years. In many environments it is embedded in vendor-controlled code the organization cannot modify. Removal requires a vendor coordination cycle, not a configuration change.
• SHA-1 lives in certificate chains from PKI deployments stood up years ago and never reissued. Replacing it means replacing every certificate in the chain (root, intermediate, and leaf), which cascades into every system that depends on those certificates.
• RSA-1024 appears in older PKI configurations, smart card systems, and device firmware where only the manufacturer can update the cryptographic stack. Options are to engage the manufacturer and wait, or replace the device.
• TLS 1.0 and 1.1 persist on legacy portals and internal endpoints where platform vendor coordination has been repeatedly deprioritized. Finding them requires active scanning; remediating them requires vendor cycles proportional to the number of affected systems.

The remediation path for each varies from a configuration change that takes hours to a vendor replacement program that takes months. The constraint is fixed: legacy algorithm remediation timelines do not compress because a deadline is close.

Challenge 4: Why Are HSMs the Longest Lead-Time Item in the Program?

Hardware security modules are the cryptographic backbone of PKI, key management, and payment processing. They are also the component with the longest remediation lead time, and the one most likely to produce an uncomfortable surprise when the firmware question gets asked for the first time.

Many deployed HSMs held FIPS 140-2 certificates that moved to Historical status on September 21, 2026. The question for each HSM is not just whether a FIPS 140-3 certificate exists for the model. It is whether the specific firmware version running in production holds that certificate, and whether the vendor offers a supported upgrade path. Many organizations are discovering that the answer to the second question is no.

When no firmware upgrade path exists, hardware replacement is the only route: procurement, physical installation, key migration, testing, and change management, three to six months in most environments. This conversation with HSM vendors belongs at the beginning of the assessment, not after everything else is complete. For organizations that need FIPS 140-3 Level 3 validated key custody without the capital expense and procurement lead time of on-premises hardware, HSM-as-a-Service provides dedicated, compliance-grade HSM capacity with full CMVP certificate documentation.

Challenge 5: Why Is Cloud KMS Almost Certainly Not in FIPS Mode?

Organizations using major cloud providers for key management routinely assume that doing so satisfies FIPS compliance. It can, but not automatically and not without specific configuration choices that are not the default in any major cloud platform:

Cloud provider	What FIPS mode actually requires	What standard configuration provides
AWS KMS	FIPS endpoints (kms-fips.[region].amazonaws.com). Applications must be configured to call the FIPS endpoint specifically.	Standard regional endpoints are not the FIPS-validated path regardless of the underlying HSM hardware certification.
Azure Key Vault	Hardware-backed validation: Premium tier or Managed HSM, both now validated at FIPS 140-3 Level 3.	Standard-tier Key Vault stores keys in software, outside the hardware boundary. Level 1 assurance only.
Google Cloud KMS	Cloud HSM key rings must be explicitly provisioned. Hardware-backed keys with FIPS 140-2 Level 3 validated HSMs.	Standard Cloud KMS software keys carry only Level 1 validation. Hardware assurance requires explicit Cloud HSM selection.

Standard cloud security reviews do not examine KMS endpoint configuration or key tier selection at the cryptographic level. This gap surfaces only when someone is specifically looking for it, and in most cloud environments no one has been. It is consistently one of the most common findings in the FIPS 140-3 assessments Encryption Consulting conducts.

Challenge 6: How Do You Manage a Vendor Ecosystem You Cannot Directly Control?

An organization’s FIPS 140-3 posture is only as strong as the weakest cryptographic module in its vendor ecosystem. EHR platforms, SaaS tools, laboratory systems, payment processors, and payer network interfaces all embed cryptographic modules, and every module needs an active FIPS 140-3 certificate for the overall posture to hold.

Many vendors have not yet completed FIPS 140-3 validation. Some are in the CMVP queue; some have not started. The discipline that makes this manageable is straightforward: require a CMVP certificate number from every vendor with in-scope modules and verify each one at csrc.nist.gov. This converts a trust exercise into a verification exercise, which is exactly what regulators and auditors require. For a broader view of FIPS compliance requirements, see our comprehensive guide.

Medical devices are the hardest version of this problem. Where the cryptographic stack cannot be modified by the organization, only the manufacturer can remediate, and their timelines are entirely outside your control. Engaging them early is the only approach that leaves enough lead time to respond if their answer is not reassuring.

Challenge 7: Why Is the Assessment Scope Almost Always Too Narrow?

Organizations that run internal FIPS assessments tend to scope them around the infrastructure they already know: HSMs, TLS endpoints, and VPN gateways. That scope misses a meaningful portion of the actual cryptographic footprint:

• SaaS platforms are the most commonly skipped category. Revenue cycle tools, patient engagement platforms, and analytics applications all embed cryptographic controls that infrastructure scans cannot reach. The only path is structured vendor questionnaires with direct CMVP verification.
• Custom applications with direct cryptographic library calls need code-level assessment. Network scanning tells you a TLS connection exists; it does not tell you which algorithm a key generation call is making, or whether the library in use has a FIPS-validated mode that is actually enabled.
• Connected devices and OT equipment are almost always outside infrastructure assessments. Operational technology refresh cycles measured in decades mean deprecated algorithms can sit entrenched in operational environments for years with no governance process that has ever touched them.

A complete cryptographic discovery using CBOM Secure covers cloud accounts, on-premises infrastructure, applications, and vendor environments, producing a Cryptographic Bill of Materials that maps every algorithm, key type, and module to its CMVP status. This is the only way to build an assessment scope that does not leave significant exposure unexamined.

Challenge 8: Why Is the FIPS 140-3 Timeline Less Forgiving Than It Appears?

The September 21, 2026 deadline has now passed. For organizations that did not complete their transition before that date, this is no longer a planning exercise. It is a current compliance gap requiring an active remediation program, not a plan to start one.

For organizations building their program now, the timeline math is instructive. Thorough cryptographic discovery and CBOM development take two to four weeks. Gap analysis and risk classification take another two to three weeks. That leaves the remaining time for all remediation activity, which must accommodate HSM firmware upgrade cycles of four to six weeks minimum, certificate replacement across PKI environments, cloud KMS reconfiguration with downstream compatibility testing, and vendor escalation timelines outside your control.

Organizations that run a structured program reach assessors with a defensible posture. Organizations that defer discovery until remediation is urgent are making triage decisions, prioritizing the highest-risk items, and accepting documented risk on the rest. The difference between a defensible posture and a compliance gap is almost entirely determined by when the program started.

FIPS 140-3 Transition: Eight Challenges Mapped to Controls and Evidence

The table below maps each of the eight challenges to the control that closes it, the evidence artifact an assessor expects to see, and the owner responsible:

Challenge	Control that closes it	Evidence artifact	Owner
1. Misleading compliance language (Validated vs. Compliant vs. Capable)	Require CMVP certificate number from every vendor; verify Active status and exact module version at csrc.nist.gov; confirm FIPS-approved mode is enabled via runtime configuration review	CMVP database query results per module; runtime FIPS mode verification logs; Security Policy comparison documentation	Compliance / Security Engineering
2. CMVP queue running 12 to 18 months	Monitor CMVP In-Process list for all in-scope vendor modules; engage vendors on realistic certification timelines; build contingency plans for modules with timeline uncertainty	Vendor CMVP status tracking log; vendor written timeline commitments; contingency decision register	Compliance / Procurement
3. Legacy algorithms embedded in vendor code	Cryptographic discovery scan across all environments; vendor coordination requests for prohibited algorithm removal; documented replacement timeline for each finding	CBOM or algorithm scan output; vendor remediation commitments; before-and-after scan confirming removal	Security Engineering / Vendor Management
4. HSM hardware lead times of 3 to 6 months	Immediate HSM vendor engagement to confirm firmware upgrade path for FIPS 140-3; replacement procurement initiated if no upgrade path exists; key migration plan documented	Vendor written confirmation of FIPS 140-3 upgrade path or replacement decision; procurement records; key migration runbook	Security Engineering / Procurement
5. Cloud KMS not in FIPS mode by default	Audit all cloud KMS configurations against FIPS endpoint and tier requirements; reconfigure to FIPS endpoints, HSM-backed tiers, and Cloud HSM key rings as required; downstream compatibility testing	Cloud KMS configuration documentation showing FIPS endpoint or HSM-backed tier; compatibility test results	Cloud Engineering / Security
6. Uncontrollable vendor ecosystem	Structured vendor questionnaire requiring CMVP certificate number for every in-scope vendor module; direct CMVP verification for each response; contingency plan for vendors that cannot certify	Vendor CMVP verification log with certificate numbers and verification dates; contingency decision register	Vendor Management / Compliance
7. Assessment scope too narrow (SaaS, custom apps, OT excluded)	Expand discovery scope to include SaaS platforms (via vendor questionnaires), custom application code (via code-level review or CBOM), and connected devices (via OT-specific assessment)	CBOM covering all environment types; SaaS vendor CMVP verification; custom application cryptographic library assessment	Security Architecture / Compliance
8. Timeline less forgiving than expected	Begin cryptographic discovery and vendor engagement simultaneously on day one of the program; classify all gaps by remediation timeline; escalate long-lead items immediately	Program start date; discovery completion date; gap classification with remediation timeline per finding; escalation log for long-lead items	Program Management / Compliance

How Encryption Consulting Can Help With FIPS 140-3 Transition

Each of the eight challenges has a known solution. What determines whether organizations reach a defensible FIPS 140-3 posture is whether they have the right advisory structure and the evidence packages that auditors need to verify.

• FIPS 140-3 Compliance Assessment: Comprehensive cryptographic discovery across HSMs, TLS endpoints, cloud KMS, PKI infrastructure, SaaS platforms, custom applications, and connected devices, producing a complete Cryptographic Bill of Materials with every gap classified by risk level and every vendor module status verified directly at csrc.nist.gov. Coverage across all eleven FIPS 140-3 security areas, not just algorithms and certificate status.
• FIPS Mode Verification: Runtime configuration assessment against each module’s Security Policy. This is the check that surfaces the FIPS-capable-but-not-enabled gap that standard audits cannot detect, and it appears in almost every environment we assess.
• Vendor Engagement Program: Direct CMVP certificate verification for every in-scope vendor module, certification timeline collection, CMVP backlog risk characterization, and replacement decision support, starting day one of the engagement.
• FIPS 140-3 Transition Strategy: A risk-prioritized, sequenced remediation roadmap reflecting the actual constraints in your environment: HSM lead times, CMVP queue positions, cloud reconfiguration dependencies, and vendor availability. Calibrated to your specific regulatory obligations, not a generic framework.
• HSM as a Service: For organizations that need FIPS 140-3 Level 3 validated key custody without the capital expense and procurement lead time of on-premises hardware, HSM-as-a-Service provides dedicated compliance-grade HSM capacity with full CMVP certificate documentation and configuration evidence available for audit review.

Conclusion

None of the eight challenges is unsolvable. The CMVP backlog is manageable if vendor engagement starts early enough. The FIPS mode gap is identifiable through a runtime configuration assessment. HSM lead times fit within available windows if the hardware assessment happens at the beginning of the program. Cloud KMS misconfigurations are a one-time fix once someone actually looks for them.

The thread running through all eight is time. Each challenge requires more of it than organizations initially expect, and none can be compressed by urgency once the deadline has passed. The September 21, 2026 deadline is behind us. For organizations with unresolved gaps, the work is current remediation with documented compensating controls, not future planning. For organizations building programs now, the same structural challenges apply, and the same solution applies: start with cryptographic discovery and vendor engagement simultaneously, classify gaps by remediation timeline, and escalate the long-lead items immediately.

Part 3 of this series is the step-by-step playbook: the complete four-phase migration framework, the vendor management approach that determines whether the program produces a defensible posture, and the compliance checklist that defines when the work is actually done. Read Part 3.

Frequently Asked Questions

How long does CMVP validation take?

The CMVP queue historically runs twelve to eighteen months from submission to active certificate. This is structural, not a temporary delay. A module submitted in mid-2025 may not have held an active certificate by September 21, 2026. In-process status is not accepted as valid by FedRAMP 3PAOs, OCR auditors, or financial examiners.

Is a vendor’s claim of FIPS compliance sufficient for audit purposes?

No. Without a verified CMVP certificate number at csrc.nist.gov, it is an unverifiable self-declaration. Require the certificate number, confirm Active status, match the module version to what is actually deployed in production, and verify that FIPS-approved mode is enabled in the runtime configuration.

How do I verify that FIPS mode is actually enabled?

Examine runtime configuration against each module’s Security Policy: confirm self-tests execute at startup, algorithm restrictions are enforced (prohibited algorithms are blocked), and the operational configuration matches the validated mode of operation. Certificate possession alone proves nothing about the running state. Standard security audits do not check this.

Is AWS, Azure, or Google Cloud key management FIPS-compliant by default?

Not at the assurance level most programs require. AWS requires FIPS endpoints (kms-fips.[region].amazonaws.com). Azure requires the HSM-backed Premium tier or Managed HSM. Google Cloud requires Cloud HSM key rings for hardware-backed keys; software keys carry only Level 1 validation. None of these is the default configuration in any major cloud platform.

What if a vendor cannot certify before September 2026?

The September 2026 deadline has passed. For vendors that did not complete certification by that date, organizations must make a documented decision: risk acceptance with compensating controls for lower-risk systems, or replacement procurement for systems handling regulated data. Late contingency decisions become impossible ones. If a vendor cannot provide a realistic timeline with CMVP evidence, begin replacement procurement immediately.

What is FIPS-capable-but-not-enabled and why is it the most common production gap?

FIPS-capable-but-not-enabled describes a product with a valid FIPS certificate that is running in a non-FIPS default configuration. Self-tests are not executing, algorithm restrictions are not enforced, and the validated module is not protecting the organization’s data. It generates no alerts, appears in no vulnerability scan, and is invisible to standard audits. It is consistently the most common finding in dedicated FIPS assessments because products ship in non-FIPS defaults that expose more functionality.

Why are HSMs the longest lead-time item in a FIPS 140-3 program?

When no firmware upgrade path to FIPS 140-3 exists, hardware replacement requires procurement, physical installation, key migration, testing, and change management: three to six months in most environments. The question is not only whether a FIPS 140-3 certificate exists for the HSM model, but whether the specific firmware version in production holds that certificate and whether the vendor offers a supported upgrade path. This conversation belongs at the start of the program, not after everything else is assessed.