The FIPS 140-3 Transition Playbook: How to Get Compliant Before September 21, 2026 

Quick answer: A complete FIPS 140-3 transition runs in four phases: Discover (build the Cryptographic Bill of Materials), Remediate (six parallel tracks covering algorithms, HSMs, FIPS mode, cloud KMS, vendors, and documentation), Verify (post-remediation scanning and the compliance evidence package), and Sustain (the ongoing program that keeps compliance alive). The framework works when discovery starts immediately, and the longest-lead-time tracks, HSM replacement, and vendor escalation, run from day one.

Key takeaways

• Parts 1 and 2 covered the what and the why; this is the how: a four-phase framework that takes an organization from unknown cryptographic posture to defensible, evidence-supported compliance.
• The Cryptographic Bill of Materials built in Phase 1 determines everything downstream. The assets that get missed, east-west TLS, shadow certificates, cloud KMS tiers, and SaaS platforms, are the ones outside the default tool scope.
• All six remediation tracks must start simultaneously, because HSM hardware replacement and vendor CMVP timelines cannot wait for shorter tracks to finish.
• Compliance is attestable only with evidence: CMVP records verified at csrc.nist.gov, configuration exports, key ceremony records, test results, and updated policies.
• The eight-point checklist at the end defines what done actually looks like, confirmed through direct verification, not assumed from vendor claims.

This is Part 3 of a three-part series. Part 1 covers what FIPS 140-3 requires and what changed from FIPS 140-2. Part 2 covers the eight challenges that consistently derail transition programs. Every one of those challenges, the CMVP backlog, the FIPS mode gap, HSM lead times, cloud KMS defaults, vendor ecosystem complexity, has a known solution. What varies across organizations is not whether the solutions exist, but whether there is enough structure and remaining time to execute them before September 21, 2026.

For organizations starting now, the roughly fourteen-week runway is workable but has no slack. It stops being workable if the early weeks are spent deciding how to start, if the hard activities get deferred until the easy ones are done, or if vendor engagement waits for the internal assessment to finish. The framework that works sequences activities correctly, runs the longest-lead-time tracks from day one, and treats the whole effort as a coordinated program rather than a sequential checklist.

What does the four-phase framework look like?

Phase	Timing	What it produces
1. Discover	Weeks 1–4	A complete Cryptographic Bill of Materials: every cryptographic asset, its configuration, its FIPS certificate status, and its risk classification.
2. Remediate	Weeks 3–12	Six parallel tracks: algorithm remediation, HSM upgrades, FIPS mode activation, cloud KMS reconfiguration, vendor escalation, and documentation.
3. Verify	Weeks 11–14	Post-remediation scanning, internal testing, the compliance evidence package, and the formal compliance declaration.
4. Sustain	Ongoing	The operational program that keeps compliance alive continuously: monitoring, secure updates, key management enforcement, and annual audit.

Each phase produces what the next one needs, and within Phase 2, every track runs in parallel, because different activities have different lead times and the only way to fit everything into the window is to start everything at once.

Phase 1: How do you build the Cryptographic Bill of Materials?

The CBOM is the foundation of everything else. Its completeness determines whether the remediation program is actually comprehensive, or whether it addresses the visible gaps while leaving the invisible ones untouched. The assets that get missed most often are not obscure; they are simply outside the default scope of the tools most organizations reach for first.

• Hardware security modules require direct vendor engagement to confirm whether the specific firmware version currently running holds an active FIPS 140-3 certificate, and whether an upgrade path exists if it does not. This question has the longest downstream consequence, which is why it belongs in Phase 1, not Phase 2.
• TLS endpoint inventory needs to cover east-west traffic between application tiers and databases, not just perimeter services. Internal connections negotiate whatever the application was originally coded to negotiate, and they are consistently where the most significant deprecated-algorithm findings live.
• Certificate Transparency logs are the most underused discovery source available. Every publicly trusted CA must submit every certificate to CT logs, which are publicly queryable. Comparing CT log output for your domains against your certificate management system surfaces every shadow certificate ever issued, all of which are in regulatory scope, whether or not they appear in your managed inventory.
• Cloud KMS configurations require examining endpoint configuration and key tier selection, specifically, not just whether cloud KMS is in use. As Part 2 covered, FIPS compliance in cloud key management depends on configuration choices that are not the default in any major provider.
• SaaS platforms and custom applications require structured vendor questionnaires with direct CMVP certificate verification as the validation step. Self-attestation is not sufficient; ask for specific certificate numbers and verify each at csrc.nist.gov.

Phase 2: What are the six remediation tracks?

This is where the transition actually happens. All six tracks start together in weeks 3 and 4, because that is the only schedule that works within the window.

