2026 FIPS Compliance: Requirements, Certifications & More

Key Takeaways

• FIPS compliance ensures cryptographic modules meet federal standards for protecting sensitive data.
• Certification vs. Compliance: Certification is formal NIST validation; compliance is correct use of validated modules in approved mode.
• Maintaining compliance requires tracking validated modules, running FIPS-approved modes, and applying timely security patches.

Many team struggle with FIPS compliance because the rules feel complex and the stakes are high. The good news is that the path is clear once you understand what the standard requires and how products earn FIPS certification.

This guide explains the current FIPS landscape for 2026, the certifications that matter, and the step you must follow to keep your systems compliant. You will learn how FIPS 140-3 works, what cryptographic modules need validation, and how updates affect your compliance status. The next section walk through all the included security requirements in plain language so you can plan with confidence.

Overview of FIPS and Its Role in Cybersecurity

FIPS (Federal Information Processing Standards) are security standards created by the U.S. National Institute of Standards and Technology (NIST). These standards define how approved cryptographic modules must work when they protect sensitive government data. Many industries, including healthcare, finance, and cloud providers also follow FIPS because it offers a clear baseline for strong encryption and controlled key handling.

The most relevant of the FIPS standards today is FIPS 140-3, which sets the rules for testing and validating cryptographic modules used in operating systems, software libraries, and hardware devices. When a product is “FIPS validated,” it has successfully passed independent lab testing under the Cryptographic Module Validation Program (CMVP).

Note: FIPS standards focus specifically on cryptographic modules, not the entire system. Compliance applies only when these modules are properly configured and used in an approved, validated mode.

Navigating FIPS 140-2 and the Transition to FIPS 140-3

FIPS 140-2, published in 2001, shaped the security baseline for cryptographic modules for more than two decades. Most operating systems and libraries that support government workloads still rely on modules validated under this standard. These modules stay active until their official sunset dates, which means many organizations still run FIPS 140-2 validated components today.

The transition to FIPS 140-3 changed how modules are tested and documented. FIPS 140-3 builds on the same core principles as its predecessor but updates the standard to reflect modern threats and align with the international standard ISO/IEC 19790. It introduces clearer rules for entropy, key protection, and physical security mechanisms. It also requires more precise documentation so independent labs can verify how each module works.

The differences matter for compliance planning:

• New Validations Use 140-3 Only: Vendors can no longer submit new modules for validation under the older FIPS 140-2 standard.
• Updates Must Follow 140-3 Rules: Even small code changes or updates to the operational environment (e.g., updating a Linux kernel) may trigger a retest under the new, stricter FIPS 140-3 standard.
• Cryptographic Changes Risk Validation Loss: Modifying a validated module without an approved process can immediately break your compliance status.
• Sunset Dates Drive Migration Timelines: Once a module reaches the end of its validation period, or the final sunset date passes, it no longer meets FIPS certification requirements for new acquisitions.

Important: Existing FIPS 140-2 modules remain valid until September 21, 2026, when all certificates will be officially moved to the CMVP Historical List. All FIPS compliance updates and new procurement must use FIPS 140-3 validated modules after this date. Plan your migration timeline now to avoid lapses in compliance.

The Difference Between FIPS Validation and Compliance

Many teams use the terms FIPS compliant and FIPS certified as if they mean the same thing, but they describe different states.

A product is FIPS Validated (or Certified) only when its cryptographic module appears on the NIST CMVP validation list. This means an accredited lab tested the module under FIPS 140-3 and that NIST approved the results. Certification applies to the module itself, not the full product.

A product is FIPS Compliant when it correctly uses a validated module in a FIPS-approved mode within the certified Operational Environment (OE). The product follows the rules in the standard, but it is not “certified” unless its own module passed testing.

The distinction matters because compliance can break if the validated cryptography changes. Even a small code patch, a kernel update, or an unapproved configuration change to a validated library can invalidate the OE. Teams must track which modules are validated, how patches affect them, and whether the entire system still runs in the approved mode as defined in the Security Policy.

The FIPS Validation Process in 2026: From Module to Market

FIPS validation ensures that cryptographic modules meet strict information security requirements before use in regulated environments. The process involves independent testing, formal review, and public listing. Understanding each stage helps organizations plan updates, deployments, and compliance audits, especially given the lengthy timelines (often exceeding one year).

Role of CMVP, NIST, and Accredited Test Labs

Validation is managed by the Cryptographic Module Validation Program (CMVP), a joint initiative of NIST and the Canadian Centre for Cyber Security (CCCS). The CMVP manages the entire program, oversees the testing, and publishes the official validation lists.

Cryptographic and Security Testing Laboratories (CSTLs) perform the technical evaluation. They are accredited to test modules against the FIPS 140-3 standard, verifying cryptographic algorithms, cryptographic key management, and security functions. NIST reviews lab results and approves validated modules for public listing.

The Cryptographic Algorithm Validation Program (CAVP) is a prerequisite to module validation. CAVP uses the Automated Cryptographic Validation Testing System (ACVTS) to ensure the module’s implementation of specific cryptographic algorithms (like AES, SHA-3) is mathematically correct before the module itself is tested.

Key Stages of FIPS 140-3 Validation

The FIPS validation process has three main stages:

Preparation and Testing: The vendor submits the cryptographic module (Implementation Under Test, or IUT) to the test lab. Testing covers the correct implementation of approved algorithms, secure key generation, randomness (entropy), and self-tests.

Documentation: The vendor submits detailed documents, most critically the Security Policy. This is the non-proprietary statement that defines the module’s boundary, its approved operating modes (FIPS mode), and the OEs on which it was tested.

