FIPS 140-2 Compliance Explained (and Why it’s Important)

Go straight to an AI summary of this blog post instead

Key Takeaways

FIPS 140-2 is a U.S. and Canadian standard validating cryptographic modules in software and hardware.
Organizations continue to use FIPS 140-2 for legacy systems, especially in regulated industries, because existing certificates remain valid.
FIPS 140-3 is the current standard for all new validations, aligning with international requirements and stricter testing protocols.

FIPS 140-2 is no longer being accepted for new validations, but thousands of critical systems across government, finance, and infrastructure still rely on its validated cryptographic modules for security. For organizations operating older FIPS-validated modules, a clear understanding of this compliance regime and its key differences from the updated FIPS 140-3 standard is essential for continuous compliance.

This guide simplifies FIPS 140-2 and explains the shift toward FIPS 140-3 without breaking cryptographic validation. You’ll also discover how solutions like TuxCare Enterprise Support help you maintain FIPS-certified systems with FIPS-compliant security patches for the FIPS-validated modules.

FIPS 140-2 Compliance Explained in Simple Terms

FIPS 140-2 is a U.S. (National Institute of Standards and Technology) and Canadian security standard that validates how cryptographic modules are designed, implemented, and protected. In practice, it ensures that the cryptography inside your operating system, applications, and hardware meets strict, government-grade security requirements for handling sensitive, but not top secret, data. Although new validations ended in 2022, many organizations still use existing cryptographic modules under this standard.

These encryption modules will remain applicable until their certificates expire, so teams must keep on maintaining them correctly for continuous compliance. All existing modules will be officially archived on September 21, 2026. Organizations should plan to transition to FIPS 140-3 before this date to stay aligned with current validation standards.

Note: FIPS is not just a compliance checkbox. It’s a practical safeguard that ensures your encryption tools and Critical Security Parameters (CSPs) behave predictably – a necessity for securing sensitive, but unclassified, data (like CUI or ePHI).

Breakdown: FIPS 140-2 Security Levels

This standard is comprised of four security levels. Each level adds stricter protection requirements for how cryptographic modules must be built, accessed, and monitored. Here’s a simple breakdown of what each level means in real-world environments.

Level 1

Basic security. Cryptographic functions must run correctly, but there are no physical security requirements. Common in general-purpose operating systems and software-based cryptographic libraries. This level often presents a challenge for patch management.

Level 2

Level 2, on the other hand, adds tamper-evident features (e.g., tamper-evident coatings or seals) and enforces role-based access control (RBAC). Used in federal government systems and enterprise servers that need visible proof of tampering.

Level 3

Introduces robust tamper-resistant mechanisms and stronger protection for private cryptographic keys. Private keys must be zeroized/erased automatically if the device is opened. Frequently used in banking hardware, Hardware Security Modules (HSMs), and high-security authentication systems.

Level 4

The highest level. Requires active detection of environmental attacks (voltage, temperature, physical probing). Designed for military, defense, and critical national security devices that operate in hostile environments.

Pro Tip: Most organizations only need Level 1 or 2 to meet typical regulatory compliance requirements. Higher levels are generally reserved for critical systems or environments facing elevated physical or tampering risks.

Maintaining Compliance on Existing Systems

Many organizations continue to use existing FIPS 140-2–certified modules. To stay compliant, teams must maintain these validated components without altering the cryptography or introducing changes that invalidate the FIPS-compliant version. This process is notoriously difficult and costly, which is a major driver for the transition to 140-3.

Keep validated cryptographic modules unchanged

Avoid updates or patches that modify the cryptographic algorithms, key handling, or module boundaries. Any unapproved change can break the original FIPS validation, forcing costly re-certification.

Use FIPS-compliant security updates

Older systems still require patching, but updates must preserve the validated crypto. Vendors providing compliance automation and FIPS-compliant patching that does not trigger a new, months-long revalidation process help maintain continuity.

Monitor certificate status and sunset timelines

Track validation expiration dates (which can be found on the NIST Historical List) and ensure your organization knows when to begin planning a transition to version 140-3. All active FIPS 140-2 certificates will move to the Historical List by September 2026.

Document configuration and operational controls

Auditors often require proof that FIPS compliance mode is enabled, cryptographic settings are unchanged, and approved modules are used consistently across the environment. This documentation must be continuously updated.

Note: Even if a system uses validated cryptography, it is not considered compliant during an audit if it is out of vendor support or no longer receives security updates.

Why This Standard Still Matters (Even in the 140-3 Era)

FIPS 140-2 compliance may be sunsetting for new validations, yet it underpins a huge amount of existing infrastructure. Organizations cannot simply replace validated cryptography overnight as doing so risks severe compliance violations, costly audits, and operational downtime.

Long-lived certified systems still depend on it

Many validated modules remain active for years, and regulated industries must continue using them in existing deployments until the September 21, 2026 deadline or until their specific certificates expire.

Replacing validated cryptography is risky and expensive

Any unapproved change to a certified module instantly invalidates compliance, forcing organizations into lengthy, expensive re-validation cycles or complex, rushed migrations to FIPS 140-3.