• Algorithm track (weeks 4–8): Remove Triple-DES, SHA-1, RSA-1024, TLS 1.0, and TLS 1.1 from every active encryption path. Re-issue SHA-1 certificates through the full chain, root to leaf. Test in non-production before cutover: applications with hard-coded algorithm references break when the underlying module switches to FIPS-only operation.
• HSM track (weeks 4–12): For HSMs with firmware upgrade paths, coordinate the upgrade with non-production testing, change management, and post-upgrade verification; budget four to six weeks minimum. For HSMs with no upgrade path, initiate replacement procurement immediately: it is a three-to-six-month process, and if it starts in week 8, it does not finish before September 21.
• FIPS mode activation track (weeks 5–10): Enable FIPS mode on every in-scope module, verify self-tests run correctly, test dependent applications for compatibility, and document the configuration state as compliance evidence. Pushing FIPS mode to production without testing routinely produces compatibility failures that push the whole timeline back.
• Cloud KMS track (weeks 5–9): Migrate to FIPS endpoints on AWS, HSM-backed tiers on Azure, and Cloud HSM key rings on GCP. Map downstream dependencies before the switch and update every application calling standard endpoints. This is a migration with application dependencies, not a settings change.
• Vendor track (weeks 3–12, from day one): Require CMVP certificate numbers from every vendor with in-scope modules and verify each at csrc.nist.gov. For modules in the queue, get expected completion dates and monitor the In-Process list. For vendors who cannot certify before September, make the contingency call early: risk acceptance with compensating controls for low-risk systems, replacement for regulated-data systems.
• Documentation track (weeks 6–12): Update cryptographic policies, Security Policy documents, key management procedures, and operational runbooks as changes are made, not after Phase 2 wraps. Documentation produced during implementation is accurate; documentation produced afterward is reconstructed, and the gaps are shown under examination.

Phase 3: How do you verify and prove compliance?

Remediation and verification are different activities. Changing a configuration is not the same as confirming it produced the intended result. Phase 3 closes that gap and builds the evidence package that makes compliance attestable.

• Post-remediation scanning re-runs discovery across all in-scope systems and confirms deprecated algorithms are absent from every active encryption path and FIPS mode is active on every module. These results are documentary proof that the program achieved its objectives.
• Internal testing confirms self-tests execute at startup and under specified conditions, FIPS mode operates as each module’s Security Policy requires, and modules reject non-approved algorithm requests rather than silently degrading. For hardware modules at Level 3 and above, physical security and sensitive security parameter management verification are also required.
• The compliance evidence package should include CMVP certificate records with Active status confirmed at csrc.nist.gov, configuration exports showing FIPS mode enabled, key ceremony records for CA private keys and master keys, internal test results, vendor documentation, and updated policy documents. This is what a FedRAMP assessment, an OCR audit, a financial examiner review, or a cyber insurance underwriting conversation will ask for.

Phase 4: How do you keep compliance alive?

The organizations that find themselves running this process every few years treat FIPS 140-3 as a project. The organizations that do not treat it as a program. Phase 4 is the difference.

• Certificate monitoring: Track CMVP status for every in-scope vendor module continuously, not at annual review cycles. A module can move from Active to Historical when a version is superseded; a certificate can be revoked when a security issue is discovered. These events do not announce themselves.
• Secure update management: All firmware and software updates to cryptographic modules go through FIPS mode compatibility testing before production. The supply chain scenario, malicious firmware silently compromising a module, is exactly what FIPS 140-3’s software integrity requirements address; verifying updates before applying them is the complementary operational control.
• Key management enforcement: Cryptoperiods, dual control for CA private keys and master keys, HSM-backed key storage, and documented zeroization enforced continuously. Key management practices are the most frequently identified FIPS compliance deficit in production environments, and they drift back after remediation without active enforcement.
• Annual cryptographic audit: A full CBOM review each year that catches gaps introduced by system changes, new vendor products, certificate status changes, and evolving NIST guidance.

The compliance checklist: what does done actually look like?

Before any organization can credibly claim FIPS 140-3 compliance to a regulator, auditor, or insurer, each of the following needs to be verifiably true, confirmed through direct verification rather than assumed from vendor claims or certificate possession alone.

• Active FIPS 140-3 CMVP certificate for every in-scope module, verified at csrc.nist.gov: Active status, correct module version matched to what is deployed, appropriate security level for the use case.
• FIPS mode actively enabled in production, not just FIPS-capable: self-tests running, algorithm restrictions enforced, cryptographic boundary respected per each module’s Security Policy.
• No deprecated algorithms in any active encryption path: no Triple-DES, no SHA-1 in new implementations, no RSA-1024, no TLS 1.0 or 1.1 on any active endpoint.
• Cloud KMS configured correctly: FIPS endpoints for AWS, HSM-backed tiers for Azure, Cloud HSM key rings for GCP, verified through endpoint testing rather than inferred from provider documentation.
• Key management practices satisfying FIPS 140-3: generation within FIPS-validated HSMs, defined cryptoperiods enforced, dual control for CA private keys and master keys, and documented zeroization procedures.
• All vendors verified through direct CMVP verification; certificate numbers confirmed for every in-scope module. Self-attestation is not sufficient.
• Compliance evidence package compiled and retained: CMVP records, configuration exports, key ceremony records, test results, vendor documentation, updated policies.
• Ongoing compliance program operational: certificate monitoring, secure update management, key management enforcement, annual cryptographic audit, and revalidation planning.

