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

On September 21, 2026, every FIPS 140-2 certificate moves to Historical status in the NIST CMVP database. That single date change does not shut systems down, but it removes the compliance standing that federal procurement, HIPAA safe harbor, FedRAMP authorization, and defense contracts are built on. FIPS 140-3 is the only active standard for new validations. If your cryptographic modules do not hold Active FIPS 140-3 certificates, your transition program needs to be running today.

Quick Answer: What Is FIPS 140-3 and Why Does September 2026 Matter?

FIPS 140-3 is the current NIST standard for cryptographic module security, based on ISO/IEC 19790:2012. It covers eleven security areas, adds a new non-invasive (side-channel) attack security area, and disallows Triple-DES, SHA-1 for signatures, RSA-1024, and MD5. All FIPS 140-2 certificates moved to Historical status on September 21, 2026. Organizations whose compliance depends on validated cryptography must hold Active FIPS 140-3 certificates for every in-scope module. The first action is verifying each module’s exact certificate status in the CMVP database at csrc.nist.gov.

Key Takeaways

• FIPS 140-2 certificates moved to Historical status on September 21, 2026. Nothing stops working that day, but the compliance standing built on those certificates does.
• FIPS 140-3 is not a minor update. It introduces substantive requirements across eight changed domains, including a completely new security area for non-invasive (side-channel) attacks.
• The gap that catches most organizations is not the certificate. It is the difference between FIPS Validated, FIPS Compliant, and FIPS Capable, and most production environments are sitting on the third.
• FIPS 140-3 spans eleven security areas. Most assessments check two: algorithms and certificate status. The other nine are where unexamined exposure lives.
• This affects healthcare, FedRAMP cloud providers, defense contractors, and financial institutions alike: any organization whose legal, contractual, or insurance standing depends on independently validated cryptography.
• The September 21, 2026 deadline has now passed. Organizations still on FIPS 140-2 Historical modules need an active remediation program, not just a plan to start one.

What Is FIPS and Why Has It Always Mattered?

FIPS validation is the independent, third-party verification that a cryptographic module does what it claims. When an organization tells a federal agency, a regulator, or a cyber insurer that its encryption is secure, FIPS is the evidence that supports that claim. Without it, the organization is asking stakeholders to take its word for it, and regulators, auditors, and underwriters increasingly will not.

The Federal Information Processing Standards (FIPS) were created by NIST under the Federal Information Security Management Act (FISMA). They are mandatory for every U.S. federal agency and for any organization that handles federal information. In practice this includes healthcare organizations operating under Medicare and Medicaid, defense contractors, cloud platforms with FedRAMP authorization, and financial institutions subject to federal oversight.

The FIPS 140 series specifically governs cryptographic modules: the hardware, software, and firmware that perform encryption, key generation, hashing, and digital signatures. Every time patient data is encrypted at rest, a VPN tunnel is established, an HSM protects a private key, or a certificate is signed, a cryptographic module is doing that work. FIPS validation is the proof that it is doing it correctly.

FIPS 140-2, issued in 2001, became the global benchmark. For over two decades, it was the answer every auditor eventually asked for. On September 21, 2026, all remaining FIPS 140-2 certificates moved to Historical status. That answer no longer works.

What Happened on September 21, 2026?

Every certificate issued under FIPS 140-2 moved to Historical status in the NIST Cryptographic Module Validation Program (CMVP) database. Historical does not mean revoked or deleted. It means the certificate is no longer valid for new federal procurement, no longer satisfies HIPAA technical safeguard expectations built on current NIST standards, and no longer supports FedRAMP authorization or the breach notification safe harbor.

The lights do not go off. But compliance standing does, in ways that become visible only when a regulator, auditor, or underwriter asks a question the organization cannot answer. The key dates in context:

• September 22, 2019: FIPS 140-3 approved and published by NIST.
• September 22, 2021: NIST stopped accepting new FIPS 140-2 module submissions to CMVP. All new submissions from this date forward target FIPS 140-3.
• September 21, 2026: All remaining FIPS 140-2 certificates moved to Historical status. This date has now passed.
• Now: Organizations holding FIPS 140-2 Historical modules need Active FIPS 140-3 certificates for every module in scope. This is not a future planning item; it is a current compliance gap.