Smooth transitions require maintaining compliance first

Most teams must stabilize and secure their existing 140-2 systems before undertaking a an upgrade. This makes reliable continuity support during this necessary overlap period absolutely essential.

FIPS 140-2 vs FIPS 140-3: Key Differences

FIPS 140-3 is the modern successor to version 140-2. While both standards validate cryptographic modules, 140-3 aligns with updated international security requirements (ISO/IEC 19790:2012) and brings stricter testing, stronger physical protections, and more consistent evaluation criteria. Importantly, existing 140-2 certifications remain valid until their certificates expire, however, all new validations must meet 140-3.

Aspect	FIPS 140-2	FIPS 140-3
Foundation	Primarily a U.S./Canada standard with custom requirements.	Aligns with ISO/IEC 19790:2012 for international consistency.
Validation Status	No new submissions accepted since April 1, 2022	Required for all new cryptographic module validations.
Testing/Checks	Required primarily at Power-On (POST).	Requires Conditional Self-Tests (CAST) and runtime checks for continuous operational validity.
Physical Security Enhancements	Level 1 – Level 4	Same security levels, but higher precision in requirements
Operational Scope	Primarily designed for physical cryptographic hardware modules.	Better defined support for software, hybrid, and virtualized modules (crucial for cloud/Linux).
Documentation	Simplified requirements.	Stricter documentation and evidence requirements for the entire module lifecycle.

How to Transition from FIPS 140-2 to 140-3 Smoothly

FIPS 140-2 remains relevant for existing infrastructure, but version 140-3 is the future of cryptographic compliance. Shifting from FIPS 140-2 to 140-3 isn’t just a technical upgrade – it’s a compliance transition that must preserve validated cryptography, avoid service disruptions, and ensure continuity across regulated environments. A structured, phased approach minimizes compliance risk and significantly reduces long-term costs.

Stabilize your existing FIPS 140-2 modules first

Before planning any migration, ensure your current validated modules remain intact, securely patched, and compliant. Unapproved changes can instantly break 140-2 validation and introduce complex, costly obstacles to the FIPS 140-3 transition.

Use vendors that provide FIPS-compliant updates

Choose solutions that deliver security patches without modifying the cryptographic algorithms or metadata, which would typically invalidate the certification. This feature is vital for keeping open-source Linux components secure while preparing for 140-3.

Plan for module-by-module replacement

Instead of attempting a risky, full-environment upgrade, replace validated components gradually, starting with modules closest to the September 2026 sunset deadline or those exposed to the most operational risk.

Document every step for audit readiness

FIPS 140-3 requires stricter evidence of lifecycle management and operational controls. Keeping clean, continuous documentation now will make future validation, re-certification, and audits significantly smoother.

Pro Tip: To minimize risk and auditing pressure, prioritize migrating your high-risk, external-facing modules (like TLS/VPN endpoints) and new systems to FIPS 140-3 before addressing internal, stable, legacy workloads.

Ensuring FIPS 140-3 Compliance with TuxCare Support

Maintaining FIPS 140-2 compliance and the mandatory 140-3 standards can be complex and costly, particularly within open-source Linux environments like AlmaLinux and Rocky Linux. TuxCare Enterprise Support (TES) simplifies this process by providing FIPS-compliant security patches for FIPS-validated AlmaLinux and Rocky Linux deployments, ensuring your cryptographic modules remain validated and operational without service interruptions or compliance gaps.

TuxCare provides a seamless path to compliance through:

Full suite of FIPS-validated modules: Support for all five critical components: kernel, OpenSSL, libcrypt, NSS, and GnuTLS.
FIPS 140-3 Continuity Patching: Security updates are engineered not to alter the validated cryptography, preserving continuous compliance.
Rapid CVE Re-certification: Re-certification of critical security patches faster than the general FIPS 140-3 certification process.
Extended Security Updates: TuxCare delivers extended security fixes for minor versions of AlmaLinux and Rocky Linux. This service is currently available for AlmaLinux 9.2, AlmaLinux 9.6, Rocky Linux 9.6, and planned support for 9.10.

FAQs

What happens if my vendor’s FIPS 140-2 certificate expires?

Once a certificate expires, the module is moved to the NIST Historical List and is no longer officially validated for new procurements. Organizations must either continue to use the module under strict internal operational controls or migrate to a FIPS 140-3 compliance.

Can FIPS 140-2 modules still be purchased after FIPS 140-3 implementation?

Yes, modules on the Historical List can still be used and purchased for existing systems, but they cannot receive new certifications. However, federal procurement rules generally mandate 140-3 for all new cryptographic module deployments, making the transition inevitable.

How can startups approach FIPS certification without large budgets?

The most practical approach is to leverage pre-validated FIPS 140-3 certified components (like operating systems and cryptographic libraries) rather than pursuing expensive direct certification. TuxCare Enterprise Support provides a full suite of five FIPS-validated modules (kernel, OpenSSL, libcrypt, NSS, and GnuTLS), dramatically reducing compliance costs and speeding up deployment.

Summary