Quick answer: Most organizations discover the FIPS 140-3 transition is far more complex than a certificate swap. Eight challenges consistently derail programs: misleading compliance language, a CMVP validation queue that runs twelve to eighteen months, legacy algorithms embedded in vendor code, HSM lead times of three to six months, cloud KMS defaults that are not FIPS mode, an uncontrollable vendor ecosystem, assessment scopes that miss SaaS and devices, and a timeline that is less forgiving than it looks. Each has a known solution, and every solution consumes time.

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, and in-process status is not a valid compliance state.
HSMs are the longest lead-time item: when no firmware upgrade path exists, replacement runs three to six months, which means the vendor conversation has to happen 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.

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 playbook.

Here is how most FIPS 140-3 conversations go. Someone asks their vendors to confirm FIPS 140-3 certification. The vendors say yes, we are compliant. The organization documents the response, checks the box, and moves on, feeling reasonably covered.

That approach produces a false sense of security that is, in some ways, more dangerous than no assessment at all. The compliance gaps that actually surface during audits and breach investigations are almost never the ones everyone already knows about. They are the 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: The language is doing a lot of work

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 get surprised.

FIPS Validated means an independent NIST-accredited laboratory tested the specific module at a specific version, and NIST issued an active certificate, verifiable at csrc.nist.gov. This is what compliance actually requires.
FIPS Compliant is a self-declaration. No laboratory, no certificate, no external verification.
FIPS Capable means the product contains a FIPS-validated module that can run in FIPS mode but is currently running in a non-FIPS default. Self-tests off, algorithm restrictions unenforced. The certificate is real; the compliance is not.

Products frequently ship in non-FIPS defaults because those configurations expose more functionality. Enabling FIPS mode is a deliberate configuration step, and without a specific program to verify it, it often is not 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: The CMVP queue is longer than your transition timeline

The Cryptographic Module Validation Program 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.

The practical implication: a vendor module submitted for FIPS 140-3 validation in mid-2025 may not have an active certificate by September 21, 2026. Organizations that treat an in-process CMVP submission as equivalent to active certification are carrying compliance risk they have not correctly characterized. A FedRAMP 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 now, in parallel with the rest of the assessment, because vendor timelines are entirely outside your control and cannot be compressed by urgency alone.

Challenge 3: Removing legacy algorithms is not a 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 entirely.

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. Your 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. Organizations that start discovery late simply do not have time to execute the longer paths before September 21. That is not a warning; it is a scheduling constraint with a fixed endpoint.

Challenge 4: Your HSMs are 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 hold FIPS 140-2 certificates that go Historical in September. The question for each one 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. An organization that discovers this in June or July 2026 is almost certainly not completing the replacement before September 21. This conversation with HSM vendors belongs at the beginning of the assessment, not after everything else is complete.

Challenge 5: Your cloud KMS is 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.

Provider	What FIPS mode actually requires
AWS KMS	FIPS endpoints (kms-fips.[region].amazonaws.com). Applications calling standard regional endpoints are not using the FIPS-validated path, regardless of what the underlying infrastructure (FIPS 140-3 Level 3 HSMs) is certified for.
Azure Key Vault	Hardware-backed validation applies to the Premium tier and Managed HSM, both now validated at FIPS 140-3 Level 3. Standard-tier Key Vault stores keys in software, outside that hardware boundary.
Google Cloud KMS	Cloud HSM key rings (FIPS 140-2 Level 3 validated HSMs) must be explicitly provisioned. Software keys in standard Cloud KMS carry only Level 1 validation; workloads requiring hardware-backed assurance need Cloud HSM.

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 assessments we conduct.

Challenge 6: Your vendors are a dependency 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, payer network interfaces: every one embeds cryptographic modules, and every module needs an active FIPS 140-3 certificate for your overall posture to hold.

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

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

Challenge 7: Your assessment scope is probably 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, and the omitted material is not trivial.

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 turned on.
Connected devices and OT equipment are almost always outside infrastructure assessments. NIST documentation notes OT refresh cycles measured in decades, which means deprecated algorithms can sit entrenched in operational environments for years with no governance process that has ever touched them.

Challenge 8: The timeline is less forgiving than it looks

Organizations starting FIPS 140-3 programs in June 2026 have roughly fourteen weeks before September 21. That sounds like a workable runway. Walk through the math, and it is tight.

Thorough cryptographic discovery and CBOM development take two to four weeks. Gap analysis and risk classification take another two to three. That leaves seven to ten weeks for all remediation activity, which has to accommodate HSM firmware upgrade cycles of four to six weeks minimum, certificate replacement across large PKI environments, cloud KMS reconfiguration with downstream compatibility testing, and vendor escalation timelines outside your control.

Organizations that start now run a structured program and reach September 21 with a defensible posture. Organizations that start in July are making triage decisions, remediating the highest-priority items, and accepting risk on the rest. Organizations that start in August are not managing a transition; they are managing a compliance gap.

How Encryption Consulting can help

Each of these eight challenges has a known solution. What determines whether organizations reach September 21 with a defensible compliance posture is whether they have the right advisory structure and the remaining timeline to execute.

FIPS 140-3 Compliance Assessment: Comprehensive cryptographic discovery across HSMs, TLS endpoints, cloud KMS, PKI, SaaS platforms, custom applications, and connected devices, producing a complete Cryptographic Bill of Materials with every gap classified by risk level.
FIPS Mode Verification: Runtime configuration assessment against each module’s Security Policy. This is the check that surfaces the FIPS-capable-but-not-compliant gap that standard audits cannot detect, and it turns up in almost every environment we examine.
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 the September 21, 2026, deadline.

Frequently asked questions

How long does CMVP validation take?

Historically, twelve to eighteen months from submission to an active certificate. In-process status is not accepted as a valid compliance state by FedRAMP assessors, OCR auditors, or financial examiners.

Is a vendor’s claim of FIPS compliance enough?

No. Without a verified CMVP certificate number on csrc.nist.gov, it is an unverifiable self-declaration. Require the number, confirm the active status, and match the module version to what is actually deployed.

How do I check whether FIPS mode is actually enabled?

Examine runtime configuration against each module’s Security Policy: confirm self-tests execute, algorithm restrictions are enforced, and the configuration matches the validated mode of operation. Certificate possession alone proves nothing about the running state.

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

Not at the assurance level most programs need. AWS requires FIPS endpoints (kms-fips.[region].amazonaws.com), Azure requires the HSM-backed Premium tier or Managed HSM, and 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.

What if my vendor cannot certify before September 2026?

Make the contingency decision early: risk acceptance with compensating controls for low-risk systems, or replacement procurement for systems handling regulated data. Late contingency decisions become impossible ones.

Conclusion

None of the eight challenges is unsolvable. The CMVP backlog is manageable if vendor engagement starts early enough. The FIPS mode gap can be identified through a runtime configuration assessment. HSM lead times fit within the available window 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 is close enough that urgency is the only tool available. The organizations that complete FIPS 140-3 transitions on time treat them as structured programs with defined phases and realistic timelines, not projects that can be accelerated into a sprint when September is visible on the horizon.

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 lands before the deadline, and the eight-point compliance checklist that defines when the work is actually done. Contact Encryption Consulting at info@encryptionconsulting.com to book your personalized consultation call.