What Actually Changed in FIPS 140-3?

FIPS 140-3 is not a minor update with a few new checkboxes. Published in 2019 and aligned with international standards for the first time, it introduces substantive requirements across eight domains where FIPS 140-2 was either silent or inadequate. Organizations that assumed the transition was administrative have consistently discovered it is operational.

What changed	What FIPS 140-3 now requires	Operational implication
Non-invasive security	Completely new security area. Formal mitigation testing for side-channel attacks including power analysis, electromagnetic analysis, and timing analysis at Level 3 and above. FIPS 140-2 never addressed this attack class.	HSM vendors must demonstrate hardening against physical attack classes that many older products were never designed to address. Existing hardware may require replacement.
Software and firmware integrity	Strengthened. From Level 2 upward, modules must verify the integrity of their own code using an approved digital signature or HMAC-based test. FIPS 140-2 accepted weaker error-detection checks.	A malicious firmware update can silently compromise a cryptographic module’s behavior without changing its external interface. FIPS 140-3 requires modules to verify themselves against that scenario. Unverified firmware updates are a direct compliance gap.
Algorithm standards	Triple-DES, SHA-1 (for digital signatures), RSA-1024, and MD5 are disallowed. Not restricted; prohibited. TLS 1.0 and 1.1 are incompatible with the new requirements.	Legacy algorithm usage across applications, TLS endpoints, and certificate chains must be identified and remediated before FIPS 140-3 modules can operate in FIPS-approved mode.
Key management	At Level 3, keys must enter and leave the module only in encrypted form, through a trusted channel, or via split-knowledge procedures. Informal practices that passed FIPS 140-2 reviews will not pass FIPS 140-3.	Key import and export procedures must be formally documented and operationally enforced. Key custodian processes that were informal under FIPS 140-2 need redesign.
Authentication	Multi-factor identity-based authentication is mandatory at Level 4. This is an operational change, not a paperwork one.	Level 4 deployments must implement MFA for module access. Organizations that deployed Level 4 hardware under FIPS 140-2 without MFA need to update access procedures.
Lifecycle assurance	Automated configuration management at Levels 3 and 4, detailed design documentation, low-level testing, and operator authentication for delivery.	Vendor delivery procedures and configuration management automation must be verified as part of the FIPS 140-3 assessment. This requires active engagement with the module vendor, not just a certificate check.
Standards alignment	Aligned with ISO/IEC 19790:2012 for the first time, enabling global interoperability. FIPS 140-2 was a U.S. and Canadian government standard with no international alignment.	Organizations operating internationally can now reference a single validated standard that satisfies both NIST and international requirements. This simplifies multi-jurisdictional compliance documentation.
Testing methodology	Systematic and objective, aligned with ISO/IEC 24759. Results are more consistent and reproducible than the manual process FIPS 140-2 relied on.	FIPS 140-3 validation results are more reliable and internationally recognized. Testing labs can produce results that satisfy both U.S. and international regulatory expectations.

FIPS Validated vs. FIPS Compliant vs. FIPS Capable: Which One Actually Protects You?

There is a critical language problem that is responsible for most of the false confidence organizations carry into their first FIPS gap assessment. These three terms are used interchangeably in vendor marketing, but they describe fundamentally different states:

Term	What it actually means	What auditors and regulators accept	Where this shows up in practice
FIPS Validated	A NIST-accredited laboratory independently tested the specific module version. NIST issued an Active certificate verifiable at csrc.nist.gov. The certificate number is real and publicly verifiable.	Yes. This is what federal procurement, HIPAA, FedRAMP, and CMMC require.	HSMs with Active FIPS 140-3 CMVP certificates; validated cryptographic libraries with confirmed Active status for the exact deployed version.
FIPS Compliant	A vendor self-declaration that the product adheres to FIPS standards. No laboratory, no certificate, no external check. May or may not be accurate; cannot be independently verified.	No. Auditors cannot verify a self-declaration the way they can verify a CMVP certificate number.	Vendor product pages and sales collateral; software libraries claiming FIPS alignment without CMVP certificates; internal security documentation that references vendor claims.
FIPS Capable	The product contains a FIPS-validated module that can operate in FIPS 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.	The most common gap in production environments. A product ships with FIPS mode disabled by default. The team enables the product without enabling FIPS mode. Standard security audits rarely catch this because they verify certificate existence, not configuration state.

