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

Quick answer: On September 21, 2026, NIST retires FIPS 140-2. Every certificate issued under it moves to Historical status and stops meeting federal procurement, HIPAA technical safeguard expectations, FedRAMP authorization, and the breach notification safe harbor. FIPS 140-3 is the replacement: aligned with ISO/IEC 19790, organized across eleven security areas, and stricter on algorithms, key management, and software integrity. Any organization whose compliance standing depends on validated cryptography needs an active transition program now.

Key Takeaways

• FIPS 140-2 certificates move 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.

What Is FIPS, And Why Has It Always Mattered?

Think of FIPS validation as the gold standard for cryptographic trustworthiness. When an organization tells a federal agency, a regulator, or a cyber insurer that its encryption is secure, FIPS is the independent, third-party verification that supports that claim. Without it, you are asking people to take your word for it.

The Federal Information Processing Standards were created by NIST under the Federal Information Security Management Act. They are mandatory for every U.S. federal agency and for any organization that touches federal information, which in practice 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 actually 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. After September 21, 2026, that answer no longer works.

What’s Going To Happen On September 21, 2026?

Every certificate issued under FIPS 140-2 moves 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 your compliance standing does, in ways that become visible only when a regulator, auditor, or underwriter asks a question you cannot answer.

What Actually Changed in FIPS 140-3?

If you have been putting off this conversation because you assumed FIPS 140-3 was a minor update with a few new boxes to check, the comparison below will be useful. It is not. Published in 2019 and aligned with international standards for the first time, it introduces substantive requirements across eight domains where the old standard was either silent or inadequate.

What changed	What FIPS 140-3 now requires
Non-invasive security	Completely new. Formal mitigation testing for side-channel attack classes, including power analysis, electromagnetic analysis, and timing analysis, at Level 3 and above. FIPS 140-2 never addressed this attack class.
Software/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.
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.
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.
Authentication	Multi-factor identity-based authentication is mandatory at Level 4. This is an operational change, not a paperwork one.
Lifecycle assurance	Automated configuration management at Levels 3 and 4, detailed design documentation, low-level testing, and operator authentication for delivery.
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.
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.

Several of these changes have direct operational consequences. Non-invasive security testing requires HSM vendors to demonstrate hardening against physical attack classes that many older products were never designed to address. The software integrity requirement closes a meaningful supply chain gap: a malicious firmware update can silently compromise a cryptographic module’s behavior without changing its external interface, and FIPS 140-3 now requires modules to verify themselves against that scenario.

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

There is a critical language problem worth addressing directly, because it is responsible for most of the false confidence organizations carry into their first FIPS gap assessment.

FIPS Validated means a NIST-accredited independent laboratory has tested the specific module and NIST has issued an active certificate. The certificate number is real; it is in the CMVP database at csrc.nist.gov, and anyone can verify it. This is what federal procurement, HIPAA, and FedRAMP require.

FIPS Compliant is a self-declaration. A vendor says they adhere to FIPS standards. No laboratory, no certificate, no external check. It may be accurate, but you cannot independently confirm it the way you can confirm a certificate number.

FIPS Capable means the product has a FIPS-validated module that can run 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. This is the most common gap in production environments, and it is invisible to standard security audits.

The practical rule: always ask for the CMVP certificate number and verify it at csrc.nist.gov. Confirm Active status, the exact module version deployed, and the security level. Five minutes per module. It is the single most effective thing you can do to close the most common category of compliance gap before it becomes your problem.

What Are the Four Security Levels, And Which One Do You Need?

FIPS 140-3 defines four security levels, and getting the right one for each use case matters. Deploying a Level 2 module in a context that calls for Level 3 is a risk management gap: the certificate is technically active, but what was independently tested does not match what the situation demands.

Level	What it requires	Where it belongs
Level 1	Software-based cryptography with no physical security requirements.	Lower-risk applications in environments where physical access is controlled by other means.
Level 2	Tamper-evident coatings or seals; role-based or identity-based operator authentication.	The practical baseline for most commercial HSMs and enterprise security products.
Level 3	Physical tamper-resistance with detection and response; keys enter and leave only in encrypted form; identity-based authentication; environmental failure testing.	CA private keys, master encryption keys, and payment HSMs.
Level 4	Complete tamper detection envelope, environmental failure protection, fault-injection mitigation, and mandatory multi-factor identity-based authentication.	The most sensitive key material in the highest-stakes environments.

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.

What Are the Eleven Security Areas, And Why Do Most Assessments Miss Nine Of Them?

FIPS 140-3 organizes its 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 bolted on.

The eleven areas are: cryptographic module specification, module interfaces (ports and interfaces), roles and authentication, software and firmware security, the operational environment, physical security, non-invasive security, sensitive security parameter management, self-tests, lifecycle assurance, and mitigation of other attacks.

Non-invasive security is brand new in FIPS 140-3. For organizations with HSMs operating at Level 3 and above, this area alone requires specific vendor engagement to confirm that deployed hardware satisfies the mitigation requirements.