Which mistakes derail programs?

• Treating this as a documentation project: FIPS 140-3 compliance requires real engineering work across all eleven security areas. Policy updates and certificate collection consistently leave material gaps unaddressed.
• Starting discovery too late to act on it: HSM replacement, vendor CMVP submissions, and certificate re-issuance all have lead times that urgency cannot compress. The discovery that starts in July does not leave time to act on what it finds.
• Accepting vendor attestation in place of CMVP verification: A vendor who claims FIPS 140-3 compliance without a certificate number is making an unverifiable claim. Require the number; verify it.
• Scoping the assessment around the infrastructure you already know: SaaS platforms, custom applications, and connected devices are the most consistently missed categories. A complete CBOM requires deliberate effort to surface all three.
• Deferring vendor conversations until the internal work is done: Vendor timelines are outside your control. Starting those conversations in parallel with Phase 1 is the only approach that preserves contingency time if the answer turns out to be complicated.

How Encryption Consulting can help

Encryption Consulting’s FIPS 140-3 compliance advisory services deliver the complete program described in this post, from initial cryptographic discovery through compliance attestation, with the focused cryptographic expertise the transition requires. Our consultants bring decades of hands-on experience in PKI architecture, HSM deployment, key management program design, and cryptographic compliance across healthcare, federal, financial, and enterprise environments.

• FIPS 140-3 Compliance Assessment: Full cryptographic discovery producing a complete Cryptographic Bill of Materials, with every gap classified by risk level and every vendor module verified at csrc.nist.gov. Scoped to find what infrastructure assessments miss: SaaS platforms, custom applications, cloud KMS configurations, and connected devices.
• Gap analysis across all eleven security areas: Software integrity, non-invasive security, sensitive security parameter management, lifecycle assurance, and FIPS mode configuration, not just the two areas most assessments check.
• FIPS 140-3 Transition Strategy: A risk-prioritized, sequenced remediation roadmap reflecting the actual constraints in your environment, calibrated to the September 21, 2026, deadline.
• Compliance Advisory and Attestation: Executive-level compliance posture reporting and attestation documentation structured to hold up under regulatory review, FedRAMP assessment, OCR audit, and cyber insurance underwriting.

Frequently asked questions

How long does a FIPS 140-3 transition take?

A structured program runs roughly fourteen to sixteen weeks: two to four weeks of discovery, two to three of gap analysis, and seven to ten of parallel remediation and verification. HSM hardware replacement, where required, extends to three to six months, which is why it starts in Phase 1.

What is a Cryptographic Bill of Materials?

A complete, machine-readable inventory of every cryptographic asset in the environment: keys, certificates, algorithms, protocols, and modules, each with its configuration, FIPS certificate status, and risk classification. It is the foundation every remediation decision builds on.

What evidence should the compliance package contain?

CMVP certificate records with verified Active status, configuration exports proving FIPS mode, key ceremony records, internal test results, vendor documentation, and updated policy documents.

Why do CT logs matter for FIPS compliance?

Certificate Transparency logs record every certificate publicly trusted CAs have ever issued for your domains, including shadow certificates that never entered your management system. All of them are in regulatory scope, and comparing CT output against your inventory is the fastest way to find them.

What happens after September 21, 2026?

FIPS 140-2 certificates are Historical, and compliance frameworks that reference active validation, federal procurement, HIPAA safe harbor expectations, and FedRAMP no longer recognize them. The sustain phase of this framework keeps the new posture current, so the next transition never becomes another emergency.

Conclusion

September 21, 2026, is a fixed date. The four-phase framework in this post is designed to take any organization from an unknown cryptographic posture to defensible, evidence-supported FIPS 140-3 compliance within the roughly fourteen weeks available to organizations starting now. It works when Phase 1 starts immediately, vendor escalation runs from day one, and all six remediation tracks go simultaneously once the gap analysis is complete.

Cryptographic compliance is infrastructure-level security: nobody notices it when it works, and everybody notices it when it fails, in a breach investigation, an OCR audit, a federal contract review, or an underwriting conversation. The SHA-1-to-SHA-256 migration was estimated to take five years and took more than ten. The FIPS 140-3 transition has a deadline; the post-quantum migration does not, and the organizations that treat it as the forcing function it is will be better positioned for everything that follows.

Ready to get started? Contact Encryption Consulting at info@encryptionconsulting.com to book your personalized consultation call. We can have your Cryptographic Bill of Materials and gap analysis ready within four weeks, enough runway for a complete transition program before September 21, 2026.