The practical rule: always request the CMVP certificate number and verify it at csrc.nist.gov. Confirm Active status (not Historical), the exact module version deployed matches the version on the certificate, and the security level is appropriate for the use case. Then confirm the module is running in FIPS-approved mode in the actual production configuration. Five minutes per module. It is the single most effective gap-closing action before an assessment.

What Are the Four FIPS 140-3 Security Levels and Which One Do You Need?

FIPS 140-3 defines four security levels. Getting the right level for each use case matters: a Level 2 module protecting data that requires Level 3 assurance is a risk management gap, not a compliance box checked. The certificate is technically Active, but what was independently tested does not match what the deployment demands.

Level	Physical security requirements	Authentication requirements	Where it belongs	Typical use cases
Level 1	None. Software-only cryptography is acceptable.	At least one authentication mechanism for each operator role.	Lower-risk applications in environments where physical access is controlled by other means.	Software encryption libraries, application-level cryptography, developer tooling.
Level 2	Tamper-evident coatings or seals; pick-resistant locks on doors of enclosures.	Role-based or identity-based operator authentication.	The practical baseline for most commercial HSMs and enterprise security products. Sufficient for most federal agency use cases and FedRAMP environments.	Enterprise HSMs, network-attached cryptographic appliances, general-purpose key management systems.
Level 3	Tamper-resistant hardware with detection and response: keys zeroed when penetration is detected. Environmental failure testing.	Identity-based authentication. Keys enter and leave only in encrypted form, through a trusted channel, or via split-knowledge procedures.	High-value key material and payment processing environments. Required when the module protects CA private keys or long-lived master encryption keys.	Root CA and issuing CA HSMs, payment processing HSMs, long-term key escrow systems.
Level 4	Complete tamper-detection envelope protecting against penetration from any direction; environmental failure protection against voltage and temperature attacks; fault-injection attack mitigation.	Multi-factor identity-based authentication.	The most sensitive key material in the highest-stakes environments. Rare outside intelligence community and specialized defense applications.	Classified-adjacent key management, ruggedized HSMs for hostile physical environments, top-secret cryptographic systems.

Most organizations have never formally assigned target security levels to their cryptographic module categories. That is not a documentation gap. It means there is no defined basis for knowing whether deployed modules provide the right level of assurance for the data they protect. A security level assignment for each module category is a required output of any complete FIPS 140-3 gap assessment.

What Are the Eleven FIPS 140-3 Security Areas and Why Do Most Assessments Miss Nine of Them?

FIPS 140-3 organizes all requirements across eleven distinct security areas. Most compliance assessments cover algorithm compliance and certificate status. That is two out of eleven. An assessment that stops there is not a FIPS 140-3 gap analysis; it is an algorithm audit with a certificate check added on, and it leaves nine areas of potential exposure unexamined.