Review and Validation: The test lab submits the test reports and vendor documents to the CMVP (NIST + CCCS). Reviewers evaluate the submission. Once the FIPS compliance review ends in an approval, the module is assigned a FIPS 140-3 Validation Certificate and is added to the official Validated Modules List.

FIPS Compliance in Cloud and Modern Architectures

Modern cloud-based deployments introduce new challenges. Cryptographic modules may run inside virtual machines, containers, or cloud services. Validation now considers how cryptography functions in these environments.

Organizations must ensure that cloud services either provide FIPS-validated modules or that their deployment preserves FIPS-approved operations. This includes maintaining validated OpenSSL, libcrypt, NSS, GnuTLS, and kernel cryptographic modules in modern stacks.

Services like TuxCare Enterprise Support (TES) can help maintain FIPS compliance in certified AlmaLinux and Rocky Linux environments. TES delivers FIPS-compliant patches and updates that do not change the validated modules, allowing organizations to stay secure while running modern community Linux in the cloud.

Best Practices for Achieving and Maintaining FIPS 140-3 Compliance

Achieving FIPS validation is only the first step. Maintaining it requires ongoing attention to validated cryptography modules, patching processes, and system configurations. These practices help ensure your compliance remains intact over time.

1. Inventory and Track the Validated Operational Environment (OE)

Keep an accurate inventory of every cryptographic module in your OE, including OpenSSL, kernel components, and encryption-using applications.

• Use the module’s Security Policy to track its version, validation date, and validated Operational Environment, including the OS version, kernel version, and cryptographic hardware architecture.
• This prevents the accidental use of unvalidated modules or running a validated module outside its approved OE.

2. Use FIPS-Approved Modes Only

Always run validated cryptographic modules in FIPS-approved mode. These modes control which algorithms can be used and how cryptographic keys are managed.

• Avoid custom builds or configuration changes that alter how cryptography works. Even small undocumented changes can invalidate compliance.
• Regular configuration reviews help prevent drift, especially in cloud and containerized deployments.

3. Apply Timely, Compliance-Safe Security Patches

Security updates are essential, but they must be handled in a way that preserves validated boundaries.

• Patches to OpenSSL, libcrypt, NSS, GnuTLS, or kernel modules may change binaries or the surrounding OE, and this can affect compliance.
• Use a controlled update process instead of standard package updates. If a cryptographic module is changed, re-validation may be required.

4. Plan for Proactive Lifecycle Management

Modules age out, and validations expire as standards evolve. With the sunsetting of FIPS 140-2 in 2026, organizations must plan ahead.

• Track the lifecycle and support timelines of validated modules and prepare replacements early to avoid gaps in compliance.
• Early planning reduces the operational impact of transitions to new validated modules.

5. Leverage Enterprise Support for Continuous Compliance

Community distributions like AlmaLinux and Rocky Linux run well in enterprise environments, but maintaining FIPS alignment requires third-party support.

• TuxCare Enterprise Support provides FIPS-compliant security patches for validated kernel and user-space cryptographic modules. These patches do not change the validated cryptography, helping organizations maintain FIPS continuity while staying current with security updates.

Common Challenges and Pitfalls in FIPS Compliance

Even with a solid plan, organizations face recurring challenges in maintaining FIPS compliance. Awareness of these pitfalls helps prevent gaps that can compromise data security or regulatory standing.

1. Untracked Modules and Changing Operational Environments (OEs)

A primary compliance failure is running modules where the OE is no longer valid. This occurs when:

• Using modules without current validation.
• Failing to track module version numbers.
• Failing to verify that the kernel, OS, or patch level matches the OE specified in the module’s Security Policy.

2. Misconfiguration of FIPS-Approved Modes

Running a validated module outside its approved mode is considered non-compliant. This often occurs due to:

• Accidental Non-FIPS Mode Initialization: Misconfigured applications, scripts, or containerized environments may initialize modules without required FIPS settings.
• Default Settings: Relying on default configurations instead of explicitly enforcing approved modes.

3. Delayed Security Patching

Timely security updates are critical, but incorrect patching can affect compliance.

• Delaying Patches: Leaves systems vulnerable.
• Incorrectly Applying Patches: Can alter validated cryptographic binaries or the OE, potentially requiring re-validation.

4. Complex Modern Environments

Cloud services, VMs, containers, and microservices add complexity to maintaining FIPS boundaries.

• Modules may run in environments where the OE differs from the validated configuration.
• Each cloud or containerized deployment may require separate consideration to ensure FIPS-approved operations.

5. Transition Challenges Between Standards

The sunset of FIPS 140-2 and adoption of 140-3 introduces stricter testing requirements, including for entropy sources and documentation.

• Teams must plan upgrades proactively to ensure modules transition smoothly to FIPS 140-3 before the September 21, 2026, deadline.

Building Trust with FIPS-Ready Infrastructure

FIPS compliance is not just a regulatory requirement; it is a signal that your systems protect sensitive data reliably and that your organization adheres to the highest standards of cryptographic security. By validating your modules, applying patches carefully to preserve the Operational Environment, and following the FIPS best practices outlined in this guide, you ensure information security and regulatory confidence across your environment.

Explore how TuxCare Enterprise Support can simplify FIPS-compliant updates and long-term security, helping keep your AlmaLinux and Rocky Linux infrastructure secure, compliant, and aligned with FIPS 140-3 standards.

Summary

Article Name

2026 FIPS Compliance: Requirements, Certifications & More

Description

Learn what FIPS compliance means, how it differs from certification, and how your organization can meet cryptographic standards for federal data protection.

Author

Rohan Timalsina

Publisher Name

TuxCare

Publisher Logo