Software and firmware security was strengthened: from Level 2 upward, integrity must be verified with an approved digital signature or HMAC-based test, not the weaker checks FIPS 140-2 accepted. If your vendor shipped a firmware update to your HSM last year and you applied it without verifying cryptographic integrity, that is exactly the scenario this requirement exists to prevent.

Lifecycle assurance now demands automated configuration management at Level 3 and above, detailed design documentation, low-level testing, and documented delivery procedures. The scope is broader than most teams realize until they try to assess it.

The remaining areas each carry their own requirements. An assessment that does not cover all eleven does not produce a complete picture, and a remediation program built on an incomplete picture leaves the organization exposed in precisely the areas nobody checked.

Who Are Impacted?

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

Healthcare covered entities and business associates protect the most valuable personal data in existence; stolen healthcare records reportedly sell for hundreds of dollars each on dark-web markets. The HIPAA breach notification safe harbor protects organizations when properly encrypted data is compromised, but that protection assumes NIST-standard encryption. After September 21, FIPS 140-2 Historical modules no longer satisfy it, and with the average healthcare breach now costing around ten million dollars, losing the safe harbor means bearing it all.

Cloud providers with FedRAMP authorization depend on active FIPS-validated modules for their Authorization to Operate. A FedRAMP environment is only as strong as its weakest cryptographic link, and Historical-status modules directly jeopardize ATO standing.

Defense contractors whose federal contracts specify FIPS-validated controls must show active FIPS 140-3 certificates in new procurement cycles. Historical-status FIPS 140-2 certificates do not satisfy that requirement. This is a market access problem, not just a compliance one.

Financial institutions face federal examiners who increasingly reference current NIST cryptographic standards. An institution that cannot demonstrate an active FIPS 140-3 certificate status is entering those examinations with a known vulnerability.

Where Should You Start?

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, that conversation needs to happen today. HSM hardware replacement, when required, takes three to six months.

Verify FIPS mode, not just certificates. For every cryptographic module you depend on, confirm that FIPS mode is actively enabled in the production configuration, not just that the product holds a certificate. These are different states, and the gap between them is where most compliance exposure actually lives.

Make direct CMVP verification standard practice. Require certificate numbers from every vendor with in-scope modules and verify each one at csrc.nist.gov. Build this into vendor onboarding and annual reviews as a default step.

Start vendor conversations now. If any vendor-supplied component depends on cryptographic hardware or software whose FIPS 140-3 roadmap has not been formally communicated, that conversation needs to begin today. Vendor timelines are entirely outside your control; the only variable you can influence is when you start engaging.

How Encryption Consulting Can Help

Understanding what the standard requires is the first step. Having the right advisory partner to execute the transition before September 21, 2026, is the second, and that is exactly what Encryption Consulting’s FIPS 140-3 compliance advisory services are built for. We work exclusively in cryptographic security: deep, focused expertise in FIPS 140-3, PKI, HSM deployment, key management, and data protection across healthcare, federal, financial, and enterprise environments.

FIPS 140-3 Compliance Assessment. Comprehensive cryptographic discovery across your full environment, HSMs, TLS endpoints, cloud KMS configurations, PKI infrastructure, SaaS platforms, and custom applications, producing a Cryptographic Bill of Materials with every gap classified by risk level and every vendor module status verified directly at csrc.nist.gov.

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 stop at.

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 the September 21, 2026, deadline.

Frequently Asked Questions

When does FIPS 140-2 expire?

All FIPS 140-2 certificates move to Historical status on September 21, 2026. After that date, they no longer meet federal procurement requirements or compliance frameworks that reference active CMVP validation.

What does 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.

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

FIPS 140-3 aligns with ISO/IEC 19790 and ISO/IEC 24759, adds a new non-invasive security area, makes software and firmware integrity checks mandatory from Level 2, tightens key management and authentication requirements, and disallows legacy algorithms, including Triple-DES, SHA-1 for signatures, RSA-1024, and MD5.

What is the difference between FIPS Validated and FIPS Compliant?

Validated means independently tested by a NIST-accredited laboratory with an active CMVP certificate you can verify at csrc.nist.gov. Compliant is an unverifiable self-declaration. Only validation satisfies federal procurement, HIPAA expectations, and FedRAMP.

Is FIPS 140-3 mandatory for private companies?

Directly, it is 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, and increasingly, financial examination standards.

Does using a major cloud provider make me FIPS compliant?

Not automatically. FIPS compliance in cloud key management depends on specific configuration choices, FIPS endpoints, HSM-backed tiers, and Cloud HSM key rings, none of which are defaults. Part 2 of this series covers this gap in detail.

Conclusion

The FIPS 140-3 deadline is not something happening in the background. It is an active compliance requirement with a fixed date and concrete consequences for organizations that are not ready when it arrives. 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 deadline, and for organizations starting now, roughly fourteen weeks of runway. The organizations that will be ready on September 21 are the ones that begin their assessment programs today. 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.

Contact Encryption Consulting at info@encryptionconsulting.com for a personalized consultation session.