Security area	Key requirements	New or changed in FIPS 140-3	Most common gap
1. Cryptographic module specification	Module boundary definition, approved algorithms, security policy documentation	Stricter documentation requirements aligned with ISO/IEC 19790	Security policy documents not updated after firmware changes or algorithm updates
2. Module interfaces	Defined data input/output, control input/output, and power ports	Tighter interface specification aligned with international standard	Undocumented interfaces in software modules; virtual module boundary confusion in cloud deployments
3. Roles, services, and authentication	Operator roles defined, authentication mechanisms per role, identity-based auth at Level 3+	Multi-factor authentication mandatory at Level 4; stronger identity requirements at Level 3	Shared administrative credentials; no formal role documentation; no MFA on Level 4 deployments
4. Software and firmware security	Integrity verification using approved digital signature or HMAC from Level 2 upward	Strengthened significantly from FIPS 140-2’s weaker error-detection checks	Firmware updates applied without cryptographic integrity verification; no vendor-provided firmware signature verification procedure
5. Operational environment	Operating system requirements for software modules; protection of sensitive security parameters	Updated for modern OS environments	Validated software modules running on non-approved OS configurations
6. Physical security	Tamper-evidence at Level 2; tamper-resistance with zeroization at Level 3; complete envelope at Level 4	Modernized physical security mechanisms; improved response requirements	Tamper-evident seals not inspected periodically; no documented seal inspection procedure
7. Non-invasive security	Mitigation testing for side-channel attacks: power analysis (SPA/DPA), electromagnetic analysis, timing analysis at Level 3 and above	Completely new in FIPS 140-3. FIPS 140-2 never addressed this attack class.	HSMs at Level 3 deployed without vendor confirmation that non-invasive security area is certified. Many older HSMs were never tested for this area.
8. Sensitive security parameter management	Key generation, establishment, distribution, storage, entry/output, zeroization per NIST SP 800-57	Stricter key entry/exit requirements at Level 3: encrypted form, trusted channel, or split-knowledge only	Informal key import procedures; plaintext key entry without trusted channel at Level 3 deployments
9. Self-tests	Power-on self-tests, conditional self-tests, and periodic self-tests for critical functions	More comprehensive self-test requirements aligned with ISO/IEC 24759	Self-tests disabled in FIPS Capable deployments; no monitoring of self-test failure events
10. Life cycle assurance	Configuration management, design documentation, low-level testing, delivery procedures, guidance documentation	Automated configuration management required at Levels 3 and 4; documented delivery and installation procedures	No automated configuration management; vendor delivery procedures not documented or verified
11. Mitigation of other attacks	Documentation of attacks considered and mitigations implemented or explicitly excluded	Formal documentation requirement; aligns with international standards	No documentation of attack mitigation decisions; vendors unable to provide this documentation for older products

Security area 7 (non-invasive security) deserves particular attention. For organizations with HSMs operating at Level 3 and above, this area alone requires direct vendor engagement to confirm that deployed hardware has been tested and certified for non-invasive attack mitigation. Many HSMs that were FIPS 140-2 Level 3 certified were simply never tested for this area, because it did not exist as a requirement. Those devices need to be assessed against FIPS 140-3 non-invasive security requirements before they can be relied upon for Level 3 compliance.

FIPS 140-3 Requirements: Controls, Owners, Evidence Artifacts, and Implementation Steps

The following table maps the primary FIPS 140-3 compliance requirements to the controls, evidence artifacts, owners, and implementation steps that security and compliance teams need to produce. This is the operational translation of the standard for organizations building or auditing their FIPS 140-3 compliance program:

Requirement	Control	Evidence artifact	Owner	Implementation step
Active FIPS 140-3 certificate for all in-scope modules	Cryptographic module inventory with CMVP certificate verification	CMVP database query results showing Active status for each module version; module inventory spreadsheet with certificate numbers and verification dates	Security Engineering / Compliance	1. List all cryptographic modules in scope. 2. Search CMVP at csrc.nist.gov for each module. 3. Record certificate number, status (Active/Historical), and exact version covered. 4. Flag any Historical or missing certificates for replacement procurement.
FIPS-approved mode enabled on all validated modules	Configuration documentation showing FIPS mode is active in production	Runtime FIPS mode verification logs; configuration management records; startup configuration files showing FIPS flag enabled	Security Engineering	1. For each validated module, obtain the vendor’s FIPS-approved mode enablement procedure from the Security Policy document. 2. Enable FIPS mode in production configuration. 3. Capture runtime log evidence confirming FIPS mode is active. 4. Include in annual configuration review.
No disallowed algorithms in use (Triple-DES, SHA-1 for signatures, RSA-1024, MD5, TLS 1.0/1.1)	Cryptographic algorithm scan across all in-scope applications and TLS endpoints	Algorithm scan output showing no prohibited algorithm usage; before-and-after scan results confirming remediation	Security Engineering / Application Teams	1. Run cryptographic discovery tool across all applications, TLS endpoints, and key management systems. 2. Identify any usage of prohibited algorithms. 3. Remediate by updating configurations, replacing libraries, or re-keying with approved algorithms. 4. Re-scan to confirm no prohibited algorithms remain.
Software and firmware integrity verification (Level 2+)	Procedure for verifying firmware update integrity before application	Vendor firmware signature verification procedure; log records of integrity checks performed before each firmware update	Security Engineering / HSM Operations	1. Request from each HSM/module vendor their procedure for cryptographic firmware signature verification. 2. Document the procedure in the organization’s change management process. 3. Require cryptographic integrity verification before every firmware update. 4. Log each verification with timestamp and result.
Key management aligned with NIST SP 800-57 (generation, distribution, storage, rotation, destruction)	Formal key management policy; key lifecycle records	Key management policy document; HSM audit logs showing key generation within validated module; key rotation schedule and execution records; key destruction records	Key Management / Security Engineering	1. Document key management policy covering all lifecycle phases. 2. Verify keys are generated using SP 800-90 compliant DRBG within a validated module. 3. For Level 3 deployments, verify key import/export uses encrypted form or trusted channel only. 4. Implement role separation for key management functions. 5. Capture audit log evidence for each lifecycle event.
Security level assignment for each module category	Documented security level decision for each cryptographic module use case	Security level assignment document with rationale; mapping of use case to level requirements	Security Architecture / Compliance	1. For each category of cryptographic module in scope, document the data sensitivity and threat model. 2. Map to the appropriate FIPS 140-3 security level. 3. Verify that deployed modules are certified at or above the assigned level. 4. Document any gaps between required level and current module level as remediation items.
Physical security appropriate to security level (Level 2: tamper-evident; Level 3: tamper-resistant with zeroization)	Physical security inspection records and seal verification procedures	Physical inspection records with dates; photographs of tamper-evident seals; documented seal inspection schedule; Level 3 zeroization test documentation	Facilities / Security Engineering	1. Establish periodic physical inspection schedule for all hardware modules. 2. Document seal inspection procedure. 3. Photograph and record seal status at each inspection. 4. For Level 3 hardware, verify zeroization response is functional per vendor procedure. 5. Retain inspection records for audit evidence.
Vendor non-invasive security certification for Level 3+ HSMs	Written confirmation from HSM vendor that non-invasive security area (Security Area 7) is covered in FIPS 140-3 certificate	Vendor written confirmation; CMVP certificate or Security Policy document confirming non-invasive security area coverage	Security Engineering / Procurement	1. For each Level 3+ HSM, contact the vendor and request confirmation that Security Area 7 (non-invasive security) is covered in the FIPS 140-3 CMVP certificate. 2. Review the module’s CMVP Security Policy document to confirm non-invasive security testing was performed. 3. If not covered, escalate as a critical gap requiring hardware replacement.
Complete documentation set for FedRAMP / CMMC / HIPAA audit	System Security Plan (SSP) with cryptographic module section; annual review records	SSP section identifying all modules, certificate numbers, security levels, and approved modes; annual compliance review records; CBOM export	Compliance / Security Architecture	1. Create or update SSP cryptographic module section with all required fields. 2. Conduct annual review of CMVP certificate status for all modules. 3. Update SSP when new modules are added or existing modules are updated. 4. Maintain CBOM as a living document updated quarterly.

FIPS 140-3 Audit-Ready Checklist

Use this checklist to verify your FIPS 140-3 compliance posture before a FedRAMP assessment, CMMC evaluation, HIPAA audit, or internal review. Each item maps to the requirements table above:

Control area	Requirement	Evidence artifact	Owner	Status
Module inventory	All cryptographic modules in scope inventoried with CMVP certificate numbers	Module inventory with certificate numbers and verification dates	Security Engineering	To action
Certificate status	All modules verified as Active FIPS 140-3 in CMVP database; no Historical or Revoked certificates relied upon	CMVP database query results per module	Compliance / Security Engineering	To action
Version alignment	Deployed module version matches the version covered by the CMVP certificate	Module version documentation; Security Policy review	Security Engineering	To action
FIPS-approved mode	All validated modules confirmed operating in FIPS-approved mode in production configuration	Runtime FIPS mode logs; configuration documentation	Security Engineering	To action
Algorithm compliance	No prohibited algorithms in use: no Triple-DES, SHA-1 for signatures, RSA-1024, MD5, TLS 1.0, TLS 1.1	Cryptographic algorithm scan results; TLS endpoint scan output	Security Engineering	To action
Security level assignment	Target security level documented for each module category with rationale	Security level assignment document	Security Architecture	To action
Firmware integrity	Procedure in place for cryptographic verification of firmware updates before application	Firmware verification procedure; log records of verifications performed	HSM Operations	To action
Non-invasive security (Level 3+)	Vendor confirmation that non-invasive security area is covered in FIPS 140-3 certificate for all Level 3+ HSMs	Vendor written confirmation; CMVP Security Policy document	Security Engineering	To action
Key generation	Keys generated using SP 800-90 compliant DRBG within a validated module	HSM configuration; key generation audit logs	Key Management	To action
Key import/export (Level 3)	Keys enter and leave Level 3 modules only in encrypted form, through trusted channel, or via split-knowledge procedures	Key management procedure documentation; audit log evidence	Key Management	To action
Role separation	Key management roles separated: generation, distribution, and destruction assigned to distinct roles	RACI matrix; access control configuration	Security Architecture	To action
Physical security	Tamper-evident seals present and inspected periodically at Level 2; tamper-resistant mechanisms at Level 3	Physical inspection records; seal photographs; inspection schedule	Facilities / Security Engineering	To action
Self-test monitoring	FIPS self-tests enabled; self-test failure events monitored and alerted	Monitoring configuration; self-test log evidence	Security Operations	To action
SSP documentation	System Security Plan identifies all modules, certificate numbers, security levels, and approved modes of operation	SSP or equivalent security documentation	Compliance	To action
Annual review	Annual re-verification of CMVP certificate status; configuration review; inventory update for any new modules	Annual review records with date; updated inventory	Compliance	To action
PQC migration readiness	Cryptographic inventory identifies all RSA and ECC usage; HSM vendor confirmation of PQC firmware update support; migration roadmap exists	CBOM or cryptographic inventory; vendor PQC roadmap; migration plan	Security Architecture	To action

Which Organizations Does FIPS 140-3 Affect?

The temptation is to frame this as a federal agency problem or a healthcare problem. It is neither exclusively. It affects any organization whose regulatory standing, contractual obligations, or insurance coverage depends on independently validated cryptographic modules.

Organization type	FIPS 140-3 obligation	Consequence of relying on Historical FIPS 140-2 modules
U.S. federal agencies	Mandatory under FISMA and OMB Circular A-130	Non-compliant federal information systems; potential audit finding; inability to procure new modules on Historical certificates
Healthcare covered entities and business associates	HIPAA breach notification safe harbor assumes NIST-standard encryption; FIPS 140-2 Historical modules no longer satisfy that assumption	Loss of breach notification safe harbor; full breach cost exposure. Average healthcare breach cost is approximately USD 10 million.
FedRAMP-authorized cloud providers	Active FIPS-validated modules required for Authorization to Operate (ATO)	ATO standing directly jeopardized; FedRAMP re-authorization may be required
Defense contractors (CMMC Level 2 and above)	FIPS-validated cryptography required for CUI protection under NIST SP 800-171 Rev. 2 SC.L2-3.13.11; new procurement cycles require Active FIPS 140-3 certificates	CMMC assessment finding; inability to satisfy contract cryptography requirements; loss of competitive standing for new contracts
Financial institutions	Federal examiners increasingly reference current NIST cryptographic standards; PCI DSS v4.0 requires strong cryptography consistent with NIST guidance	Examination finding; PCI DSS compliance gap; increased scrutiny on subsequent examinations
Cyber insurance policyholders	Many policies require NIST-standard encryption as a condition of coverage or for breach coverage claims	Coverage denial or reduced payout if historical modules were relied upon at time of breach

Where Should You Start Your FIPS 140-3 Transition?

The September 21, 2026 deadline has passed. Organizations still holding FIPS 140-2 Historical modules need to move from planning to execution. The sequence below reflects what consistently separates organizations that close their gaps efficiently from those that discover them during an audit:

1. Start with your HSMs: Ask your HSM vendor one specific question: does the firmware version currently running in production hold an Active FIPS 140-3 CMVP certificate? If the answer is no or uncertain, this conversation needs to happen immediately. HSM hardware replacement, when required, takes three to six months minimum and depends on vendor availability.
2. Build a complete cryptographic module inventory: Identify every cryptographic module across your environment: HSMs, TLS libraries, OS-level cryptographic providers, VPN clients, disk encryption, cloud KMS services, and application-level cryptography. For each, record the vendor, product name, exact version, and CMVP certificate number. A CBOM Secure engagement automates this discovery across cloud and on-premises environments and produces a Cryptographic Bill of Materials that auditors can review directly.
3. Verify FIPS-approved mode, not just certificate existence: For every validated module in scope, confirm that FIPS mode is actively enabled in the production configuration, not just that the product holds a certificate. This is where most production compliance exposure lives, and it is the gap that standard security audits most consistently miss.
4. Run an algorithm scan across all applications and TLS endpoints: Identify any usage of prohibited algorithms (Triple-DES, SHA-1 for signatures, RSA-1024, MD5, TLS 1.0/1.1) before your FIPS 140-3 modules can operate in FIPS-approved mode. Legacy algorithm usage in applications will prevent FIPS-approved mode from functioning correctly even on fully validated hardware.
5. Engage vendors on non-invasive security coverage for Level 3+ HSMs: For every HSM operating at Level 3 or above, request written vendor confirmation that Security Area 7 (non-invasive security) is covered in the FIPS 140-3 CMVP certificate. This is the most commonly missed area in Level 3 deployments and the one most likely to result in a critical finding during a formal assessment.
6. Make CMVP verification a standard vendor onboarding and annual review step: Require CMVP certificate numbers from every vendor with in-scope modules and verify each one at csrc.nist.gov. Build this into vendor onboarding checklists and annual review processes so version drift does not create a compliance gap between reviews.

How Encryption Consulting Can Help With FIPS 140-3 Transition

Encryption Consulting is an ISO/IEC 27001:2022 and SOC 2 certified applied-cryptography firm with deep, focused expertise in FIPS 140-3, PKI, HSM deployment, key management, and data protection across healthcare, federal, financial, and enterprise environments. Our FIPS 140-3 compliance advisory services are built to close gaps before they become audit findings.

• FIPS 140-3 Compliance Assessment: Comprehensive cryptographic discovery across your full environment including HSMs, TLS endpoints, cloud KMS configurations, PKI infrastructure, SaaS platforms, and custom applications. We produce a Cryptographic Bill of Materials (CBOM) with every gap classified by risk level and every vendor module status verified directly at csrc.nist.gov. Coverage across all eleven security areas, not just algorithms and certificate status.
• Gap Analysis Across All Eleven Security Areas: Software integrity, non-invasive security, sensitive security parameter management, lifecycle assurance, and FIPS mode configuration, covering the nine areas that most assessments skip. This is where the evidence packages that FedRAMP 3PAOs, CMMC C3PAOs, and HIPAA auditors need to see are built.
• FIPS 140-3 Transition Strategy: A prioritized, sequenced remediation roadmap with realistic timelines that account for HSM lead times, CMVP queue backlogs, vendor dependencies, and cloud reconfiguration cycles. 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.
• PQC Readiness: FIPS 140-3 transition and post-quantum migration are converging timelines. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 targets RSA and ECC deprecation around 2030. Our PQC Readiness service and PQC Center of Excellence assess which HSMs support PQC firmware updates versus requiring replacement, so organizations do not solve the FIPS 140-3 gap with hardware that immediately needs replacing for PQC.

Conclusion

The FIPS 140-3 transition is no longer a future deadline. September 21, 2026 has passed, and all FIPS 140-2 certificates are now Historical. The compliance standing built on those certificates is gone. The transition introduces new requirements across eleven security areas, disallows algorithms that are widespread in legacy environments, and requires compliance to be demonstrated at the module level in ways that simply holding a certificate does not satisfy.

The SHA-1-to-SHA-256 migration was estimated to take five years; it took more than ten. The FIPS 140-3 transition has a fixed date that has now arrived. Organizations starting their assessment programs now face compressed timelines for procurement, vendor engagement, and CMVP queue management. Part 2 of this series covers the eight challenges that consistently derail FIPS 140-3 transition programs. Part 3 is the step-by-step playbook for organizations executing their transition now.

Frequently Asked Questions

When did FIPS 140-2 certificates expire?

All FIPS 140-2 certificates moved to Historical status on September 21, 2026. They are no longer valid for new federal procurement or compliance frameworks that reference active CMVP validation. This date has now passed. Organizations still relying on FIPS 140-2 Historical modules have a current compliance gap, not an upcoming deadline.

What does FIPS 140-2 Historical status actually mean?

The certificate remains in the CMVP database but is no longer valid for new procurement or current compliance reliance. Existing deployments do not stop working; the independent assurance behind them stops counting. Regulators, auditors, and underwriters who verify the certificate will find a Historical record, and that distinction has direct consequences for HIPAA safe harbor, FedRAMP ATO, and defense contract compliance.

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

FIPS 140-3 is based on ISO/IEC 19790:2012 and ISO/IEC 24759, where FIPS 140-2 was a standalone U.S./Canadian standard. FIPS 140-3 adds an entirely new security area for non-invasive attacks, makes software and firmware integrity verification mandatory from Level 2, tightens key management and authentication requirements at Level 3 and Level 4, and disallows legacy algorithms including Triple-DES, SHA-1 for digital signatures, RSA-1024, and MD5. See our comprehensive guide to FIPS compliance for the full comparison.

What is the difference between FIPS Validated, FIPS Compliant, and FIPS Capable?

FIPS Validated means independently tested by a NIST-accredited laboratory with an Active CMVP certificate verifiable at csrc.nist.gov. FIPS Compliant is an unverifiable vendor self-declaration with no laboratory test and no certificate. FIPS Capable means the product has a validated module that can run in FIPS mode but is currently running in a non-FIPS default configuration. Only FIPS Validated satisfies federal procurement, HIPAA expectations, and FedRAMP. FIPS Capable is the most common production gap and the hardest to detect without a dedicated configuration review.

Is FIPS 140-3 mandatory for private companies?

FIPS 140-3 is directly mandatory for U.S. federal agencies. In practice, it binds any organization handling federal information or relying on frameworks that reference it: HIPAA safe harbor, FedRAMP, defense contracts, CMMC Level 2 and above, and increasingly, financial examination standards. Private sector organizations with no federal exposure are not legally required to comply, but FIPS 140-3 validation is the benchmark for independent cryptographic assurance that underwriters, enterprise customers, and sophisticated auditors increasingly expect.

Does using a major cloud provider make an organization FIPS 140-3 compliant?

Not automatically. Cloud providers offer FIPS 140-3 validated cryptography as a configuration option, not a default. Achieving FIPS compliance in cloud environments requires specifically selecting FIPS endpoints, HSM-backed key storage tiers, and Cloud HSM key rings. Organizations must also verify which exact module version the cloud provider’s FIPS service uses, confirm that version’s Active CMVP certificate, and document that workloads are using the FIPS service rather than a non-FIPS default. Responsibility for correct configuration rests with the cloud customer.

How long does FIPS 140-3 validation take?

FIPS 140-3 validation typically takes 6 to 24 months from submission to certificate issuance. Testing is conducted by a NIST-accredited Cryptographic Security Testing Laboratory (CSTL), followed by CMVP review. For organizations whose modules do not yet have Active FIPS 140-3 certificates, this timeline means immediate action is needed to avoid extended compliance gaps while waiting for vendor validation programs to complete.

What are the eleven FIPS 140-3 security areas?

FIPS 140-3 covers eleven security areas: (1) cryptographic module specification, (2) module interfaces, (3) roles, services, and authentication, (4) software and firmware security, (5) operational environment, (6) physical security, (7) non-invasive security (new in FIPS 140-3), (8) sensitive security parameter management, (9) self-tests, (10) life cycle assurance, and (11) mitigation of other attacks. Most gap assessments only cover areas 1 and certificate status, leaving nine areas of potential exposure unexamined.